iOS / ISY Proximity Script

[rccoleman]

Other than the changes I mentioned, I didn't customize anything other than changing the update granularity. I'm running mostly a stock setup.

[Steven M Castano]

Other than the changes I mentioned, I didn't customize anything other than changing the update granularity. I'm running mostly a stock setup.

 

Well ok then, good good... at least I knew the default options are working well then!!

 

I'll get that 2 factor auth working soon enough and include it into the public code base so you can keep up to date with anything else I add and things should be good then.

 

The only things I have planned in my head right now are:

 

1) I want to check the "isOld" data returned from the API and if it's true, I want to try a max of 5 times with 30 seconds in between to read location data again and get date that is NOT old before reporting it to the ISY. If it tries 5 times and doesn't get non-"isOld" data, than use it anyway

2) Apparently from the API I should be able to read battery status as well. I was thinking about adding a configurable feature so if your battery drops below a certain percent, the script checks either once per hour, or however long your distance variable sleep time is, whichever is longer.

3) Possibly move a lot of these functions to separate threads so one running copy of the app could be used to check multiple devices on multiple accounts all reported back to the same ISY.

 

I'm also sure there are some people who might like this idea but just don't have the linux/python/server/raspberry pi experiance etc... to install something like this and run it... so I'm thinking about possibly releasing a cloud version of it where people could create an account, put in their iCloud and ISY credentials, select from a list of devices associated with there account and just have it all done for them from one of my datacenter servers. Of course with the database/location tracking disabled.

 

I've also considered putting together another configuration file that could take a list of locations and the radius around them, just like the "home" settings now and have it before configurable to send emails, alerts, perform other web calls, etc... so people could do things like email an alert to their spouse when leaving work, or even had alerts sent to parents when a kid leaves school or something.

 

It's all a little big brother-ish, but I knew there are some people who want that. The first I'll do I think is set mine to send an alert to my team when I'm getting close to the office telling them that someone should make coffee for me and leave it in my office!

[Steven M Castano]

The "isOld" checking is now in place. By default in the latest version (0.13.1), if the data returned from the iCloud API has an "isOld" value of true, the data read function will sleep for 30 seconds and try again. It will try again a max of 6 times and if it still hasn't gotten data that is current, it will return back to the main function whatever data it has.

 

All the options related to this new feature are configurable in the .ini file, the max number of times to retry, the sleep time between attempts and to enable or disable checking the "isOld" field in the first place.

 

Update on the 2 factor authentication, it was in fact my account that was screwed up, I've created a new iCloud account, put a backup device on it and got 2 factor authentication working properly on the account. Now I will work on updating the code with the pyicloud library suggested code for 2FA as @rccoleman already confirmed he made the changes himself and it's working fine, I would assume my tests should go just as well and I'll have a version out that supports 2 factor authentication soon.

[Steven M Castano]

It took a little while to get it all worked out and tested, but release 0.14 was just pushed to the public repo with the two factor auth code in it, fully tested and working. Just be sure that if you upgrade to the version you also make sure you install the python module "click" by running either a "pip install click" or a "pip install -r requirements.txt" to make sure you have all the modules needed for the code to work. Without having click installed, even if you do not have two factor auth enabled, the app will fail to start.

 

Things are going pretty well according to plan. I'd like to implement the battery checking portion next if possible, then I think we're ready for the first version 1.0 release. Hopefully some more people will report anything that comes up or let me know it's working well so far. I see from the traffic on the repo that a few more people have cloned the code and cloned a few versions, so I'm guessing it's more than just myself on Rob running the app! hahaha

 

Let me know how it's going for you!

[rccoleman]

In the middle of the night tonight my ISY oscillated between Home and Away a couple of times.  I checked the script log and I noticed that the location usually reports a PositionType of GPS, but those two times it unexpectedly reported "Cell" with a distance from home >=0.5miles (in one case it was 0.5, in the next it was 0.6).  In both cases, the next sample was GPS, and the distance went back to being very near home (~0.01 miles).

 

With a program that looks for >=0.5 miles as "away", that was enough to trigger "away", "home", "away", "home" at ~3:50AM.  Ugh.  This was with my phone sitting on a charger on my nightstand.

 

I note that the logs say this:

2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - RADIO_CHECK - Running...
2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - RADIO_CHECK - Script is not set to check for WiFi proximity, continuing...
2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - RADIO_CHECK - Script is not set to check for Bluetooth proximity, continuing...
2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - RADIO_CHECK - the iOS device is not in radio range.
2016-10-02 03:49:32,701 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - MAIN - iPhone is not in radio range or WiFi and BT checking is disabled, checking GPS...

It looks like you're relying on a separate data source and a variable to indicate both of those states.  How do you intend for that to work?

 

Based on the apparently poor accuracy of Cell-type locations and the relative frequency of GPS-type locations, I'm tempted to completely ignore "Cell" reports.

 

Rob

[Steven M Castano]

In the middle of the night tonight my ISY oscillated between Home and Away a couple of times.  I checked the script log and I noticed that the location usually reports a PositionType of GPS, but those two times it unexpectedly reported "Cell" with a distance from home >=0.5miles (in one case it was 0.5, in the next it was 0.6).  In both cases, the next sample was GPS, and the distance went back to being very near home (~0.01 miles).

 

With a program that looks for >=0.5 miles as "away", that was enough to trigger "away", "home", "away", "home" at ~3:50AM.  Ugh.  This was with my phone sitting on a charger on my nightstand.

 

I note that the logs say this:

2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - RADIO_CHECK - Running...
2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - RADIO_CHECK - Script is not set to check for WiFi proximity, continuing...
2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - RADIO_CHECK - Script is not set to check for Bluetooth proximity, continuing...
2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - RADIO_CHECK - the iOS device is not in radio range.
2016-10-02 03:49:32,701 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG    - MAIN - iPhone is not in radio range or WiFi and BT checking is disabled, checking GPS...

It looks like you're relying on a separate data source and a variable to indicate both of those states.  How do you intend for that to work?

 

Based on the apparently poor accuracy of Cell-type locations and the relative frequency of GPS-type locations, I'm tempted to completely ignore "Cell" reports.

 

Rob

 

So what your seeing is fairly normal, especially when charging and iOS device can drop off of wifi for up to 30 minutes to an hour from my testing... sometimes the call for GPS location will wake it back up for wifi, other times a push notification or an email will do it, sometimes when it's charging, hasn't physically moved in a while and is just sitting there, it surely does stay of wifi almost all the time and end up relying a triangulating cell towers for it's location since it figures it's not all that important to you at that moment.... since you're not touching your phone for hours anyway.

 

Another user on this forum post (@jtara92101) noted a similar behavior with the cell style of GPS oscillation. Without any other checks, mine does the same thing as well. If you look at the horizontal accuracy numbers for "Cell" coordinates they're pretty huge compared to the normal 5 - 60 meters you get from GPS or WiFi. So what you're seeing is totally normal.

 

There's a few solution I could propose for you:

1) Start using timers, Basically, have the app update a variable, but when that variable updates have it start a program that waits for 5 minutes before setting your home to it's "Away" mode. Then anytime that variable drops below .5 miles again, have it STOP the timer program and set the variable back to "Home" again. Then hopefully if you're having the app check once every minute, you'd have 4 or 5 more chances to get back onto GPS or WiFi and get a more accurate location.

2) I could very quickly code in another advanced option called "ignore_cell" or something that like that would do exactly what you're looking for an ignore any GPS data with a returned type of "Cell", pause for a variable number of seconds you could enter into another setting called "ignore_cell_sleep" and then recheck again. Maybe even let it recheck a few times and have a max_retry setting so if it check your location 5 times and it STILL hasn't come back to GPS or WiFi, just report it anyway. Which could easily happen if your WiFi, internet or something like that is down, or your wifi is turned off on your phone, or maybe even, you're in a place where you don't get WiFi or GPS, maybe your basement, or in a mall or something.... but if the use-case is there for you to totally ignore cell based GPS data I can write that in.

 

The third option is where it gets a little more complex...

3) Use the "RADIO_CHECK" functions I've already built into the app. These are both set in the [general] section in the more advanced settings. Basically, I'll explain both wifi and bluetooth for you....

 

The first 1, wifi is based on a shell script I wrote. I run OpenWrt as my router firmware. It's basically an opensource little mini version of linux meant to totally replace whatever stock firmware runs on your router now. Previously I had it running on a Linksys E3000, now it's running on an ASUS something... I forget the model. Basically what it does is checks the arp tables of the router for the mac address of the wifi antenna on my iPhone. (this will work for any phone by the way) It does this by running the "arp -a" command, getting a list of every mac that's passed data through the router in the last few minutes and searches the last for my phones MAC, if it funds it, it updates another ISY variable just like the iphonelocation python app I wrote. When the device is found in the arp table, it sets the ISY variable to "1", when it's not found it sets the ISY variable to "0". This is basically how I was doing proximity checking for the last 4 or 5 years. SO.... what I wrote into the iOS iCloud Proximity app is the ability to check this variable. So you can enable the wifi checking, tell it that the wifi data is stored in ISY variable number 40 for example and that the expect value when the device is on wifi is a "1". The the iCloud Proximity app would check this ISY variable before even looking for GPS data and if it find the device is on wifi, it doesn't even bother to his the API and look up the GPS data because if your device is on your home WiFi network, you're obviously home. It then causes (by default, but its configurable) the app sleep for 300 seconds (5 minutes) before even bothering to check radio status and/or GPS data again... since it's probably going to take you a few minutes to get your stuff together and get out of the house and wifi range anyway. Then, when you're NOT on wifi, the app goes back to it's normal 1 check per minute until you start getting farther away.

 

And NEXT.... keep all that garbage in your head since it's basically the same for Bluetooth checking. I tossed a really cheap bluetooth 4.0 compatible dongle ( an older Raspberry Pi, I think it's just a Model B since that's what I had laying around and I have another python app/script that basically does the same thing as the WiFi checking. You basically pair your phone with the bluetooth dongle and set it as a trusted device which is needed for the iOS to not block out bluetooth calls to it later after it's gone away and come back... then basically it does the same thing the wifi script does, only this time the python script runs an "hcitool name -a AA:BB:CC:11:22:33" (replaced with whatever your bluetooth MAC is, which returns the name of the device. In my case this command returns "Steven's iPhone". The script then basically checks the name returned from this command and if it matches the text you configure it to expect, it sets another different variable on the ISY so the ISY now knows you're in range via bluetooth. If you are, that script sleeps for 5 minutes and checks bluetooth again. Basically the bluetooth low energy lookups use FAR less battery than the GPS lookups, and again... if you can be seen by a bluetooth dongle, you must be within 30 - 50 meters as most of them are rated, so you're obviously home and the iCloud Proximity app doesn't bother to check your GPS location.

 

Sorry for the LONG explanation there, but that's basically how that works... I do use both the wifi and bluetooth checking in addition to the iCloud Proximity app and it works great. In fact, once of the cool things I can do is on the ISY with a timer function like I described above the "radio" checks become a backup to the GPS checks. If the GPS checks still think I'm home, but my device hasn't been seen on WiFi or via Bluetooth in 1 hour, the ISY sets me as away anyway, then as soon as it sees one of them again, it marks me as home right away. It's not only good as a backup to the GPS data should the script crash and you not know it, but it's nice if I wind up walking over to the cute neighbors place for a few hours, even though I'm inside my 1 mile "geofence" I'm still not IN my house, so it works anyway!

 

I know that's a lot of data/stuff to ingest all at once... hopefully it makes some sense, but THAT is what the RADIO_CHECK function is there for. It's actually been in the app since the first version I wrote, the only reason you're seeing it now is because I moved that code to a separate function outside of MAIN to keep the code clean since it can get a little complex... so what you're seeing now is main calling the function, and the function reading from the config file that the checks are disabled, so it's just returning back to main that the wifi status and bluetooth status are "False" since they're not being checked.

 

So VERY long story short, to review... your 4 choices really, would be:

1) Use a timer function to not mark you away for 5 or so minutes to give the iCloud Proximity app a chance to catch a GPS or WiFi based location again

2) I could code in for you the ability to ignore "Cell" based location data (it's almost the same is the ignoring of "isOld" data I wrote into the latest few version, so writing this in should be pretty quick, it could be done today

3) You could start working on WiFi and or Bluetooth proximity checking, which by the way is a huge battery saver for your device, and I'm happy to help you with both of those

or the one I hadn't though of yet 4) You could set your geofence to 1 mile and not care if it bounces around a bit since it would still be inside your geofence and not trigger anything.

[Steven M Castano]

Release 0.15 has been pushed in response to the request/idea above!

 

So before you even had a chance to reply, I added the code to ignore the cell based location data. It's turned OFF by default since most users will probably want to accept any GPS data that's current, but all the settings have been added to the end of the .ini.sample file are configurable to ignore the data, the max number of times to ignore data if it's from cellular and the time to sleep between retries as well.

 

From your logs above I can see you're running v0.12. There have been some other updates between there and this new release this morning (v0.15), so make sure you check the Releases page and follow the instructions to install click, and update any other new settings that have come up in the .ini.sample file since. The biggest one being that, by default now, the app rejects any data that comes from the API with the "isOld" flag set to true for a max of 6 times with a retry time of 30 seconds in between. If you do NOT want to use this feature, make sure you switch the setting to "False" in your .ini file.

[rccoleman]

Thanks. Steve. I updated to 0.14 after I noticed the cell location problem and will do so again for 0.15.

[Steven M Castano]

Thanks. Steve. I updated to 0.14 after I noticed the cell location problem and will do so again for 0.15.

 

Not a problem, let me know how it goes!

[Toddimus]

I've been keeping an eye on this thread.  I plan to check it out soon, maybe this week.  Been too busy to get deep into loading/testing it out. 

 

Thanks for your work on it!!

[Steven M Castano]

I've been keeping an eye on this thread.  I plan to check it out soon, maybe this week.  Been too busy to get deep into loading/testing it out. 

 

Thanks for your work on it!!

 

Not a problem, good luck!! And of course, don't hesitate to reach out for a hand if it doesn't come together too easily. Most of it is pretty simple though, as long as you get the install done and the script to run... basically you should just be able to put in your iCloud info, get your device ID, add that and all your ISY info the .ini file and the defaults should pretty much have you up and running quickly.

[rccoleman]

0.15 has been working well for me since last weekend with cell location updates ignored.  Thanks for doing this!

 

Rob

[Steven M Castano]

0.15 has been working well for me since last weekend with cell location updates ignored.  Thanks for doing this!

 

Rob

 

Good stuff, and not a problem... I'm glad it's working well for you... I've been using it myself as well and it's working great!!

 

I did also do some recent digging in the iCloud API and I found out how to check battery levels and be able to display messages and have the phone play a sound, so I'm going to add a little code soon to check the batter level when it checks the location and write in a configurable battery threshold, so maybe by default, if your phone dips under 15% charge, it sends you a little warning messages and switches to checking 1 time per hour until it sees the battery level has come back up. The warning message would just be to let users know their position tracking is being slowed down, so they're not surprised if the lights on when they don't get home or something like that.

 

And of course, the battery level threshold will be configurable, the amount to make the script wait before checking again will be configurable, and of course, you'll be able to turn off that entire functionality and have the script ignore the battery level all together.

 

I'm also thinking about adding an option in there to skip over all the database storage so if people want to run a really lightweight version of the script, they won't even need MySQL anymore, they just won't have any history to go back and look at.

 

Is there anything else you, or anyone else can think of that they'd like to see the script do? I've not, I'll finish up these last few changes, clean up the sample.ini file with better descriptions and a little nicer format and release the first 1.0-Stable version.

 

Oh yeah... 1 other thing, I think I might toss a version check thing in there so maybe once every 24 hours or so it pings one of my servers and compares version numbers and just sends your phone a quick little message to let you know there's a new version of the script out.

[rccoleman]

Thanks, battery level awareness would be helpful. I'm trying to figure out if the declining battery performance of my 6s Plus is due to the march of time or the increased GPS checking.

 

Rob

[Steven M Castano]

Thanks, battery level awareness would be helpful. I'm trying to figure out if the declining battery performance of my 6s Plus is due to the march of time or the increased GPS checking.

 

Rob

 

Well I can tell you for sure the GPS lookups do have an effect on battery life. I switched from a 6 Plus to a 6s Plus recently as well and battery life did surely get better, and it's some of best battery life I've ever had an iPhone, so I would think if you're having battery drain problems, and you still have the script checking once a minute all the time, especially when you're home anyway, that could surely have an effect on it.

 

My phone is running 9.3.3 and it's jailbroken, so I had installed the enhanced battery stats tweak so I could see what system daemons and everything were using the battery as well and sure enough, when I set the script to ignore my wifi and bluetooth status and just check all the time, I'd have days where, even with pretty solid usage of the phone the "com.apple.icloud.FindMyDevice" service did show usages as high as 20 - 30% of my battery at worst. That was basically a full 24 hours of checking my GPS once every minute. That's based on about 1,440 checks a day, so figure that approximately every 50 GPS checks costs me 1% battery life.

 

That's the biggest reason I put the ability for the script to not check GPS if it reads from your ISY that you're in range via Bluetooth or on your home Wifi network, as well as writing in the variable sleep time as your move farther away from home. No granted I work from home, so the battery saving there was huge, but even if you're only home for a few hours a day, every hour you're home would save you another 1% battery.

 

It all depends on your use case but the few GPS lookups you need to do the better.

 

You could go into the Advanced Settings area of the .ini file and try changing your "cycle_sleep_default" value from the default of 60 seconds up to 120 seconds or even 180 seconds and see if your battery life improves.

 

Also, depending on how far away from home you are... for instance, if you work within 5 miles of your house, then the script will just bang away all day since you're not outside of the default radius to start using variable time.

[bernieb]

This looks like a really good way to do geo location.  I may very well try this in the near future.

Question though:  How hard would it be to modify the script to use with another home automation software.

I am gearing up to run OpenHab in conjunction with my ISY to supplement a few less important processes.  I would be nice to have a similar way to track presence on both platforms, even share an RPi for the task.

[Steven M Castano]

This looks like a really good way to do geo location.  I may very well try this in the near future.

Question though:  How hard would it be to modify the script to use with another home automation software.

I am gearing up to run OpenHab in conjunction with my ISY to supplement a few less important processes.  I would be nice to have a similar way to track presence on both platforms, even share an RPi for the task.

 

It shouldn't be very hard at all, in fact I'm sure I can put together something for you to try very quickly. Basically the current code works like this... from a 50,000 foot view so to speak:

 

1) It reads your iCloud account info and the GPS coordinates of your house from the info you enter in the config file.

2) It logs into your iCloud account and get's a security token

3) It uses this token to hit the iCloud API and get the GPS coordinates of your device

4) It compares the device coordinates with your "home" coordinates and determines the distance your device is away from home

5) If the distance you are from home is different during this cycle than it was from the last, it runs a function to send the data to the ISY

6) It record the distance from home

7) It starts the loop of read the coordinates, calculating the distance, checking it against you previous distance and reporting the new distance if needed

And on and on and on and on..... 

 

Basically, the part you're talking about is "step 5" from above which happens to be on line 799 of this code version v0.15 which calls a function called "isy_variable". In the function it takes the data, in this case the distance, using the ISY API and records the distance in a variable. All in about 15 lines of code.

 

To make this work with OpenHAB also, all I need to do is a write a function called "openhab_variable" or something that takes the exact same data and using the OpenHAB API sends to data over however it's needed... url query, json, just an http get request, etc... I don't know much about OpenHAB since I don't run it myself, but if you could give me a quick overview of the API and/or point me toward some documentation, I could very easily add an OpenHAB section to the config file that would let you put in another set of credentials, variable names/numbers/whatever, and put together a way to deliver to both one after the other. I can even put variables in there to turn on or off updating each system independently.

 

So yes, you should be able to use a single Raspberry Pi and a single running copy of this script to update both places, and honestly, I could write in the code for just about any home automation system out there as long as it has an API and there's somebody out there willing to beta test it for me.

 

I'd be happy to help.

[bernieb]

Hi Steve,

 

Thanks for the quick reply.  I am not much of a programmer, but from reading your original description, my thought were exactly the same, it shouldn't be too hard to attempt this to support another home automation platform.  Being able to support both the ISY and something else, (in this case OpenHab) would be great.  this way it would be consistent across the board.  Let me look at the requirements and dependencies of your package and see if I can't get that running in the between now and next weekend.  This way it will give me a baseline.   

 

I am still very green with Openhab, just beep playing with it for the last 10 days or so and already had to start from scratch 3 times, but I am getting there.  

They do have several APIs and binding that can be used, not sure what would be the best, but here's a few references that may give you a better idea.  I would think that you'd want to keep it as close to the same method used to update the ISY

 

JSON

https://github.com/openhab/openhab/wiki/JSON-Transformations

REST API

https://github.com/openhab/openhab/wiki/REST-API

HTTP Binding

https://github.com/openhab/openhab/wiki/Http-Binding

 

The right had column of this wiki may give you other ideas/methods to explore as well.

 

I love my ISY and plan to stick with it for my "mission critical" items.  Lighting, heating and security.  But the other fun stuff, like Hue, Kodi, outdoor landscaping lighting, RFXCOM drape and shades automation, I'd like to explore OpenHAB.  Maybe in the future Polyglot will offer all of these services, but for now it's fun to learn another platform.  

[Steven M Castano]

 

REST API

https://github.com/openhab/openhab/wiki/REST-API

 

It looks like we've got it right here.... in the middle of the REST API section it shows the exact URL on how to set a value:

It's also possible to send a status update using a HTTP GET request 
(http://localhost:8080/CMD?Temperature_FF_Office=12.3). This way it's
actually possible to send status updates simply through a web browser
address bar.

That pretty much looks like exactly what I'm looking for, that's the same method already in place for the ISY, so I should be able to create new config options for OpenHAB_Username / Password / Varaiable Name / Etc... then just pass the distance and variable name into that function and it will authenticate, run an HTTP get with the URL type format above and it should drop the distance value into any variable/device you'd like.

 

Once you've got it up and running, let me know and I'll create a specific development branch for the OpenHAB testing... then once we get it right, I'll marge it into the main code with two new variables "Enable_ISY" and "Enable_OpenHAB" then people can choose.

 

Technically, I could include any other methods/home automation systems people want as well, I could also build in a web framework into the app itself so it has it's own API, so you could call http://scripthost:8080/device/<appleguid>/distanceand it would return to you the current distance the app has calculated. I've thought about doing this anyway so people could hook it up to the Amazon Echo and ask something like "Alexa, Ask proximity manager where Steve is." and it would tell me how far away Steve is as well as do a geolookup to google and tell you the city and state as well!

[Steven M Castano]

I just spent a few minutes (hours) adding battery level checking... currently the default settings are that battery checking is turned on, the threshold is 15% and the sleep time is 3600 seconds (1 hour).

 

What this means is the script will now check the battery level of the iOS device while it checks the location and if the battery is below 15% it will wait 1 hour before checking again, but if your far enough away that the variable time checking would have waited OVER that 1 hour, it waits longer instead.

 

And as always, the battery check itself can be turned on and off and the threshold as well as the sleep time if the battery is below that threshold are all configurable in the .ini file.

 

I'm running the code myself for the next day or two to make sure it's good to go, then I'll push it out to the public repo... if anyone really wants to test it sooner, I'll push it to the dev branch, just let me know.

[rccoleman]

So, if I understand correctly, if my battery level is below 15% and I'm heading home, it's possible that it won't see that I'm approaching my house because it may be in the middle of a 1-hour waiting period?  I think the maximum that I'd want in that situation is around 5 minutes, and that's close to what I get with the current distance multiplier and no battery checking.  My office is about 15 mins away from my house, so I don't deal with significant times or distances on a day-to-day basis.  I can't think of a better way to take the battery level into account without some sort of feedback from the device, though.

 

Rob

[Steven M Castano]

So, if I understand correctly, if my battery level is below 15% and I'm heading home, it's possible that it won't see that I'm approaching my house because it may be in the middle of a 1-hour waiting period?  I think the maximum that I'd want in that situation is around 5 minutes, and that's close to what I get with the current distance multiplier and no battery checking.  My office is about 15 mins away from my house, so I don't deal with significant times or distances on a day-to-day basis.  I can't think of a better way to take the battery level into account without some sort of feedback from the device, though.

 

Rob

 

Yes, if the battery level were to fall under 15%, the script would wait for 1 hour before updating... but all those values are configurable so you could set it to 5% or even set it to slow down the checks to once every 10 minutes, or even just change the "battery_check" setting to "False" and just have it skip the whole thing. That's why I made it configurable... so in your case with being so close to home, you could adjust it or disable it to your liking.

 

If you wanted to slow it down to match what you mentioned, you could just change the "battery_sleep" setting to "300" which would be the 5 minutes you're looking for.

 

What type of feedback are you thinking about that would make the battery info more usable?

[Steven M Castano]

I'v just push version 0.16 out to the public repo, through my testing it's been working well. Basically I change the logging level of some messages so the data output to the screen is a little cleaner, no more warning messages for "isOld" or "Cell" data unless you exceed the retries and the old or Cell data needs to be used.

 

Also, I added the battery monitoring I was talking about above. In my case it works great with the default setting. Once my battery drops below 15% the script sleeps for 1 hour if I'm close to home, or longer if the variable distance says I was going to sleep for over an hour anyway.

 

As always, the settings have been added to the .ini.sample file and you can adjust them to fit your needs, or disable the entire function.

[bernieb]

Hi Steve,

 

Just rebuilt my instance of OpenHab on a new Raspberry Pi 3, so I wanted to see if I can get this started, I have to say that I only skimmed part of this thread and did have a few questions.  Can this allow to follow more than one device?  Can it track my phone and my wife's phone as well?   

 

Also I did see your pre-requisites, but does this need an Apache server as well?  I may be the one that would need a "for dummies" step by step install instructions unless I can refer to standard install of these dependencies on RPi.  I did look at the config file and saw that there is only 1 port to setup.  My ISY does not run on the standard port 80 and even my https port is not standard as well, can your script accommodate non-standard ports for both http and https?  On my OpenHab, these are not standard either, it runs on port 8080 for http.

 

Also curious about your script that runs on your router.  I have an Asus as well and wouldn't have an issue installing a new firmware if I can get some benefits from that as well.  One of the things that I am looking for is a way to see if some devices are connected to the router (via MAC address i assume)  One of my goals is to be able to let my ISY (Openhab) know if I am working from home.  Detecting the MAC address of my work laptop and updating a variable would work fine.  Any ideas if this could be accomplished with such a script?

 

Thanks

Bernie

[Steven M Castano]

We'll take the reply step by step...

 

Just rebuilt my instance of OpenHab on a new Raspberry Pi 3, so I wanted to see if I can get this started, I have to say that I only skimmed part of this thread and did have a few questions.  Can this allow to follow more than one device?  Can it track my phone and my wife's phone as well?

 

Right now the script only tracks one device at a time, however you can clone the script into multiple directories and run multiple copies of it... that's exactly what I do for both mine and my GF's phone. I setup each one independently of the other, so they have different iCloud credentials, different ISY variables, different databases for location data storage, etc... basically, you just set the whole thing up twice. In theory, you could run as many copies of this as you want and track as many devices as you want.

 

Also I did see your pre-requisites, but does this need an Apache server as well?  I may be the one that would need a "for dummies" step by step install instructions unless I can refer to standard install of these dependencies on RPi.  I did look at the config file and saw that there is only 1 port to setup.  My ISY does not run on the standard port 80 and even my https port is not standard as well, can your script accommodate non-standard ports for both http and https?  On my OpenHab, these are not standard either, it runs on port 8080 for http.

 

This does not currently need an apache server no, there is no web component, everything is done from the command line. If you look at the README on the code page it should talk you through step by step how to install everything. Basically on the Raspberry Pi you would need to run the following command first. This would install git which you need to clone the repo, mysql database server which you need to store the location data, python which is the language that the script is written in and pip which is the tool that installs all the other python libraries you need to get it running.

sudo apt-get install git-core mysql-server python python-pip

As for the 1 port, yes that's the only port you need and you can configure it to anything you want... so if your ISY uses alternate ports, you can set it there. It only needs to use one or the other HTTP or HTTPS and it will make the connection and whatever port you specify. In my case, my ISY and the script run on the same network, so there was no need to use SSL (HTTPS), but I have tested it and works fine that way also.

 

As for the OpenHAB part, there currently is no functionality in the script to set OpenHAB variables and such, I would need to build that and include it... which with a little help/time I'm sure can be done pretty easily, but for now you can def get the into into your ISY

 

Also curious about your script that runs on your router.  I have an Asus as well and wouldn't have an issue installing a new firmware if I can get some benefits from that as well.  One of the things that I am looking for is a way to see if some devices are connected to the router (via MAC address i assume)  One of my goals is to be able to let my ISY (Openhab) know if I am working from home.  Detecting the MAC address of my work laptop and updating a variable would work fine.  Any ideas if this could be accomplished with such a script? 

 

Regarding the WiFi proximity script, that's nothing more than a bash shell script. That has the ability to track multiple devices by their MAC, so you could set it up to check the MAC for your phones, as well as your laptop and it uses a single ISY variable for each, so yes you could surely track your work laptop as well as your phones on WiFi and I'd be happy to share the script with you. I would just have to remove personal info from it and post it to another public repo. The important part there is that you have a router you can run a bash shell script on... take a look at OpenWRT, that's exactly what I'm running now and once you get that going, you'll need to get the "screen" or "tmux" commands installed and working on the router also. Either of these allow you to start the script, then disconnect and have the script run in the background. I use tmux myself.

 

Go ahead and give it all a shot and when and if you get stuck someplace, let me know and I can help you through it.