iOS / ISY Proximity Script

[Steven M Castano]

I've been working on a new project written in python that basically hits the Apple iCloud API (now support two factor authentication enabled accounts), grabs your iOS devices current location, computes it's distance from the GPS coordinates of your home, then uses the ISY API to store that distance as a variable. You can imagine all the options you can use this for from there!!!

 

It's main features are:

• Reads an iOS device's GPS location, computes it's distance from home and stores it as an ISY variable
• It can report the distance from home in miles with up to 8 decimal points of precision (Can be done via an optional multiplier on firmware below v5.0.x that doesn't support variable precision)
• It's outputs a table of data showing its values, distances and updates to the screen as well as stores the data in a MySQL database for your own review later
• Optional: it can read other ISY variables to check to see if your device is present on WiFi or within range of a bluetooth sensor (this reduces battery drain by not checking the API GPS location when the script already knows your device is home)
• It varies the time between updates based on your distance from home, so the the rather you are away from home, the less often it attempts to read data, again to save battery life
• It can optionally read your location more often if it senses you are getting close to home to attempt to ensure your variable it updated all the way 0 before you actually walk in your door.

The code is coming along nicely. There have been a few releases already and a few suggestions from this thread already incorporated. The code and write-up is on GitHub at: ISY iCloud Proximity

 

*SMC

 

From here on out, I will update this first post with all changes and releases as they're pushed to the public repo, but as always, you can use the link above to get to the GitHub page and get the latest code and read the latest release notes.

 

Changelog:

(If you want to see more of this info all the back to the first releases and/or the most current info if this post falls behind, be sure to check the GitHub releases page for this project)

 

 

**11/14/2016 - Version 0.18.0 Released:

Added:

• Auth config file integration: No more copying settings back and forth between .ini files when a new release comes out. The script now reads your current iphonelocation.ini file, backups it up for you, adds the new features needed, and restarts the script with all the correct previous settings.
• openHAB Integration: The script can now connect to an openHAB instance and report it's distance at full precision (8 decimal places). This new feature is turned off by default.
• Battery Level Reporting: Requested by a user, the script can now report the current iOS device battery level to the ISY in a variable. Settings are in the advanced area under the [general] section. This new feature is turned off by default.

Bug Fixes:

• There was a condition missing from the "from_cell" data validation function that took a few tries to fix. The script reported a false warning if Cell location data was set to be allowed and the data did, in fact, come from a cellular triangulation. The script would continue, but with a warning. The erroneous warning message is now corrected.

 

 

**11/14/2016 - Version 0.17.2 Released:

Fixed: -- ***NOTE: Please make sure you run "pip install -r requirements.txt" again to catch added packages.

• Code to create pid files properly on Windows machines to avoid script crash.
• Code to check for script updates will continue after error to prevent script crash.
• Added the python mysql driver to requirements.txt (Needed for windows users)

 

**10/25/2016 - Version 0.17.1 Released:

Fixed:

• Added appropriate spacing to reflect the increase in precision of distance from home calculations.

**10/25/2016 - Version 0.17.0 Released:

Added:

• Forced GPS rechecks: This means that if you're using Wifi or Bluetooth checking, by default the app will now check your GPS location from the iCloud API once every hour even if your location radio systems can see the device. This is to catch crash local detection apps that have left your device in a "home" state. This can be disabled in the .ini file, and the frequency with which the forced checks occur is also configurable.
• Battery level retries: Previously the script would try to read your batter level once and move on. Now, by default the script will try to read your battery level from the API 3 times with 30 seconds between each try before moving on. Again, this check can be disabled and the number of retries and sleep time is configurable in the .ini file. *Version checking: Instead of just relying on forum posts and/or emails from github, the script will check once every 6 hours to see what the latest publicly availible version of the script is and let you know in your screen data table and debug logs.

Fixed:

• Mismatched cell phone location rejection rules: The conditions to validate if location data came from Cell vs. GPS of Wifi had a small logic error that cause some cell locations when the API reported them as not being "old" to be used even before the max number of retries had expired.

 

**10/18/2016 - Version 0.16.1 Released:

Added:

• Code now outputs the raw data returned from the API when reading battery level if check is enabled to allow for better understand of percentage calculation if there is an error.

Fixed:

• Added the proper code to read boolean values from the .ini conf file. Now any config item that can be turned on or off will accept (case insensitive) "true, false, yes, no, on, off, 1, 0" as acceptable values.

 

**10/13/2016 - Version 0.16 Released:

Added:

• Battery monitoring has been added. By default the script will check your battery level when it updates it's GPS data and if the battery is below 15% it will sleep for 1 hour, or however long the variable distance sleep time is, whichever is longer.
• This feature is turned ON by default.
• All configuration items for this feature have been added to the end of the .ini.sample file, if you'd like to turn it off, simply change the "battery_check" setting to "False"

Fixed:

• Changed logging level for a few GPS validation checks, isOld warning now only appear if you exceed retried and old data must be used.

 

**10/2/2016 - Version 0.15 Released:

Added:

• You can now set in the .ini configuration file to ignore any GPS data that comes from cellular triangulation and only accept the more precise data that comes from Wifi, GPS or GPS-Course.
• This feature is turned OFF by default.
• All configuration items for this feature have been added to the end of the .ini.sample file.

Fixed:

• Changed logging level for GPS data validation checks that are configured to be ignored from a warning to a simple debug message.

 

**9/30/2016 - Version 0.14 Released:

Added:

• Added code to api_login function to handle iCloud accounts with two factor authentication enabled

Fixed:

• Added import for the python "click" module to use proper prompts for 2 factor authentication
• Added "click" version 6.6 or higher to the requirements.txt for install

** Notes:

• Be sure you either run a `pip install click` or a `pip install -r requirements.txt` to confirm you have all packages needed as at least 1 has been added by this release

 

**9/29/2016 - Version 0.13.1 Released:

Added:

• Added code to check data returned from the iCloud API for the "isOld" flag indicating that the data iCloud has from the device may not be current. By default the application will now retry 6 times, sleeping 30 seconds between checks and if current data isn't returned, it will proceed anyway with any valid date it all. All the options, the sleep time, the max number of retries and rejection of the "isOld" data itself is all configurable in the .ini file.

 

**9/28/2016 - Version 0.12.1 Released:

Added:

• Updated the onscreen table display to show a "*" after any ISY value that was sent to the ISY. (Only changes from the previous distance value are sent)

Fixed:

• Moved reading location data from the iCloud API to it's own function and added error checking. The function now only returns data and an exit_code of 0 if a valid latitude and longitude are found.
• Moved the computation of the sleep time between update cycles to it's own function to clean up the main app code.
• Updated some DEBUG logging lines to be more descriptive.
• Removed redundant log lines after moving code out to its own functions.

Edited November 18, 2016 by Steven M Castano

[jtara92101]

This is brilliant!

 

All of the other solutions I have seen rely on installation of an app on the iPhone to check GPS, some augmented with checks for home network, iBeacon, etc. This turns everything inside-out.

 

I've been using Locative, and I have noticed that sometimes it momentarily decides I am not home when I am home, and so then there go the lights... Probably in part due to the fact that I live in a highrise, and GPS consistently puts me across the street at the Red Roof Inn.  (Which is still close enough for Locative to consider me "home", but a bit of drift and then it's too far away from reality.)

 

To be fair, Locative has other uses, as it can be used to set-up multiple geofences with different actions.

 

This script seems the ideal way to handle the specific issue of telling ISY if your device is home or not. No app needed on the device, easy to check if device is in Wifi range. Would seem to be minimal impact on battery life.

Edited September 8, 2016 by jtara92101

[Steven M Castano]

I've always been interested in how people were using Locative to make that work. I had been trying other geofence apps, including MobiLinc itself, Find My Friends, etc... and none of them really seemed to work. Sometimes after an iPhone reboot the app didn't restart, it might crash in the background and I never knew, etc... it was always very flaky.

 

@jtara92101, as for your specific situation, I would think you could tell your ISY programs to only mark you away once you're 2 miles away or something and that would resolve the issue of the "jumping" that happens with GPS. Mine does that same thing from time to time, if WiFi based GPS fails, since I also live in a high-rise it switched back to cell based triangulation and sometimes shows me a few blocks away in one of 2 or 3 spots. They just happen to be inside the 1 mile radius I've set for myself.

 

I could also write into the code that it doesn't consider a distance as changed when it's going from 0 miles, up until the distance is over 1 mile 3 times, that could eliminate a little bit of the noise... but also introduces some delay.

 

I'm stuck at my desk at work right now, but should be living soon and one more quick cleanup of the code and I'll have it posted on github in just a few hours.

[Steven M Castano]

P.S. A comment on battery life... on my jailbroken iPhone with enhanced battery stats showing all the system deamons, the GPS services that respond to the iCloud API GPS calls, which is actually the Find My iPhone service, running over the course of an entire 9 - 10 hour day at work barely 10 miles from home, which means lookups every 3 - 5 minutes, so that's an average of about 150 lookups while I'm away from home, only shows it's using 6% of the total power my iPhone has used and since it starts with a full charge every morning and comes home, on average at about 50% - 60% charged, that means this services is barely using 2 - 3% of my battery all day.

 

A simple tweak to check less frequently when I'm not home could lower that even farther, and since I am doing WiFi and Bluetooth proximity checking, when I'm home, the script doesn't even do a single iCloud lookup.

 

I also went camping this past weekend for 3 days about 80 miles from home, which meant the script was only doing a single lookup once every 40 minutes. On those days the Find My iPhone services showed up as using less than 1% of my total battery usage and it still increased it's lookup frequency as a drove home and sure enough, just as I was passing the 7-11 near my house, my phone popped up it's notification that the ISY had marked me as home.

 

I've been testing this for about a month now, there's really only 3 major roads to drive in and out of where I live and I can tell basically within a few blocks of where I should be getting the notifications that I'm home or away and it works every single time.

[Steven M Castano]

Ok, the initial code is pushed out to the github page, go ahead and download away... give it a shot and tell me what you think. Just do me a favor and any code related questions or issues that come up specific to the code itself, use the "Issues" section on github so I can track everything that needs to be done myself and so it might be consolidated and helpful to others in the future as well.

[Steven M Castano]

I just pushed new code changes (v0.8.1) so the script will check the iOS devices location more frequently when it detects you're moving closer to home. I also made all of the timing controllable by setting config options in the .ini file.

[rccoleman]

I'm excited about this!  I've been trying to find a reliable geofence mechanism it's been harder than I expected.  For some reason, IFTTT doesn't trigger for me most of the time unless I start the app (despite having "background app refresh" and location "always" allowed), so that's out.  Locative works much better, but I still routinely get multiple triggers upon crossing the geofence (either all the same, or sometimes is oscillates).  I'll give this a try and see if it works better for me.

 

Rob

[Steven M Castano]

I'm excited about this!  I've been trying to find a reliable geofence mechanism it's been harder than I expected.  For some reason, IFTTT doesn't trigger for me most of the time unless I start the app (despite having "background app refresh" and location "always" allowed), so that's out.  Locative works much better, but I still routinely get multiple triggers upon crossing the geofence (either all the same, or sometimes is oscillates).  I'll give this a try and see if it works better for me.

 

Yeah, I wasn't happy with app based location/geofencing either, that's why I wrote this. As long as you have "Find My iPhone" enabled on your phone this will work through the iCloud API.

 

As far as the "oscillation" goes, I haven't specifically put in any code to stop it, so I guess if you have the geofence set at 1 mile like I do and you were basically standing on nearly the exact 1 mile mark from your home location, it surely might bounce back and forth a bit. If that becomes a problem for you let me know ASAP and I'll add in some "hysteresis" type code that maybe only triggers updates when you're 1/10th of a mile inside or outside your geofence. In fact, I can probably make that variable controller as well. That way you only get updates to your ISY when you're surely inside or outside your chosen distance. That would stop the oscillating.

 

Let me know how things go getting it working and feel free to post issues and such right on the github page and I'll get them addressed ASAP. It should run great for you the way it is now, I'm currently running the same code I uploaded this morning and it's working great!

[Steven M Castano]

Just pushed another release (v0.9) with at least 1 important bug fix. In the previous release the math was wrong when computing your change in distance from one GPS reading to another and it confused the app into checking your GPS location LESS frequently when you were approaching home and more frequently when you were moving farther away. That's been correct and the behavior is as expected when. By default when the app detects you have moved at least 1 half mile closer to home since the last check, it cuts the sleep time between checks in half. This way you can't outrun the GPS check and get home before the next check cycle.

 

Another bug fix was in relation to the ISY not being availible. The code to read from the ISY would crash the app if the connection timed out. Now it returns an error code and simply waits to do another update cycle.

 

I also added variables for the WiFi and Bluetooth checking so you can control what value the app expects to see in an ISY variable to know if your iOS device is on WiFi or in Bluetooth range.

 

As always, feel free to comment here and/or post in the issues section on GitHub if theres anything that isn't working properly or features you'd like to see added.

[Steven M Castano]

More updates just pushed (v0.10) to fix a few issues and improve on a few others:

 

Functionality Change:

• iphonelocation.ini.sample now had WiFi and Bluetooth checking turned off by default
• The on screen table header of GPS info now redisplays after 20 lines of output

Improvements:

• Better more descriptive logging messages if there is an error reading the iphonelocation.ini
• Added debug logging to table header display interval counting

Bug Fixes/Code Cleanup:

• Moved all radio checks for WiFi and Bluetooth to it's own function
• Fixed logging message names for INDIVIDUAL_RADIO_CHECK and RADIO_CHECK functions
• Cleaned code and improved the look of the on-screen data table header

[Steven M Castano]

A quick fix was just pushed out v0.10.2, I had put the wrong variable name into a logging line related to computing the variable sleep time and it was causing app crash/restarts... and I didn't find it until I was traveling today myself. I've commented out the line and things seem to be going well... I'll test through the rest of my trip and when I get home I'll fix the code and push another update.

[rccoleman]

I set this up today and it looks like it should work for me.  I had to install some additional requirements (PyMySQL was one), but nothing too complicated.  It was also my first attempt to use MySQL, so that may prove helpful in the future.

 

One quick comment is that having the distance in whole miles is a bit coarse for me.  I'm using v5.0.4 on my ISY, which allows you specify variable precision, and it would be great if I could get at least 1 decimal place.  I'd like to be able to arm my alarm when I'm 0.5 or 0.25 miles away from my house, for instance.  I quickly hacked that by changing

exit_code, isy_status = isy_variable('set', 'state', device_conf['ISYDistanceVAR'], int(distance_home))

to 

exit_code, isy_status = isy_variable('set', 'state', device_conf['ISYDistanceVAR'], round(distance_home,2))

Now, to drive around a bit a try it out!

 

Edit: It looks like there are few more things that need to change, but I think I got them all now.  Back to testing!

 

Rob

Edited September 24, 2016 by rccoleman

[Steven M Castano]

I set this up today and it looks like it should work for me.  I had to install some additional requirements (PyMySQL was one), but nothing too complicated.  It was also my first attempt to use MySQL, so that may prove helpful in the future.

 

One quick comment is that having the distance in whole miles is a bit coarse for me.  I'm using v5.0.4 on my ISY, which allows you specify variable precision, and it would be great if I could get at least 1 decimal place.  I'd like to be able to arm my alarm when I'm 0.5 or 0.25 miles away from my house, for instance.

 

I'm glad it's going well so far... and yes, there are a few places in the code that would need to be changed in order to get the distances right including a few while reading in the settings but that's a great suggestion. I'm a 5.0.4 as well, so I'll start testing a few out, but here's how I could see it going:

 

1) I'll provide an option in the configuration file to specify how many decimal places precision you want reported to the ISY

2) I'll add another option for people who aren't on v5+ firmware and must use integers to be able to use a multiplier. So I can have the app take the distance, multiple it by 100, the report that integer to the ISY. So, for example, if you are 2.356783 miles from your home location, the app will use the multipler to make that 235.6783, clip it to the integer level of 235 and send that to the ISY. So effectively you are saying you would be 235 100ths of a mile away. This would be people on lower firmware the ability to also have more precise distance uses that just per mile.

 

I've got a few minutes of downtime, I'll get started putting some of this together right now. Look for an update soon... if not in a few hours, then Monday.

[rccoleman]

Sounds good, Steven. Thanks! It's working well enough for me that I switched my triggers to it and deleted my Locative geofence.

[Steven M Castano]

Sounds good, Steven. Thanks! It's working well enough for me that I switched my triggers to it and deleted my Locative geofence.

 

That's awesome, that's what I like to hear!!

[Steven M Castano]

Ok, version 0.11 has been pushed up to GitHub. If you look in the iphonelocation.ini.sample file I added an option at the bottom to configure the precision level that gets reported to the ISY. I've tested it with all values from 0 up to the max the ISY can support of 8 and it appears to work fine.

 

That being said, if the precision of the ISY is set higher than the app, the ISY fills in the back with 0's. So for instance, if you set the ISY variable to have a precision level of 4 and you get a distance of 43.123 miles, the app will hit the ISY API and report the 43.123, but it will show up in the ISY was 43.1230

 

I ran it through a few loops with different values and everything appears to be working like it should. Go ahead and push the new code and let me know how it goes.

[Steven M Castano]

Another quick release... v0.12, this one allows for a distance multiplier as discussed above. For people who are not on firmware v5.0.x or higher yet, you can have finer grained control of your distances. Since the ISY on the current production firmware can only handle integer values, you can now specify a multiplier like 100 so a distance of 43.12345678 miles as calculated by the app will be reported to the ISY as 4312. This effectively means that you are 4312 100ths of a mile from home.

 

So if you wanted to have program run when you're .25 miles (1/4 of a mile) away from home, you would configure the multiplier to 100 and set the ISY to run when the variable is over 25 since the distance of 0.25xxxxx would be first multiplied by 100 showing a distance of 25.xxxxxx, then reported to the ISY an integer dropping the decimal places and storing 25.

[rccoleman]

Hmm..  After updating to v0.12, the first iCloud request succeeds and any after that fail.  I worry a bit that it's because of the two-factor authentication that I have turned on.  When I first run the app, I get the normal "someone is trying to access your account - accept/deny" popup, I hit "accept", it gives me a six digit code to enter on the client, and I ignore it.  The app continued to be able access my account forever yesterday, but now it's failing after the first query.

 

Do you have two-factor authentication enabled?

[Steven M Castano]

Hmm..  After updating to v0.12, the first iCloud request succeeds and any after that fail.  I worry a bit that it's because of the two-factor authentication that I have turned on.  When I first run the app, I get the normal "someone is trying to access your account - accept/deny" popup, I hit "accept", it gives me a six digit code to enter on the client, and I ignore it.  The app continued to be able access my account forever yesterday, but now it's failing after the first query.

 

Do you have two-factor authentication enabled?

 

I actually do not have 2 factor authentication implemented in the app yet, so I'm fairly sure that is the reason. I could try to disable it and see if it starts working again. I don't use 2FA and I'm running v0.12 myself and it's working fine for 3 devices on 2 separate accounts, so I do imagine the 2 factor auth is the problem.

 

That being said, I think I remember seeing the documentation for the pyicloud library for python supporting 2 factor auth. That's the library my app is built on, so I might have to register an additional account, connect my test phone to it and enable 2 factor auth and try to build it into the app via either a command line prompt, or potentially a small web portal/config page... but that might take me a little while longer.

 

So for now, I would say if you want to keep running the app you'll probably have to turn off 2FA and I'll start working on the app to include it, publish some stuff to the 'dev' branch once I have something I think actually works and we can test it from there.

[rccoleman]

I thought that I'd be able to create an app-specific password for your script, but it's not accepting the one that I created.  That's supposed to be the answer for third-party apps, and I'd expect it to work just fine.

 

The more I look at this, I'm wondering if it's just a bug in the loop.  I get this in the log:

2016-09-25 09:48:42,519 - rpi3 iPhoneLocation(v0.12)[11999]: WARNING  - MAIN - Reading the iCloud iPhone location from API failed! Sleeping for 30 seconds.
Traceback (most recent call last):
  File "./iphonelocation.py", line 586, in <module>
    distance_home_delta = distance_home - distance_home_previous
TypeError: unsupported operand type(s) for -: 'float' and 'str'

on this line:

                        ### Determine the change in distance:
                        distance_home_delta = distance_home - distance_home_previous

I suspect that "distance_home" should be "distance_home_precision", and that's causing the loop to fail on subsequent executions, but changing that isn't enough.  I suspect that the error message that I'm seeing is not really accurate.

 

Edit: Got it working.  I changed "distance_home" to "distance_home_precision", as described above, and also added "float(xxx)" around the expression on 578.  Otherwise, it evaluates to a string and the delta calculation fails.  I think the "float(xxx)" change is the only one that's really needed, but I also wanted to do the delta calculation with equivalent significant digits.

 

Edit 2: See here for info on 2-factor authentication with pyicloud.  I added the code and it seems to work, but for some reason it doesn't seem to matter.  I can just leave this code out, ignore the 6-digit code that pops up on my Macs and it works fine.  I can't seem to make app-specific passwords work for this, unfortunately.

 

Rob

Edited September 25, 2016 by rccoleman

[Steven M Castano]

I thought that I'd be able to create an app-specific password for your script, but it's not accepting the one that I created.  That's supposed to be the answer for third-party apps, and I'd expect it to work just fine.

 

The more I look at this, I'm wondering if it's just a bug in the loop.  I get this in the log:

2016-09-25 09:48:42,519 - rpi3 iPhoneLocation(v0.12)[11999]: WARNING  - MAIN - Reading the iCloud iPhone location from API failed! Sleeping for 30 seconds.
Traceback (most recent call last):
  File "./iphonelocation.py", line 586, in <module>
    distance_home_delta = distance_home - distance_home_previous
TypeError: unsupported operand type(s) for -: 'float' and 'str'

on this line:

                        ### Determine the change in distance:
                        distance_home_delta = distance_home - distance_home_previous

I suspect that "distance_home" should be "distance_home_precision", and that's causing the loop to fail on subsequent executions, but changing that isn't enough.  I suspect that the error message that I'm seeing is not really accurate.

 

Edit: Got it working.  I changed "distance_home" to "distance_home_precision", as described above, and also added "float(xxx)" around the expression on 578.  Otherwise, it evaluates to a string and the delta calculation fails.  I think the "float(xxx)" change is the only one that's really needed, but I also wanted to do the delta calculation with equivalent significant digits.

 

For this, no the code was intended to stay as distance_home. Basically the app is being setup to do all it's distance calculations with the most precise data possible, which is the "distance_home" variable that carries distance out to 8 decimal places and it only uses "distance_home_precision" where it's reporting back to the ISY with less precision than that.

 

As for that line, that line is actually calculating the difference between your position now in relation to your position before, not your actual distance to home. The purpose there was so that when you're moving closer to home you can sleep for less time between cycles and not "outrun" the script. So for me, when I'm moving farther away from home or standing still, the script sleeps between cycles for half the number of minutes as miles. So on a recent trip I was just 240 miles from home, so my script slept for 120 minutes between reading my GPS location. Once it noticed me moving closer to home, which happened at about 180 miles away, it only slept 45 minutes before the next check instead of 90.... this way as I get closer to home the script is reading my location more and more often.

 

I know that part of the code works, I just tested it on my home about 30 minutes ago. As for the error message you saw, I think I found the cause. Apparently, when the script fails to read the GPS location from iCloud properly, the error code returned is coming out as a string instead of a number format which is why that operation failed. I can cast the numbers all as "float()" to avoid it, but I'd rather figure out what failed in the read and why the error code came out wrong. If you can look at the actual log file in the logs directory and grab the whole debug output leading up to that point that would be great, then I can see what failed and cause a string to be sent back instead of a number of some format.

 

Edit 2: See here for info on 2-factor authentication with pyicloud.  I added the code and it seems to work, but for some reason it doesn't seem to matter.  I can just leave this code out, ignore the 6-digit code that pops up on my Macs and it works fine.  I can't seem to make app-specific passwords work for this, unfortunately.

 

Rob

 

 

As for the 2FA, I just created a second iCloud account so I could start testing that and I'll jump on it in the morning. I do see a few things come up when I search on google for issues with pyicloud related to authentication, so hopefully one of them will have a fix for whatever is happening there.

 

 

 

 

Also, if the error message you were talking about above related to the distance_home_delta comes up every time you run the current version, let me know, I'll see if I can quickly figure out the error code return problem and push something out to the dev branch ASAP. I'm trying to recreate the problem here and I can't get it to fail like that... that's why I suspect it is related to 2 factor auth.

[rccoleman]

For this, no the code was intended to stay as distance_home. Basically the app is being setup to do all it's distance calculations with the most precise data possible, which is the "distance_home" variable that carries distance out to 8 decimal places and it only uses "distance_home_precision" where it's reporting back to the ISY with less precision than that.

 

As for that line, that line is actually calculating the difference between your position now in relation to your position before, not your actual distance to home. The purpose there was so that when you're moving closer to home you can sleep for less time between cycles and not "outrun" the script. So for me, when I'm moving farther away from home or standing still, the script sleeps between cycles for half the number of minutes as miles. So on a recent trip I was just 240 miles from home, so my script slept for 120 minutes between reading my GPS location. Once it noticed me moving closer to home, which happened at about 180 miles away, it only slept 45 minutes before the next check instead of 90.... this way as I get closer to home the script is reading my location more and more often.

 

I know that part of the code works, I just tested it on my home about 30 minutes ago. As for the error message you saw, I think I found the cause. Apparently, when the script fails to read the GPS location from iCloud properly, the error code returned is coming out as a string instead of a number format which is why that operation failed. I can cast the numbers all as "float()" to avoid it, but I'd rather figure out what failed in the read and why the error code came out wrong. If you can look at the actual log file in the logs directory and grab the whole debug output leading up to that point that would be great, then I can see what failed and cause a string to be sent back instead of a number of some format.

 

 

As for the 2FA, I just created a second iCloud account so I could start testing that and I'll jump on it in the morning. I do see a few things come up when I search on google for issues with pyicloud related to authentication, so hopefully one of them will have a fix for whatever is happening there.

 

 

 

 

Also, if the error message you were talking about above related to the distance_home_delta comes up every time you run the current version, let me know, I'll see if I can quickly figure out the error code return problem and push something out to the dev branch ASAP. I'm trying to recreate the problem here and I can't get it to fail like that... that's why I suspect it is related to 2 factor auth.

 

Fair enough on the first part.

 

Regarding 2FA, once I added the code from the link I mentioned, it asked me for the authentication code the first time and hasn't since.  I suppose that it now sees this rpi as "trusted", but it may time out at some point in the future.  I reverted back to the original distance_home_delta calculation and it's now working fine.

 

Rob

[Steven M Castano]

I fixed the error messages coming from times the app can't properly read location data from the API as well as fixed a few small things. I'm still working on 2 factor authentication, it's proving to be a little bit more of a pain in the a** than I thought! Anyway, here is the latest release:

 

**9/28/2016 - Version 0.12.1 Released:

Added:

• Updated the onscreen table display to show a "*" after any ISY value that was sent to the ISY. (Only changes from the previous distance value are sent)

Fixed:

• Moved reading location data from the iCloud API to it's own function and added error checking. The function now only returns data and an exit_code of 0 if a valid latitude and longitude are found.
• Moved the computation of the sleep time between update cycles to it's own function to clean up the main app code.
• Updated some DEBUG logging lines to be more descriptive.
• Removed redundant log lines after moving code out to its own functions.

[rccoleman]

I'll check this out when I get home. What sort of trouble are you having with adding 2FA? I just imported the "click" module and added exactly the code at the link I mentioned earlier. That let me pick the device and enter the the code that I received over SMS.

 

For what it's worth, the setup that I have now is working great!

 

Rob

[Steven M Castano]

I'm glad it's working well for you... that's what I like to hear. That's exactly why I release the code open-source and wanted other people to benefit from it! Are you using any of the other more advanced stuff, like checking for WiFi or Bluetooth presence?

 

As for the 2 factor auth, it could just be the new account I setup to test it since I haven't had 2FA setup on anything... but I'll giving it a try and more sure I get it right.

 

The updates I made today just took care of some housecleaning issues. v0.12 runs, and it kept running... I had already set any non-critical errors to basically just get skipped over and re-run the mail look so it would just pick everything up again. Now instead of letting the loop fail and re-running, it's actually checking for the data needed before continuing. This will stop any "ERROR" level messages and tracebacks and only issue warning that a know possible read problem has happened, it will sleep for 30 seconds and try again.

 

Also, I really wanted to add that little * into the table readout so I knew exactly when my script had been updating the ISY.