Steven M Castano

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.

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!

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.

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!

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.

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.

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.

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.

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.

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.

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

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.

It's called ha-bridge. It basically emulates a Philips Hue bridge and lets you name the "bulbs" anything you want then let's you run whatever commands or make whatever web calls you'd like when that light is trigger and it does accept "turn up, turn down, lock, unlock..." etc... as commands also. Check it out: https://github.com/bwssytems/ha-bridge

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.

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

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.

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!

I haven't personally figured out how to say "Alexa, turn on the lights" and have it know which Echo picked it up so it only turns on the lights in that room yet, but I'm working on it. As for it being compatible. Yes, there are a few Alexa skills that will link you to the UDI/ISY portal, one that can be used with the smartphone all MobiLinc and my preference which is to run an Philips Hue emulator called ha-bridge and let the Echo detect all the lights. The big difference between them is the "skill" way of doing things you need an activation word, for instance I was using the MobiLinc skill, so I could have to say "Alexa, tell MobiLinc to turn on the kitchen lights" and now with the emulator, I can just say "Alexa, turn on the kitchen lights." It even supports brightness control so I can say "Alexa, turn on the bedroom lights to 25%" and sure enough, it turns them on exactly how I said. Take a look at the documentation on how to set up the emulated devices, how to use the UDI API and how to use brightness control, but it does work and with it you can basically control anything.

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.

@memphis2k: ISY iCloud Proximity that's the github page with the code I just posted yesterday... it works great, but I'm still adding a bunch of stuff to it, you'll see in the description. And here's a link to the forum post where I first put it out there: http://forum.universal-devices.com/topic/19793-ios-isy-proximity-script/ I can copy the WiFi proxy arp bash script I have and post it somewhere as well if people are interested. Bluetooth is a little more involved, but I'd be happy to help anyone that would like through it for a bit and see if I can generalize and adapt the code for you.

That's awesome... in that case, i can't wait to try it!!! As for the backup advice... noted and for sure it will be done. I'm super anal about it anyway. I take a backup every time I log in to change basially anything. I think I have my entire 3 - 4 years of ISY backup zip files sitting here all the way back to my first 4 devices and 2 scenes! hahaha

Well ok, that's good to know... maybe that will be tonight's project then. As long as my current integrations still work I'm all set. As for the decimal values, match, while loops, etc... do you mean that stuff is NOT in v5, or it *IS* in v5?? Because I would LOVE all of those things!! My iCloud proximity script would get even that much more accurate, I'd be able to add light levels/variables together and control other devices, read temps better, etc... Right now I basically filled all of that stuff in by writing a python app with a web interface/api of it's own... so I have a few network resources that do things like matching brightness on philips hue devices... for instance, I have one script that works like this: In my living room, when I turn on a lamp connected to a keypad linc in an enclosure sitting on an end table, I have a program that watches the switch, anytime the switch is pressed on, off, fast on, fast off, dim, brightened, etc... it triggers a network resource that makes a call out to my "processing script" like http://myscript.athome.com/api/light/livingroom which triggers the script to then hit the ISY API and read the current brightness of that dimmer for the next 30 second, reading it 4 times a second, converting the math over to the right brightness value to match and hitting the Hue API to control a group a lights across the room. If I had better math, loops, variables, etc... I might be able to do that in the ISY without the external calls. That would be awesome!

I'll have to go back and collect up all the links, but I basically have all of this working for you and it's been running strong for years. I run openwrt on my router and have a script that will check for wireless devices on wifi and is fully configurable with mac addresses and IST variable numbers. I also have another script I wrote in Python that will used Bluetooth on a raspberry pi to look for devices as well. AND I just posted new code yesterday with a link in a post on this forum to another Python script I wrote that uses the iCloud API to do an actual real geofence and look up your phones exact location and update a variable on the ISY with your relative distance to home. I used all 3 together and it's totally rock solid, I've been running the wifi and Bluetooth for 3 years plus that way and my new iCloud script for a few weeks and it's working great! Sent from my iPhone using Tapatalk

Ok, so no Z-Wave isn't a problem for me either, I'm not using it either. @MWareman, is it that rough? Will I really be creating problems for myself by switching?

So I'm really interested and getting some stuff running with Polyglot, and potentially even developing some plugin/modules for it as well, but from what I can understand from reading, it only works on ISYs running v5.0.2 or higher, right? Right now my entire home automation control basically revolves around my ISY controller. Proximity detection, heating/ac control, security, locks, even controlling thing polyglot already covers, most importantly philips hue lights... but like a lot of other folks here my network resources list has become HUGE and almost unmanageable and I'm having to make certain sacrifices in controlling things the way I want just to keep the list and the number of programs to a reasonable level.... hence my interest in moving to Polyglot to handle those things. So, the question at hand is... how stable IS v5 of the firmware and is there anything I should know before upgrading? Will anything big be changing? Especially anything with the API since that's how I have HomeKit for my iOS devices and all my Amazon Echo's integrated. I'd hate to break that functionality.