Jump to content

iOS / ISY Proximity Script


Steven M Castano

Recommended Posts

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, windows here too. Where does it writes the log file? I don't see it in the directory with the conf and tools folders.

Link to comment

Yes, windows here too. Where does it writes the log file? I don't see it in the directory with the conf and tools folders.

 

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.

Link to comment

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.

There should be quotes around the @ in username?

Link to comment

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.

Link to comment

Talk about a fast and accurate reply!  0.17.2 appears to have fixed the Windows python issue.  Ok, now time to play.

 

1.) On Windows, I will have to figure out how to run the script without it running in a Command Prompt window hopefully.  And upon reboot etc.

2.) So far no updates/changes made in ISY, but I haven't left the house yet to change the Distance Var.  MYSQL is looking really good.

3.) So in my programs, if distance is < 1 and (1 being a mile).... execute.  I think I understand this.  MobiLinc & Locative its been either 0 or 1.

 

I appreciate the amount of settings you put into this.  The wifi & bluetooth presence will be a plus.  v5.0.* will help once I'm ready to commit.

Link to comment
1.) On Windows, I will have to figure out how to run the script without it running in a Command Prompt window hopefully.  And upon reboot etc.

 

 

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! :-P

 

2.) So far no updates/changes made in ISY, but I haven't left the house yet to change the Distance Var.  MYSQL is looking really good.

 

 

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.

 

3.) So in my programs, if distance is < 1 and (1 being a mile).... execute.  I think I understand this.  MobiLinc & Locative its been either 0 or 1.

 

 

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.

 

I appreciate the amount of settings you put into this.  The wifi & bluetooth presence will be a plus.  v5.0.* will help once I'm ready to commit.

 

 

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.

Link to comment

This is easily one of my favorite additions to the ISY. I've never been thrilled about outsourcing my geofencing to IFTTT and now I don't have to. I'm probably most excited about the [future] prospect of tracking multiple locations (home, work, gym, etc.) and using those to delay certain programs such as heating and cooling. A few other requests would be the ability to pass lat/long to the ISY as variable as well as battery percentage. I would use the battery percentage alongside the Alexa Tell Me functionality. Passing lat/long could be a substitution for multiple location support I suppose. I also noticed that icloud.com now has the find my friends app. Would be cool to incorporate that in a future release. 

 

In the interim, I'm considering running three instances of script and triangulating my position from 3 different fixed points. (2 mi from A, 3 mi from B, 5 mi from C = work)

Link to comment

I have to say that this works very well, I was able to successfully, without any issues my location and home presence.

But am I the only one that sees severe battery draining issues?   I've tested this for several days.  When the script is running, not only my phone but my Apple watch drains way before the end of day.  My phone dies mid afternoon and my watch goes into low power consumption mode around 6PM.  I left it running for a couple of days and same issue.  I stop the script and everyhting goes back to normal and get a full day of use from both my phone and my watch.   I decided to repeat the process again and be mindful of using my phone ... and then I see the same battery issue.  Stopped the script a couple of days ago and back to normal.  It may just be me.

Link to comment
This is easily one of my favorite additions to the ISY. I've never been thrilled about outsourcing my geofencing to IFTTT and now I don't have to.

 

 

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! :-P)

 

I'm probably most excited about the [future] prospect of tracking multiple locations (home, work, gym, etc.) and using those to delay certain programs such as heating and cooling.

 

 

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.

 

A few other requests would be the ability to pass lat/long to the ISY as variable as well as battery percentage. I would use the battery percentage alongside the Alexa Tell Me functionality. Passing lat/long could be a substitution for multiple location support I suppose.

 

 

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.

 

I also noticed that icloud.com now has the find my friends app. Would be cool to incorporate that in a future release. 

 

 

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?

 

In the interim, I'm considering running three instances of script and triangulating my position from 3 different fixed points. (2 mi from A, 3 mi from B, 5 mi from C = work)

 

 

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.

Link to comment

Next up a reply to Bernie regarding battery life....

 

I have to say that this works very well, I was able to successfully, without any issues my location and home presence.

 

 

This is good!! I'm glad you got it working!!

 

But am I the only one that sees severe battery draining issues?   I've tested this for several days.  When the script is running, not only my phone but my Apple watch drains way before the end of day.  My phone dies mid afternoon and my watch goes into low power consumption mode around 6PM.  I left it running for a couple of days and same issue.  I stop the script and everyhting goes back to normal and get a full day of use from both my phone and my watch.   I decided to repeat the process again and be mindful of using my phone ... and then I see the same battery issue.  Stopped the script a couple of days ago and back to normal.  It may just be me.

 

 

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.

Link to comment

Steven,

 

Can you explain in some detail the expected values for BT & Wifi?  Not sure I fully understand what its comparing.

 

And maybe how the WIFI and Bluetooth works.  Say I'm at home and on my known wifi SSID, it now sleeps to 300 seconds.  But I'm at work and on wifi (distance = 7)... so it does 300 seconds too?  How does Bluetooth work... say an echo paired at home and then bluetooth in the truck, and bluetooth dock at work.  So 300 seconds in truck, but since not on wifi, back to 60 seconds?

 

Thanks

Link to comment

Steven,

 

Can you explain in some detail the expected values for BT & Wifi?  Not sure I fully understand what its comparing.

 

And maybe how the WIFI and Bluetooth works.  Say I'm at home and on my known wifi SSID, it now sleeps to 300 seconds.  But I'm at work and on wifi (distance = 7)... so it does 300 seconds too?  How does Bluetooth work... say an echo paired at home and then bluetooth in the truck, and bluetooth dock at work.  So 300 seconds in truck, but since not on wifi, back to 60 seconds?

 

Thanks

 

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:

 

H39uLFI.png

 

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:

 

SSHV8Rb.png

 

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.

Link to comment

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)

 

lPfknwP.png

 

So... I'd say sorry for the LONG winded explanation... but really, you did ask for it! :-P hahaha

 

Do this start to make a little more sense now?

Link to comment

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,

Link to comment

Thanks for the new feature! I have mine working now. I use the battery percentage along with the Alexa Tell Me skill so I can just ask what level my battery is if I have it plugged in somewhere else in the house. But I am also considering a notification to remind me to charge it if it gets below a certain level (10%, 5%). 

 

Here's the how to on setting up the Alexa tell me skill:

http://forum.universal-devices.com/topic/19749-how-to-guide-getting-alexa-to-provide-verbal-responses/ 

Link to comment

Well, seems like I have a lot of reading to do ... haven't had a chance to catch up.  I will most likely try to upgrade first, then work on getting a little more from my battery with some of the suggestions that you mentioned above ( will read a little later)

 

I'll then give it a good shot testing with OpenHAB and see where this leads me.  I may need a little help on the configuration.

 

Quick question for out (out of left field) ... have you ever taken a look at Home Assistant?   https://home-assistant.io

It's been discussed on this board and actually has a component that hooks to the ISY.  I had seen it before, but someone from the OpenHAB community sent me to take a look in regards to a wifi module for my new Roomba vacuum cleaner.  Seems like Python is popular with this system.   So I'll be building a Pi3 next weekend and will run it in conjunction with ISY and OpenHAB.  They both have their pluses and minuses ... but more than likely I will choose between the 2 to complement the ISY.

Link to comment

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. 

 

Question on this before I do it... if I do run 3 separate instances of the script, does this mean it will be checking my location 3X as much? Just trying to think about battery implications since that has been an issue for some. 

Link to comment

Question on this before I do it... if I do run 3 separate instances of the script, does this mean it will be checking my location 3X as much? Just trying to think about battery implications since that has been an issue for some.

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

Link to comment

 

 

1) Install the dependencies listed above

2) Clone this repository to your local computer/server

3) Install MySQL and create a database to store your location data

4) Run pip install -r requirements.txt to install all needed python modules

 

(pretend like i'm a little kid that doesn't understand this stuff at all)   :-P

 

I did number one and they seem to have installed.  I used MariaDB

 

I'm not sure how to do numbers 2, 3 and 4.  

 

should I give up or is there another (dumber) explanation for how to do this stuff.  

Link to comment

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.

Link to comment

Steven:  I appreciate your  assistance with this.   

 

I am using Windows 10.  I have thus far installed: GitHub, HeidiSQL, MariaDB and Python.  Quite frankly, I'm not completely sure what any of these things really are or do.

 

on this:

 

 

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/s...-Proximity.git"This will pull all the files from the repository and put them in a directory called "ISY-iCloud-Proximity"

when I click on the above https:// link, it takes me to the gibhub page of stevenmcastano and then I click the green "clone or download" box and then click "open in desktop" and then that causes my "GitHub" to open with what I believe is a repository called "ISY-iCloud-Proximity".    So I guess that I've accomplished this number 2 step here.  

Link to comment

Steven:

 

as far as this step goes:

 

 

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.

can you expound on how to do this using GitHub, HeidiSQL, MariaDB and Python?  I don't understand what you mean here.  thanks again, Steven.

Link to comment

Steven:  I appreciate your  assistance with this.   

 

I am using Windows 10.  I have thus far installed: GitHub, HeidiSQL, MariaDB and Python.  Quite frankly, I'm not completely sure what any of these things really are or do.

 

on this:

when I click on the above https:// link, it takes me to the gibhub page of stevenmcastano and then I click the green "clone or download" box and then click "open in desktop" and then that causes my "GitHub" to open with what I believe is a repository called "ISY-iCloud-Proximity".    So I guess that I've accomplished this number 2 step here.  

 

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"

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...