Jump to content

Steven M Castano

Members
  • Posts

    216
  • Joined

  • Last visited

About Steven M Castano

  • Birthday March 4

Profile Information

  • Location
    Washington, DC

Steven M Castano's Achievements

Member

Member (3/6)

5

Reputation

  1. 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.
  2. You should be good to go! Let me know how it goes! Sent from my iPhone using Tapatalk
  3. 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
  4. 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?
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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"
  12. 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.
  13. 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
  14. 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,
  15. 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?
×
×
  • Create New...