Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Location using the Icloud API?
#1
Dean,

I've been following This Thread on the ISY forums. It is for a python script that hits the icloud API to get the location of an ios device, calculates the distance from home and then writes it to a variable in the ISY.

People here have been trying to figure out a good solution for geofencing and I thought this might be something you would think about adding. I would guess that android has a similar API but am not familiar with it.

The main benefit of this route is that everything is configured on the CQC server. There is no need to install an app on the phone, configure it there and keep it up to date.
|Z-Wave|Sonos|Tivo|Hue|Plex|Roku|MyMovies|Echo|
Nest|Harmony|Neeo|LG TV|Smarthings|
Reply
#2
I can probably take a look at that post-5.0 release. It doesn't look like it would be too huge a thing. There's already a calculator for Geodistance at the action level, called System::CalcGeoDistance(). If you have two lat/long coordinates it will calculate the distance. So really all that would be required is a CML class that would get the lat/long of the phone. You can already get the lat/long of your home system. So that would give you the info required to do that calculation.
Dean Roddey
Software Geek Extraordinaire
Reply
#3
This sounds pretty awesome.
--Kill all the serial ports--
Reply
#4
potts.mike Wrote:Dean,

I've been following This Thread on the ISY forums. It is for a python script that hits the icloud API to get the location of an ios device, calculates the distance from home and then writes it to a variable in the ISY.

People here have been trying to figure out a good solution for geofencing and I thought this might be something you would think about adding. I would guess that android has a similar API but am not familiar with it.

The main benefit of this route is that everything is configured on the CQC server. There is no need to install an app on the phone, configure it there and keep it up to date.
Playing devil's advocate...

What you are proposing would be a great addition to CQC however there is an overhead burden of coding (to keep it all in CQC) and would require polling for each user and their device(s) and then sorting through geo location trigger scenarios.

geo trigger scenarios

near, moving towards, moving away, away, movement velocity

then based on scenarios:

where is Sally, check each of Sally's trigger scenarios, trigger automation event(s)
where is Bobby, check each of Bobby's trigger scenarios, trigger automation event(s)
where is Dad's personal phone, check each of Dad's personal phone trigger scenarios, trigger automation event(s)
where is Dad's work phone, check each of Dad's work phone trigger scenarios, trigger automation event(s)
where is Mom's cell, check each of Mom's cell trigger scenarios, trigger automation event(s)
where is Mom's tablet, check each of Mom's tablet trigger scenarios, trigger automation event(s)
etc
etc...
Loop

In these use cases would it make more sense to have push notifications from the devices? Yes the setup is spread out but the messaging can be simplified to user and trigger. e.g. sally has passed through 2 geofence circles that indicate she is heading home (far from home geofence, near home geofence) send message to CQC, Sally heading home, adjust HVAC. Then when Sally hits home geofence (other 2 trigger scenario's have already been satisfied) send CQC message Sally home, do home things set up for Sally. Of course Sally could be going to a friends house near her own home that happens to be in the near home geofence but that is a different problem to solve...

For device push notifications on Android a solution already exists. Tasker combined with the AutoLocation plugin will give you everything you need to use geofencing to trigger events in CQC via Push notifications (as opposed to CQC constantly polling in a Pull fashion) The AutoLocation plugin allows you to easily set up geofence triggers (up to 100 per device and cascade dependencies can be built between defined geofences) using a map, no need to have to calculate anything. The plugin also knows how you are moving, in auto, on bike, walking which could be useful for determining when to trigger an automation event.

If you are interested a Google I/O presentation from 2013 Beyond the Blue Dot describes in more detail of how Android does geolocation combining GPS and WiFi signals.

My perspective on this may be skewed due to the fact that the AutoLocation plugin provides a very easy way to solve the fence trigger scenarios and build dependencies that better indicate location and direction of travel. There may not be a similar type of solution available on iOS.

Regardless of push vs pull for Android users yes there is a similar API available and it would be a great addition to have basic geofencing capability built into the system.
Reply
#5
It would certainly be vastly more efficient to push it from the device. It doesn't even have to be able to do the geo-distance calculation. It just has to send its lat/long info, and a device identifier.

A driver on the CQC side can use that, plus the known home system lat/long, do the calculation, and store it in a distance field per user (or device.) It can send out a trigger when the device moves into or out of one of its predefined radii.

So it would require a driver that can listen for the notifications, plus take some configuration that indicates which devices it wants to know about, an name to assign to each one that is used for the fields and the notifications, a unique id that will come in with the notifications, and a handful of defined radii for that device to trigger on.

It would probably want to have a new GeoDistance trigger type as well, since that's something that it would be nice to have standardized.

Of course that means exposing that driver to the outside world. Not a lot of danger in that in this case, since the worst they could do is try to confuse you as to the distance of one of your devices, or a DOS attack I guess. But it couldn't become a gateway to access any functionality other than what you set it up to react to. And they'd have to know the id of your devices to even do that.
Dean Roddey
Software Geek Extraordinaire
Reply
#6
I realize that this is something that can be done now but maintaining another app on my wife'a phone is proving to be impossible. Having it centralized to the CQC system makes this much easier.

I am not sure what the worry concerning overhead in CQC is. It barely registers 1% on any machine currently in service.
|Z-Wave|Sonos|Tivo|Hue|Plex|Roku|MyMovies|Echo|
Nest|Harmony|Neeo|LG TV|Smarthings|
Reply
#7
It's not really CPU overhead here really. But it depends on how quickly these things need to be kept up. I guess in the case being discussed above, it's not actually having to go out and find a device and talk it it, it's talking to a server, right? Do they have rate limitations on accessing that data?

If you are driving down the road, how often does each one need to be updated in order to make it accurate enough? You could be going a mile a minute. And, in a polling situation, we have to constantly poll at the worst case rate that it would need to be kept updated. So if it needed to poll every ten seconds, that's 8640 times a day per device. Five devices and it's 43K times a day.

As long as the servers will allow that and remain responsive it can be done of course.

And there's nothing to say such a driver couldn't support both types of schemes. Definitely where it's practical to push the notifications that would be optimal. That means minimum overhead and the latency is very low.
Dean Roddey
Software Geek Extraordinaire
Reply
#8
The python script I linked to polled more frequently based on distance. The idea being the farther away you are the less urgent your location is. I'm
It sure what the max polling frequency is, I'll try and check tonight.
|Z-Wave|Sonos|Tivo|Hue|Plex|Roku|MyMovies|Echo|
Nest|Harmony|Neeo|LG TV|Smarthings|
Reply
#9
Just curious whats the best method for GeoFencing currently?

I wanted to enable it again thought id see what y'all were doin.
Reply
#10
There is an action command called System::CalcGeoDistance. It takes two lat/long pairs, and an indicator of what units you want the calculated distance to be returned as, and a variable to put that result into.

If you provide the special value [SERVER] that will resolve to the CQC server's lat/long which is already configured. You can also put in [CLIENT] which would resolve to the client's lat/long if there is a means to get that. Currently there isn't. If it's possible to get lat/long from within a javascript program, then the WebRIVA program could be updated to support that. Then any time you want to make that calculation just call the command with those two special values.

That is of course a way to get it on the client itself. Maybe that's not always what is desired, or maybe that's never desired. But doing it on the back end is a much bigger thing, because it would require that the server be told about any clients and have some way to uniquely identify them and know how to connect to them (not an easy thing for mobile devices necessarily) and regularly talk to them to get lat/long info.

That's probably not too practical. It would be more practical to have the client tell the server about its distance. But then you have all of the issues of secure connections back to CQC, and the clients have to be on and actively doing something all the time in order for it to work. But, this way, each client could just send its info and a unique name that you tell it to send. A driver could accept these commands and, for each one it's seen, it stores a last distance and time stamp for when it last was updated. CQC doesn't have to know ahead of time about the clients, it just stores info for ones that have reported to it.

This way, where it's done on the server, then that info can be field info and you can react to it. Of course you can already react to your phone connecting to your network. There's a NetMon driver for that. So you can do things based on when it sees your phone enter or exit the local network. It uses pings to do this.

For WebRIVA, it already has a connection back to the server and already is running actively as long as you have it up. So, we could have it provide client side lat/long to the server actively from the client. That would allow the web server to send out action triggers when the distance changed by more than some amount. Or we could have a special driver that the WebServer watches for and writes these changes to it so that it can be seen as field data. That might be a better way to do it, I dunno.

If the data isn't stored in driver fields there wouldn't be any way to display that distance on the WebRIVA client. At least not without some specialized, WebRIVA specific display widget which I'd prefer to avoid.

Anyway, hopefully that made some sense. The short version is:

IF it's possible to get lat/long from javascript (not a given with all the security concerns these days), then WebRIVA could get that info and send it to the WebServer after any change of a given magnitude (probably percentage so that bigger changes are required for longer distances) or at least at some maximum period. The WebServer could either send out triggers for those changes, or be updated to watch for a special driver that it updates. You would have to configure that driver with the names of any WebRIVA clients it should have storage for. The &sessname=xxx value on the WebRIVA client would provide the name that the WebRIVA client would send out, and that would have to map to one of those configured names in the driver. If so, the driver would store the distance and time stamp of the last change. Maybe another field that is true if the last update was within some period of time, i.e. a 'fresh' indicator.

That would probably be the best way to do it.
Dean Roddey
Software Geek Extraordinaire
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)