Steven M Castano

My guess here is that it doesn't like that you're writing to the root of the C drive... you could try "Run As Administrator".... start an admin command prompt then run the iPhoneLocation.py script. If that doesn't work, I can probably show you a few code changes so it writes the .pid file somewhere else... as well as just commend out the lines and not write one at all.

You should be good to go! Let me know how it goes! Sent from my iPhone using Tapatalk

No, it should run without a problem... you would just have to make sure all the python dependencies get installed. I don't think I've tested it on windows myself, but it's written in standard python 2.7. As long as you can get python and pip to install, it should work. Are you getting any specific errors? Sent from my iPhone using Tapatalk

Which script are you trying to run... the router based shell script that does the WiFi Proximity checking, or the python script that does the iCloud API checking for device location?

Sure, it'll run on anything. It doesn't even have to be linux, that's just where most people run it. There's a few guys out there with it running on Debian, I run it on both Ubuntu and RedHat, and I even wrote in Windows detection to the do the paths for pid file storage and such properly. So the only dependency is that you have to have an OS that can run Python 2.7 and any MySQL compliant DB to connect to. I was running on a Raspberry Pi for a while and a buddy of mine runs 6 copies of it at the same time on a Raspberry Pi 2 along with MariaDB to do proximity for his entire family and it runs fine at less than 5% CPU.

Sure, that could probably be done, but it's really just a python script, and I wrote it without many dependancies. Honestly, by the time you install the docker engine and everything else, you could just as easily just install mysql and python, in fact, most linux distributions will come with almost everything you need in python already installed. As for the influxDB, currently no it won't work. The python library used for the DB is specifically written for either MySQL or Postgres and the way the code has been written, the only driver and connection strings implemented are for MySQL. That being said, any MySQL compliant DB will work. I've personally testing MySQL 5.5, 5.6 and 5.7 as well as Percona and MariaDB and I run my production scripts on a MariaDB Galera cluster that I have installed already to support some other applications like WordPress, ownCloud and a few others. I have been thinking about writing an option into the script to stop the database storage of info anyway since all it's really used for is location history and some people aren't really interested in the history, just that the app is running in real time.

That's actually my script that I shared a long time ago! hahaha And yes, there have been some updates since then that allow for better checking on the ARP tables and such, but that should be enough to get you started. It's a general bash script, so any router firmware, OpenWRT, DD-WRT, etc... that you can run on a router, you'll be able to run this script. Mine even has some config options to change the arp commands and notification commands as needed.

I tried doing this for a while myself and found there's 2 major problems: 1) The ping response is just as flaky as the device staying on wifi. It won't respond to pings a lot of the times even when it's there... so you're still stuck with the same problem with the ARP method in that you have to account for temporary disconnects 2) Since a ping is an active part of the TCP/IP stack, the phone itself has to create the ping response and send data back. So you're actually asking the phone to do work. Work = battery = does dead faster. The ARP method is totally passive and really doesn't depend on the iOS device at all, so you still have problem number 1, but you don't even negatively effect battery life. I would still point you in the direction of a passive monitor. If you've got any way of writing a script on the firewall or mod'ing the router so you can run a bash script, then those are probably your best bets. You just have to make sure you're monitoring things from a location that ALL wifi traffic has to pass through. If you only have the one ASUS router as your only WiFi access point, that might be the perfect place to do it. Run OpenWRT on it and I can clean up and post the bash script I use to look at the ARP table.

Sorry, I vanished there for a bit... I've had a few crazy weeks. Now that you've created the database, you just put the database name and the mysql login and password in the iphonelocation.ini file and the script will take care of the rest of creating the tables and stuff you need. Then you can fill in your iCloud account instructions and keep following the instructions on how to list devices and select the one you want to use for GPS location.

With HeidieSQL you would connect to your database, so on your local host, and you can just create a blank database using the gui. Name it anything you'd like and use the name and the username and password you used in HeidiSQL to connect in the iphonelocation.ini file as your database setting. Your hostname would be either "localhost" or "127.0.0.1" then and the standard port of 3306 should be fine.

Ok, so for windows you might actually need to install the git client: https://git-scm.com/download/win With that you can run the command I listed above: "git clone https://github.com/s...-Proximity.git"

ok, so 1) depending on what os you're using, those are the packges you'll need to install. On Ubuntu or Debian that "apt-get install python python-pip" 2) You'll need git installed for this, again on Ubuntu or Debian thats "apt-get install git-core", to do the actual clone you'll do a "git clone https://github.com/stevenmcastano/ISY-iCloud-Proximity.git"This will pull all the files from the repository and put them in a directory called "ISY-iCloud-Proximity" 3) You have to do this using the mysql client, like "mysql -u root -p", then when prompted, give the mysql password you used when you installed MariaDB. The at the mysql prompt you'll type "create database iphonelocation;" and make sure you put the semi-colon in there. Then you can exit and you now have a blank database. 4) You change into the directory with the script, so "cd ISY-iCloud-Proximity" and run the command exactly as you see it "pip install -r requirements.txt" This installs the rest of the python packages you need. From there, continue on down the directions following each step very carefully and you should be able to get it up and working pretty quickly.

Yes, it would check the location 3 times... but if you use longer cycle times or the wifi/Bluetooth checking it should be fine. Sent from my iPhone using Tapatalk

So... the yet another version has just been pushed to the public repo: v0.18.0 With it comes 2 things that needed to change anyway: 1) No more manually moving config items from .ini file to .ini file every time I add a new feature or do an upgrade. I've put in a version control system to check your .ini file and if it needs to be moved up, it reads all your current settings, backs up and NEVER deletes your old .ini file, the rewrites a new .ini file with all your previous settings, plus the new ones that are needed at their default values which for almost everything will always be a new feature that by default is turned off. Once the upgrade of the .ini file is done, the script will automatically restart itself with the new configuration file in place. 2) A bug fix on cell location validation. Without a long winded description, I missed a validation check where you can have the script set to NOT reject cell locations and the location DID come from the cell method. Previously the script would warn you that the data "didn't pass the from_cell validation check" and continue running anyway, now the erroneous false warning has been corrected. Next up are 2 new user requested features: 1) User bernieb asked for openHAB integration. It's in there now. Very basic, but it's there. The script can now send the from home distance over to an openHAB instance with full precision out to 8 decimal places. I've got this running on a test installation of openHAB 2 and it works great. I have yet to fully test it on openHAB 1.7 or 1.8, but from the documentation of their API, it all appears to work the same way. Let me know if you have a problems. 2) User nathagt asked for battery level reporting. The script now has 2 new settings in the [general] section to turn on battery level reporting to the ISY and for what variable number to store it in. I also tested this on my ISY and have it working fine. I haven't figured out what I'm going to do with the info in my ISY... maybe turn my desk lights RED to remind me to plug in my phone if it get's under 30% or something... but, either way, ask and ye shall receive. It's in there. Also, you'll notice the .ini file has undergone a huge facelift... I commented the hell out of it with descriptions of each setting, examples of some of the math being done, etc... it should go along very well with my WAY too long posts from the other day explaining how a lot of the script works. The next thing I'm going to start a little work on is the ability to do automatic updates so people don't have to keep messing with things,

So, now... how this all ties in. Basically this part is pretty simple. With the ISY "sitting in the middle" getting updates on wifi and bluetooth, the GPS script can now read those states from the ISY and if the ISY already knows your home via bluetooth or wifi, it can skip the GPS check. Then, like I said, I have the script set, by default to check your GPS location once every hour even if it things your are "in radio range" as described above, just to make sure one of your scripts didn't crash while you were home and just leave you marked in range. In my ISY my GPS location takes precedence over everything. Even if my ISY variables say that I'm in wifi range and I'm on bluetooth, but a GPS update happens and says I'm 20 miles away, my programs all trigger there away state and even force the wifi and bluetooth variables to be marked that I'm NOT actually there. In fact, I even have alert programs on my ISY so that if the GPS location says I'm away, but wifi and bluetooth don't agree, it sends me an alert and tells me to check my wifi and bluetooth scripts when I get home because they weren't in sync with GPS. So with those options, the WiFiCheck and BTCheck turned on... basically, aside from the force check once per hour, which you can also turn off if you want, when I'm home I basically eliminate all GPS location checks which has massive battery savings. For comparison on an iPhone 6s Plus: 1) 24 hours of constant GPS checks, once per minute, costs ~25% - 30% of the battery 2) 24 hours of constant bluetooth checks, once every 5 minutes, costs about ~1% - 3% of the battery 3) 24 hours of constant wifi checks, once every 2 seconds, cost 0% of the battery So between methods 2 and 3, I save myself a lot of trouble. Basically, the whole thing kind of looks like this: (it's ugly, but it was quick) So... I'd say sorry for the LONG winded explanation... but really, you did ask for it! hahaha Do this start to make a little more sense now?

Sure, basically those variables have nothing to do with THIS script and the device info you can get from the iCloud API. Currently, you can't see bluetooth connections or wifi connections through the API. They're meant to work with OTHER scripts that check for those things for the purposes of saving battery life. If you don't use them, and keep all the default settings, the script checks your GPS position once every minute... even when you're sitting at home, which I already talked about in the posts above can have a bit of a negative effect on your battery. So the idea behind the WiFiCheck and BTCheck variables are to have the script read info from your ISY that another script may have put there and skip doing the GPS check if it finds the "expected" value. So here is an example. For wifi, I have an Asus home internet router that I run openWRT on (https://openwrt.org/). This gives me a mini linux operating system on my router that's capable of running the bash shell and tmux, and popular program that allows things to run after you've disconnected from your SSH session. So I have a script, similar to the GPS script that does my wifi checking for me. It works, at a high level like this: 1) You give it a list of up to 4 MAC address to look for. (the hardware address of the wifi radio on your phone) 2) You give it an ISY variable number to go along with each MAC, just like the GPS script 3) You give the IP/hostname, username, password, etc... of your ISY so it can make the updates via the REST API 4) The script then reads the routers ARP table which is a table of every MAC address of devices passing traffic through it 5) It scans that list for any of the MAC addresses you're looking for 6) If it finds one, it updates the corresponding variable you've set to "1" 7) When it no longer sees the MAC address on your network, it sets the variable back to "0" So with that, your ISY now knows if your smartphone (of any brand, iOS or android) is on your home wifi network. So when my script has the WiFiCheck turned on, it connects to the ISY and reads that variable. If it sees a "1" it sets a state in the script I named "iPhone_RadioInRange". (Yes, I will change this to iOSDevice_RadioInRange someday, I was just lazy since I made the first script for an iPhone). Then, basically once the GPS script knows your device is "in radio range", it doesn't bother to do a GPS check, so by default now it sleeps for 300 seconds (5 minutes), then checks that ISY WiFi variable again... and if you're still home on wifi, it just keeps skipping the GPS check. By default, in the advanced options, the script it set to do 1 GPS check per hour even if your script constantly thinks your device is "in radio range" which is done to just cover you if, for some reason, your wifi script crashed and left your device marked as in range. They're basically a backup to each other. Now there is 1 huge benefit to this, and 1 big problem (which can be solved somewhat) with this approach. The big benefit is that your router is doing all the work, the phone isn't even aware that it's happening so there is absolutely zero cost to battery life while this script runs. The BAD part about this whole thing is that, again to conserve battery life, a phone may drop off wifi for anywhere for 2 - 40 minutes and power off it's radio when nothing is happening... especially at night when your phone is asleep and doesn't detect any motion for a long period of time. Just for reference, in the last 24 hours, my wifi script has made 2,406 updates to the ISY according to my logging server. It sleeps for 2 seconds between checks when I'm NOT on wifi, and sleeps for 4 seconds between checks when I am. Here's what the script debug and update counters look like from my logging server: So as you can see, that little dip around what looks like 2am or so where there isn't much activity at all, that's when my phone was CONSTANTLY on wifi because it was doing it's normal nightly iCloud backup. Then you can see around 13:30 or so, a thick blue bar start and lasts a few hours... that was the script banging away every 2 seconds constantly with basically no variation because I left my house for a meeting in my office. This is one of the reasons I don't depend on wifi for my normal proximity. 1) Because when you first come home, you don't even have a chance of being detected until you're in wifi range, basically already in your home, and on top of that if your phone is in your pocket, sometimes it doesn't even try to connect to wifi for a few minutes, until you get an alert or until you pick it up and wake up the screen. Then 2) because it bounces OFF wifi so often, you can use it's wifi state "raw" to mean your home or not or your ISY would mark you from HOME to GONE and back and forth every few minutes and your lights would be flashes, doors locking, etc... etc... etc... think "full poltergeist mode"... that's not fun! So, remember I said 1 big problem could be solved somewhat? That's the problem. What I do is I have 2 variables in the ISY... one of them called "SMC_WIFI_PRESENT" that gets update like 2500 times a day... kind of useless... and the other is set by a program. I have another variable called "SMC_WIFI_DELAYED"... so basically every time the SMC_WIFI_PRESENT variable get's set to "0" to show my phone isn't on the network anymore a program called "SMC_WIFI_TIMER" starts.... and if left to run for 1 hour (the longest I've ever seen my phone NOT be on wifi and I'm actually home), then it sets the SMC_WIFI_DELAYED variable to "0"... that means I'm REALLY not on wifi anymore. If the timer program is running and the SMC_WIFI_PRESENT variable flips back to "1" since I'm back on wifi for a few seconds, it stops the program and cuts off the timer and that cycle repeats all damn day. So when I was using wifi for proximity checking alone, I knew when I was home within about 2 - 3 max of actually getting there, sometimes as I was walking up to the door, but to thing I was actually gone, took about an hour after I had actually left every time. Ok.... NOW... enter ALMOST the exact same idea, but with bluetooth... a little battery hit to the device, but FAR more reliable, and with Bluetooth LE, far LESS of a battery hit then checking the GPS position. So I have yet another script, running on a raspberry pi with a USB bluetooth dongle in it and it's set to run a command called "hcitool" in fact the exact command it runs is "hcitool -a aa:bb:cc:11:22:33" (with my real bluetooth MAC address obviously not aa:bb:cc....) and what that does is put a bluetooth ping out there in the world an ask the device with MAC "aa:bb:cc:11:22:33" to reply with it's name. Mine happens to be "SMC's iPhone". It then looks at the output of the command... if the word "iPhone" is in it, it updates an ISY variable to let the ISY know I'm close enough to be seen by bluetooth (about 55 meters). Then it sleeps for 5 minutes before checking again. Suppose I've now left the house.... then, when the script runs again, if it doesn't get back any output, or hits an error like "device unreachable" or "timed out", etc... it doesn't find the word "iPhone" it considers me NOT in bluetooth range, updates the ISY again to say it can't see me and only sleeps for 1 minute. Then it just hammers away and checks over and over and over and over again every 1 minute until it sees me, marks me home again, and sleeps for another 5 minutes. Here's another graph of what that looks like along with the number of updates from the last 24 hours: BOOM, that's pretty spot on... 2 updates... once when I left this afternoon, once when I got back this afternoon... and if you notice, the blue bump in activity in this chart, pretty much matches exactly with the bump in activity on the wifi chart. SO... I'm going to post this, then make one more reply tying these all together before this single update get's WAY too long.

Next up a reply to Bernie regarding battery life.... This is good!! I'm glad you got it working!! This is NOT just you... this is somewhat expected. I'm not sure about the Apple Watch part, I never saw that in any of my tests... but yes, running this script all day basically hammering away checking your GPS location once a minute will have a significant hit on your battery. I'm not 6s Plus, I saw nearly 24 - 30% of my battery being used by my phone while letting the script check GPS for an entire 24 hour period of which my position was always via Wifi. I think I wrote a post about this somewhere in this thread... maybe I need to make an FAQ and host it somewhere, or maybe add to the GitHub Wiki page or something.... but for the issue at hand, it goes like this: GPS lookup cost battery life in varying levels because the phone needs to wakeup to get the location and report it back. Normally, without the script running, your phone will do this every 10 - 30 minutes just based on normal iOS device operation. There are a few types of GPS location methods, I'll list them from "least battery hit" to "most battery hit" 1) GPS (normal lookup, clear view of the sky, signal from multiple satellites) 2) GPS-Course (GPS "almost" worked but was impeded a bit, still read satellite data, but may have missed a few so it's a little less accurate) 3) WiFi (GPS isn't working at all, probably because you don't have a clear few of the sky, but the phone is on or near of WiFi network that apple pretty much knows where it is) 4) Cell (This one is the worst. You don't have GPS or WiFi and your phone sends pings and measures signal strength to nearby cell towers and then does the math to triangulate your exact location) These methods also have a varied accuracy, which is why I show it in the script. GPS can range from 5 - 50 meters, GPS-Course is 30 - 100 meters, WiFi is very frequently 50 - 75 meters and Cell, again being the worse can be anywhere netween 100 and 1000 meters. So basically if you're indoors a lot and the script is pushing for your location info once a minute, you're probably getting WiFi or Cell location data which can be a little costly and that's why you're seeing the battery drain. This is exactly why I put the advanced settings in there. You can increase the time between GPS checks from 60 seconds up to something like 300 or 600 (5 or 10 minutes)... but this means even though you might want things to happen when you're 1 mile from home, the script might not check often enough and the scripts will still work, but they'll be delayed since you'll be at "0" miles meaning your home, then the next check might not happen until you're 4 or 5 miles away. Another thing that can be done is using the Wifi or Bluetooth monitoring in the advanced settings as well... so that when you're home, the script basically doesn't ask for your GPS distance at all, maybe once every hour as a backup to make sure your bluetooth and wifi sensing is working properly (this is what I do and it works great) The other thing you can do is vary your time between checks more when you're not near home. A lot of this depends on your location patterns/where you are all day. If you work from home, or work very close to home (within 5 miles), the default settings are going to ask for your GPS location once every 60 seconds... that could hurt a bit. If you're willing, you could share some of your location history and info/logs with me and I can help you fine tune the script so it doesn't have such a harsh impact. All the logic and math needed to make it easier is in there, you just have to dive into those advanced settings.

I'm glad you like it, and yes that was one of my big motivators... I didn't really like having someone else have my location data that I know for a fact sells it and has partners access for advertising and such. So yes, no you own your data, you and only you. (Until I release a cloud version of this monitoring service! ) The multiple location support is a little bit down the ways... I want to make sure I have all the kinks worked out with device checks, retried, variable updates, openHAB support, a good clean way of doing script updates, if not the option to even do them automatically, etc... once most of the junk is worked out, I'll get to doing the math so you can more efficiently check multiple locations with a single script. I can surely add in the functionality to send battery level over to the ISY, that's pretty easy as it's a single integer value from 0 to 100. As for the lat/long support, that's a little harder since the values are numbers with large decimal values. This would be easy on v5.0.x of the beta firmware that's out now since it supports precision, I could send the data over with up to 8 decimal places which would be pretty accurate. To do this on current firmware, the v4.x series, I'd have to use a multiplier again so your location would be sent over as a very large integer, for instance a location of 39.12345678, -72.12345678 would have to be send to the ISY as a latitude variable with a value of "3912345678" and a longitude variable of "-7212345678"... I've never tried that and I don't know if the ISY will hold numbers that large. It would be interesting to experiment with though. The API doesn't currently allow you to get friends GPS locations, that's only availible in the app. What would you be looking to do with it though? Yup, that totally works you could very easily run three scripts and setup a program with variable ranges to basically have an unlimited of position tracking points then only with 3 running scripts. This is much the same logic I had intended to implement for multiple location support in a future release. Something probably once the web interface is done to help people calculate the exact math they'd need to do the triangulation. That's a pretty advance concept for someone who isn't familiar with it. I'm glad the script is working out well for you though... keep the ideas coming and I will sure keep a list and try to get as many of them in there as possible.

This can get a little tricky on windows, but if you look there are instructions out there on how to make a command or batch file run as a servers and little helper utilities that will install them as a service and configure them to run on startup. Either that and ditch windows, but a Raspberry Pi for $35 and run it on there! You can always try to set the variable on the ISY to something like -1. The script is written so that the first time it gets a GPS location, it does an update to the ISY right away. So if you set the ISY manually to -1 and restart the script, it should set it back to 0. Yup, that's pretty much when I do. I have another variable called "is_home" and I have a program that checks all the other variables like distance from home, wifi and bluetooth presence, etc... and if the right combo of things is there, it set "is_home" to 1 and that triggers all my other programs. Not a problem at all.. I wanted to make sure the "defaults" basically ran out of the box without people having to play with it too much, but it still had enough options to really be flexible when people wanted to really dig into it. Once I know all the real core functionality and such works, I'll actually write a web interface for it, some auto-config options, etc... as well as support multiple devices, accounts and locations all from a single script. That's why I've been considering these last few shots as "pre-releases" it's basically super FUNCTION over ease of use. I'll make it pretty later. As for the wifi and bluetooth, you can use those under the v4 firmware as well... they work great, a bunch of guys are running that way. You can also dig into the "distance multiplier" settings if you want so you can have finer grained control than just 1 mile increments if you want. That works pretty well already too.

I've also just push release 0.17.2 which fixes the script problem with creating the .pid file on windows machines, but it also updates the version checking so the script doesn't crash if it can't reach the updates server. Also, make sure you run the "pip install -r requirements.txt" step again as another package needed to be added for windows users.

No, there should be no quotes anywhere in the settings. It should be formatted exactly as it is in the .ini.sample file [iCloudAPI] # Your iCloud username username = myicloudname@icloud.com # Your iCloud password password = c00lpa$$w0rd

I've got the code up on my machine write now and I'm patching it to handle the windows specific issues. If you guys are on IRC at all, I'm on Freenode in chatroom #stevenmcastano you can go to http://webchat.freenode.net/ if you don't have an IRC client installed on your machine.

If it gets to the part where it's going to write logs it writes to the "logs" directory which would be a subdirectory of wherever you're running the script from. If you're getting a syntax error and the script isn't even logging anything, that probably means, either you didn't install everything in the requirements.txt file, or there's something wrong with the way you entered your icloud credentials. There should be no quotes and really on the "@" symbol for your username.... I've honestly never tried with special characters in the password, I'm wondering if that could be a problem as well, I'd have to test... but I wouldn't think so.

Going back a few posts, I missed this one: Right now the script only monitors 1 device on 1 iCloud account with 1 "home" location at a time. However, you could very easily just copy the script or clone the script contents into multiple different directories and run it multiple times with different settings for each script. That's what I do monitor multiple devices right now. Multiple device support is planning for the near future, multiple locations is a little more complex, but I'm sure I can put it in there somehow. *SMC

I honestly think the problem you're having here is that I never designed this program to run under windows, so right at the start it's trying to write to a unix style path, that's what the trouble is. Just to get you up and running very quickly before I push out a fix, try this. Put a "#" (pound symbol, or hashtag as the kids are calling it these days... WITHOUT the quotes)... so put a # infront of lines 52 through 55, that will comment out the creation of the .pid file completely while I rewrite that part to detect windows and put it in a better place.