Steven M Castano

Are you running on windows also? As for the SyntaxError, that sounds to me like something in the .ini file might not be right. Can you check the logs directory and see if there's any output into the log?

Yes, you might find that a slightly larger distance than the 300 feet will work with much more reliability. Mine is set to 1/4 mile (.25) and it works 100% of the time. Yes, a multi-device version with multiple threads and a web interface will be availible eventually... right now I just wanted to get the framework and actual device/mathematical functionality done first before I work on making it pretty. Until the multi-device version comes out, you can do the same thing I've done to track multiple devices which is simply to just run multiple copies of the same script. I have mine tracking 6 devices right now, I just run everything 6 times! The data that's stored in the database is actually very small. I currently have just over 5000 records in my database and it's only 9.1M of data on disk. I hadn't thought about writing in a way to purge records, but it could be done. Or maybe just create a small command line utility that could be run every once in a while to keep only the last xxxx number of records or something. It's something to consider, but it's going to take a long time to build up enough data for it to really become a problem for you... probably years. From what I can tell, the code appears to be the same for the REST API into openHAB, so it should work on 1.8.3 also. I should have the next release ready in a day or two that will add the openHAB functionality so you'll be able to test it soon. I did catch that yeah, thanks for pointing it out. I've corrected it in the development branch of the software so it will get updated fully after the next release, until then I've manually edited the only version and corrected the spelling. And no problem, I'm glad you're finding it useful and that it's working well!!

Ok, so first is getting the distance control you want. Since you're on the v4.x.x series firmware, your variables can't do decimal places, they're whole integers only. So if you look in the iphonelocation.ini file you'll a setting names "isy_distance_multiplier", in the latest version availible to the public *v0.17.1", it's like 88 of the .ini file. The section reads as follows: # This multiplies the distance reported to the ISY by the value below. This is done for ISY # units running firmware earlier than v5.0.x so they can have more precise distance actions. # For example, if the setting below is set to 100, a distance of 23.12345678 miles, with the # above precision setting left set at 0, will report it's distance to the ISY as 2312. This # basically means your distance is 2312 100ths of a mile. isy_distance_multiplier = 0 So basically, for you to continue to use your "300 foot" distance, you need to increase that number. Since our ISY can only hold integers with no decimal place, this setting with basically just multiply whatever distance you are from home, by this number. According to my math, with a mile being 5280 feet, and you wanting things to happen at 300 feet, thats a distance of 0.05681818181 miles. So to get that level of precision, I would say you should change that value for isy_distance_multiplier to 1000. This is going to report your distances in 1000ths of a mile. So when you're 1 mile away, your ISY is going to see a value of 1000. In order to set things to happen at 300 feet, you'd want them to happen when your variable is at about "56". That would be "56 1000ths of a mile" or roughly 295 feet. So yes, this can be done the same way... and that's basically exactly how I do it. You would create a program that basically says "if my distance is greater than 56, set my geofence variable to 1", the build another program that says "if my distance is less than or equal to 56, set my geofence variable to 0" Then all the same functionality will work that you had programmed before. If everything is already triggers from that variable anyway, they'll keep working, you're just changing that variable from a different source. Does that make sense? I think the best thing for me to do here is show you what I'm running. Basically, you'll need to install supervisor to begin with with the command "apt-get install supervisor" Then you'll need to built a configuration for the script to run. This is nothing more than creating a text file with the info supervisor needs to run your program. You'd make it with the command "vi /etc/supervisor/conf.d/iphonelocation-steve.conf", and here is the content of my configuration file: [program:iphonelocation-steve] command=/usr/bin/python iphonelocation.py directory=/opt/apps/iphonelocation-steve/ priority=100 autostart=true autorestart=true startretries=3 stderr_logfile=/var/log/iphonelocation-steve.err.log stdout_logfile=/var/log/iphonelocation-steve.out.log user=root Basically this configuration file tells the supervisor services to change to the /opt/apps/iphonelocation-steve directory where I have the script installed (I have the "-steve" on there because I fun a few copies to monitor multiple devices), and then it tells supervisor to basically run the same "python iphonelocation.py" command you run to start the script, but it does this all in the background when the supervisor program starts. The priority isn't really important for you, it's used when you have multiple programs starting to control what order they start in, "autostart" obviously tells supervisor to start this program everytime supervisor itself starts "autorestart" tells it to try to restart the program if it crashes for some reason and the "startretries" tells supervisor to try 3 times before giving up. The log files capture the program output while it's running the background, and the user section tells the program to run as user "root". That pretty much does it, the only other thing I do is in the /etc/supervisor/supervisord.conf file I add a section to the bottom of the file like this: [inet_http_server] port = 9001 username = admin password = password This allows me to open up a web browser and go to the IP of my raspberry pi on port 9001, so "http://yourip:9001"and log in with that username and password and you get a little graphical interface to see if the program has started, what PID it's running under and it will let you look at the program logs its collected in the files mentioned in the application config. That's pretty much it. Just be aware though, that based on your previous post, it sounds like you might have to expand your 300 foot radius, or maybe adjust your home settings a bit because when you said you were first running the script, you were showing a distance of 0.108813 which would already be outside of your home radius. Also, 300 feet is a VERY close radius to see just based on your device capabilities. Even when I have a pretty solid GPS signal to my iPhone 6s Plus, the GPS accuracy get's show anywhere between 5 and 50 meters and when it's on GPS, the most common accuracy level is 65 meters. That's already 213 feet of your 295 feet... that's playing it pretty close. Unless you find tune your home distance so that you get basically the EXACT GPS coordinates, the script may either never think you're in the home area and/or bounce you in and out of it. I spent a good deal of time making sure I had my EXACT GPS coordinates for my house and even with that, while I've been home for the past few hours, asleep and not even moving, I'm showing distances from home ranging from 0.0109365076994 all the way up to 0.0593268414988 which would be enough that if you have your GPS radius set at 300 feet, your ISY would mark you "not home" with a reading like that. Most of the guys I've talked to including myself really run the script with the shortest distance for action being about 1/4 of a mile or .25 as opposed to where you're aiming for .05-ish.... it might be worth it to run the script for a bit, fine tune your GPS location for home, see how consistently low you can keep the distance readings, then use that to try to judge what the smallest radius you can run is. That's really a limitation of the phone and your GPS signal, not the script. While you're working on all of that, I'm working on getting v0.18.0 ready, which includes the ability to auto update and recreate your .ini file for you so you don't have to move setting over and it also introduces the ability to send the distance data to openHAB 2 which I've been running for about a week now without any problems.

You're doing pretty good so far!! What firmware are you running? The v4.xx series or v5.0.x??? As for running the script automatically, I'm a big fan of running either the program "supervisor" or "monit" to auto start scripts like this and make them keep running. As for the "0" being sent to the ISY, the because by default the script only uses distances to the nearest mile. So with a distance of .108 and change in the script that's going to report the distance as a 0. Once you get farther away, over .5 miles it will round up to show "1" as the distance. Once I know what firmware version you're on I can show you how to make that more precise. Sent from my iPhone using Tapatalk

I can surely take a look at the spelling correction... I'm not sure if it's the file I spelled wrong, or just the instructions, but I'll look at it ASAP. As for the files being empty, yes thats something you need to look at, as for sure, on the repo they are not empty. Regarding the username and password, if you look in the code they are not sent anywhere but to Apple to the iCloud API which obviously has those credentials already and while they are stored in clear text in the configuration file, they are only transmitted to Apple via SSL. As for the "call home" part you're talking about... I'm not exactly sure. Basically all the processing and such happens on your machine in the script, the only 2 outbound calls the script makes are: 1) To the iCloud API which sends your username and password over SSL to get your device location data and your device status data. 2) The script makes a single call to "updates.casta.no" which is my software versioning website, it sends no username or password, doesn't even send any location data, it just reached out to the website over SSL, sends NO data at all, but reads a text file with the latest version number of the script in it, so in the this case "latest.txt" at the time of this writing has just "0.17.1" in it and if you're on an older version it reads another text file from the same location called "urldata.txt" which is just the URL to GitHub where you can go to download the newest version and displays it on the screen for you. So, regarding your iCloud credentials, nobody get's sent those but Apple, nobody get's your location info but the script, and obviously since it's reading it from Apple, they have it already anyway and, through the API you're not able to make purchases, read credit card info or anything else like that either, it's just not something they allow over their public API. As for the credentials being in clear text, no ports are open to your Raspberry Pi, it's not allowing any connections in, so there really is nothing exposing your RasPi to the internet that would make it hackable. However, yes... if someone is on your home network and starts hacking your Raspberry Pi, knows your login and password to the Raspberry Pi, etc... they could in fact read your iCloud username and password, HOWEVER.... if there's some dude you don't know sitting on your couch with a laptop trying to hack a Raspberry Pi on your local network.... you probably have bigger problems then someone buying a few 99 cent apps before you change the password after the police leave. That's one of the nice things about open source though... the issues you raise are all out there for everyone to see. You can see all the code, see how everything works and are fully aware of everything the script can and does do at all times. If I was harvesting iCloud credentials or collecting users location info myself, people would be all over it and would have posted in here already that I a big scammer and to stay away from this script! So, not like "my word" really counts for anything, since you don't know me at all... but if you want to have someone else big into the code with more experiance, you'll see, the only data that gets "sent" from your script out to anyone are the things I mentioned above, your iCloud credentials have to go to Apple, who has them already, and the scripts reads a text file from my versioning website to see if it's running the latest version of itself. And even that last part doesn't really SEND me any info, it just reads the URL... mostly for use in future versions, which will be coming out in the next few days, that give you the option to "auto-upgrade" whenever you'd like by running something like "python iphonelocation.py --upgrade" which would download the latest version of the script, transfer your settings over to a new .ini file when features are added, show you a quick explanation on the screen of what those new feature are, then let you just go back to running things as usual. Right now upgrades are a little bit harder since you've got to manually move everything from one .ini file over to the new one when new features are added, the next version of the software to come out "v0.18.0" looks to avoid that, and in future versions, roadmaped for version "v0.19.0" or possible "v1.0" you'll have the option to turn on literal "auto-updates" where the script will just download new copies of the code on it's own, move your settings over to a new config file, always backing up the old one and totally restart itself so you'll always been on the newest version all the time. Bottom line here... there's noting to worry about. None of your data get's sent anywhere and the script doesn't expose the Raspberry Pi to the internet so it's not even acessible to anyone for them to attempt to hack it.

Ok, so I figured out how to pass info into items in OpenHAB via the REST API... so I'll be testing out some code shortly to see if I can get it all working well together. My tests worked great though, I was able to pass the distance in to a Number variable, add that variable to a sitemap and have it show up without a problem. I haven't really done much with getting info from the ISY to OpenHAB, it's more just been to create some switches in OpenHAB to turn on and off scenes in the ISY which I linked with the older legacy 1.7 version of the binding. It leaves a lot to be desired, but for now... I guess it's better than nothing. I haven't spent much time working on it, I just really wanted to build it to test this all out for you guys. As long as it all works, I can probably rename the project to just iOS Proximity something and put the options in the conf file to configure the ISY and/or OpenHAB.

I haven't forgotten about this at all... I don't use OpenHAB myself, but I just built a quick little OpenHAB 2 virtual server so I have something to test against and got it linked to my ISY as well as just grabbing some weather data, etc... I'm a little swamped, as I tend to be on Mondays, but over the next few days I'm going to try to API access you linked too above and see if I can quickly write in the OpenHAB support. I'll then push to the public repo on an OpenHAB branch for you to test with. Have you been able to get the original script up and running?? If you or anyone else needs a hand, if I'm at my desk... which is a LOT... I'm on IRC on FreeNode in #stevenmcastano and I'd be happy to talk you through anything you might need.

Very minor 0.17.1 released which fixes a display formatting problem with the on-screen table. It didn't have enough room in the distance from home column to accommodate the full precision of the new calculations. It's can now properly display up to 9999 miles with full double precision after the decimal point.

As promised, version 0.17.0 was just released, as you can see from the changelog and release notes, I added the forced GPS rechecks for people that are using the wifi and bluetooth checking, I find that one very useful myself. The big ones for everyone else are 1) The battery retries, the script can now make a few attempts and reading your battery level from the API before moving on.... and as always you can configure all of it. 2) Rejection of cell phone based locations. I know a few of you have had problems where when a location is report using the cell method, with the much lower accuracy, you were bouncing in and out of your home range. There was a little error in the script logic there where it would let a few of those cell locations be used even if the max retries had not been hit. That's resolved now and no matter what, the script will not move on and accept cell data for a location unless you've either not configured it to ignore cell locations, or it's run through is maximum number of retries. About the only thing I think I have left before bumping this up to Version 1.0 is to write in the option to have the script send popup notifications to your phone if your battery has run too low, or I guess I could even have options for it to send messages when you enter and leave your home location as well, maybe even let you know there's been a version update. Or... anything else you guys can think of while I've got some free time. Suggest away!

Just a few more additions coming soon. I'm testing them right now. 1) I added the ability to retry reading from the API if at first a valid battery reading isn't returned along with the variables to set the max number of retries and the time to sleep between them 2) I added the ability, for those of you who use wifi and bluetooth checking to force a GPS check every however many number of seconds as a backup. Just in case your wifi or bluetooth checking system has crashed and left you marked as home, you can now have the script check GPS, by default once every hour, just to make sure you're REALLY there. If there's anything else people are looking for, let me know now and I can test a few new features before the next release.

Sorry for the delay on this one, I was a little busy with work and some home projects over the last few days. Minor revision v0.16.1 has been pushed to the public repo and along with a logging fix on battery level checking, I updated the config file parsing code to read actual boolean values instead of strings. So now all of the following, "true, false, yes, no, on, off, 1, 0" are all acceptable values and are case insensitive. So place there is an option config item to turn something on or off, like wifi and bluetooth checking, battery level checking, etc... any one of those values can be used and the rest of the code has been adjusted to use proper boolean variables instead of string compares. Rob, thanks again for pointing that out! It's all set now.

You're totally write. Yes, right now "True" is different than "true", I just tested and verified it myself. I will fix the config parser in the morning so boolean values are not case sensitive. You're right, that would be much better. Sent from my iPhone using Tapatalk

We'll take the reply step by step... 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. 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 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.

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.

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?

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.

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!

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.

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.

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.

I run the OpenWRT firmware on my router, and I've previously run DD-WRT as well... and depending on your setup you may even be able to run the script on another host somewhere in your network, but that's a little iffy and sometimes doesn't really work. The best way to do it is to run something like OpenWRT on your router so you have the ability to SSH into and run shell scripts. I have an entire bash script written, probably about 150 lines of code so not TOO big, and basically it runs the "arp -a" command which shows the MAC address of every device that's recently passed traffic through it (usually an ARP entry sticks around for 3 - 10 minutes after the last bit of traffic is seen). It then uses the "grep" command to check the output for the MAC address of your phones wifi radio (which I type into the script before running it) and if it sees the MAC, it knows the device is on your network so it hits the ISY API and sets a variable to "1", then it keeps checking... mine checks once every 2 - 5 seconds... once it no longer sees the MAC address is starts counting, if it doesn't see it 3 times in a row, it sets the ISY variable to "0". So basically, now your ISY will know if your device is home and in range of your wifi or not... and I even have another script written in python that will do basically the same thing with Bluetooth. You put a cheap bluetooth dongle in a raspberry pi, then pair the phone to it and on the raspberry pi, set the device as "trusted". This allows the raspberry pi to hit the bluetooth radio of the phone without it being rejected. So there's a command line tool for bluetooth management of devices in linux called "hcitool", so I run the command "hcitool -a hci0 -n AA:BB:CC:11:22:33" (you'd be entering in the MAC of your smartphone there in a config file before running), and that command sends a name request out to the device of that MAC address. In my case, the name of my phone is simply "Steve's iPhone", so I just get the output from that command and scan the text, if the word "iPhone" appears, then the script knows I'm in range via bluetooth and it sets a different variable on the ISY to "1", as soon as it doesn't see the word "iPhone" anymore, or the command just fails if the device is totally gone, it sets the variable back to "0". The only hard part with bluetooth is that it has limited range... so in my case, I live in a 1200 sq foot condo, one centrally places raspberry pi is enough to catch my phone within range at the absolute corners of my entire place... the only place I've had it go out of range for testing was to put it under my mattress in the master bedroom all the way across the condo. However, at my brother-in-laws house, they have a 3 floor 3,000 sq foot place, backyard, garage, etc.... basically for him, we built 6 raspberry pi's, 3 of them are in different places in the house, 1 right back the back door and the other 2 out in the detached garage and shed. Each one of them is set to update a different variable on the ISY, so there are 6 possible "1" or "0" indicators. Then I wrote an ISY program for him that control a 7th variable based on the first 6. The first 6 are named BTSensor01, BTSensor02, etc.... and the 7th is named BTInRange.... and basically the program is pretty simple, it just says "If BTSensor01 OR 02 or 03 or 04 (etc....) == 1 THEN set BTInRange to 1 ELSE set BTInRange to 0" So basically, if any one of the 6 sensors can see the phone, the ISY knows it's in range. Based on just Wifi and Bluetooth you can have your ISY know if your device is home... with 1 slight caveat... smartphones, to save battery, will drop off of wifi a lot, and sometimes even power down they bluetooth radio, however... they do wake up every once in a while to do some quick checks, GPS, wifi connection, poll for email, verify they're own IP address, etc... I've seen iPhone stay off wifi for almost 30 minutes sometimes, and some androids up to 45 minutes. Bluetooth powers down much less often since it's so low energy anyway, it only shuts off for 2 - 3 minutes max from my testing on both iOS devices and Android based devices. So in order to really be used for "proximity" to tell your ISY if you're home or not... you pretty have to let the ISY know you're home immediately upon seeing either the wifi or bluetooth radios, BUT... if the sensors and scripts report to the ISY that they're gone, you have to program in a little delay... mine is set for 1 hour. If the ISY doesn't see Wifi or Bluetooth for a device for an entire hour, then it marks it as totally gone. That's the reason I started writing my GPS script... waiting for an hour isn't bad to turn off lights, change temp settings for your heat/AC, etc... but I wanted it to be much more sensitive so I could forward my work phone, lock doors, I even have it cut power to my computer monitors so nobody can even see the screen without plugging it into another outlook. I also have it set so if the ISY thinks I'm not home and any motion detectors get tripped, switches get turned on or off, or even door sensors detect an open outside door, it uses Network Resources to shoot a command over to my security cameras, snap a picture and email it to me.... yes, I'm a little bit of a security nut... but I wanted those things to happen right away, not 1 hour after I leave.... now with the GPS script enabled everything is on lockdown and secure within about 3 minutes of the last person leaving home.

If you can find me a way to poll and API at Google or something that can read your device location, I can make it happen for you. I've got a whole other thread on proximity detection and a well developing app that does exactly that. You also could use Bluetooth and wifi and means of checking to see if your home and have it turn on the lights.... that's how I was doing it for years before I started working on the iCloud API method. In fact I'm actually still using Wi-Fi and Bluetooth along with it. Sent from my iPhone using Tapatalk

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.

Not a problem, let me know how it goes!

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.