I just had to install the wazeroutecalculator in my ha venv and was good to go …
Great work on this!
I seem to have some weirdness/conflict with the native tracker & icloud3 (my guess…):
1:40PM iPhone is at home
1:37PM iPhone is away
1:37PM iPhone is at home
… other stuff in log
1:26PM iPhone is away
1:26PM iPhone is at home
1:24PM iPhone is away
Essentially, every time I leave/arrive into a zone, I get 3 entries in the log like the above.
Anyone else see this?
Thanks,
R.
Me too, it’s weird. I can’t use it this way. Because my alarm and lights are presence based. Now when i come home the lights turn on and back off again. Same for the alarm and then I trigger the alarm 
. Hopefully there will be a fix. In the mean time I’m switching back to icloud2.
I see similar. So far have three iPhones being tracked, each on its own iCloud account. In cases where there are retries, it does appear there are multiple threads running for each account.
One example is a a 15 second loop and a 2 hour loop going for the same device.
I’ve started to do a little debugging and have found a couple things. Once I confirm them I’ll submit them as bugs to gcobb321’s github repository.
It seems that when iOS updates the state, icloud3 is accidentally setting it back (the update is not supposed to change the state, but in the case where iOS changes the state, it is out of sync with icloud3’s ‘last_state’). It’ll take me a few days to test… going into a long weekend here. 
1 Like
This is why I developed my gps filter script - unfortunately, it was designed around an older HA which allowed entities to be created and updated (we’ll say dynamically) but now there’s much more tighter controls around this. The symptom @Ricshy mentioned sounds a lot like what I encountered.
Unfortunately my wife uses an iPhone which I’m forced to support and need reliable GPS tracking. It was easy with my script because it would zero the device into home location (didn’t matter if I used the HA iOS app, iCloud, Owntracks, etc) and then keep it locked there with updates received. The problem with being indoors (even with my Android) is GPS drift and no line-of-sight to a satellite. I even dropped gps accuracy down a 50m value in hopes of filtering out too much drift but I still get false positives.
I’m still battling it and the whole reason I wrote that script in the first place… I’ve been watching this thread in hopes of a better component for my wife’s iPhone (I believe I’ve found one for my Android–Ariela) but sounds like the same problems still plague us with GPS.
@gcobb321 perhaps my ideas may help solve some problems experienced here, maybe not but figured I’d toss the idea out to you… see here: Zanzito GPS Filter (python script)
One thing I noticed is for example in the composite device tracker is when in the home zone, ignore all GPS updates with regards to zoning, ultimately, I think that’s probably the best approach.
Sorry for the rambling, just finished reading the entire thread and thinking about trying this component but feel it’s still plagued by the same issues all indoor-GPS tracking has.
EDIT: After reading through the github documentation, this is by far the best implementation I’ve seen to work around the issues noted above. Nice work.
While trying to tighten the integration with the HA IOS app, I kept running into several problems that are related to this issue. I am running on a 5-second cycle where I monitor the information sent by the IOS app to HA.
The IOS app sends transactions that update the state information of the device, it updates the gps coordinates (latitude & longitude), trigger, timestamp, battery and gps accuracy attributes of the device. These changes are first processed by the device_tracker.see in the device_tracker component init.py file. The gps coordinates are reformatted from ‘gps: (lat-value, long-value)’ to '…{‘latitude’: ‘lat-value’, ‘longitude’: ‘long-value’, …} items in the device_tracker entity state/attribute items.
Zone Ente/Exit transactions.-- The proximity sensor (proximity.py ) looks at the tracked device’s location and determines if it is in a zone and changes the state of the device to zone or not_home (I think). Other proximity attributes are also set… I am also looking at this and using it to trigger zone updates that start the interval timers, distance calculators, etc…One problem I have run into deals with a Zone Exit automation.An ‘Arrives Home’ automation is triggering when I leave home. I think this might be a state change timing timing issue. I pick up the state change and start processing it. Before I finish, another thread also picks up the state change and triggers the Arrive Home automation, I then reset the state using the new gps coordinates from the IOS app when it left home, think it is in the Home zone and set it back to Home based on the GPS coordinates of the device when the 5-second cycle began. I am going to put a condition in the automation that it must be heading Towards home but I think that is a work around rather than a solution.
Background Fetch – This transaction is sent periodically to HA and I think is the main problem of GPS wandering. I put a bunch of traces in the init.py file to follow when the gps coords are updated. I found that many these transactions have old information. I pick up the BF trigger when it happens found the timestamp to be from 2-minutes to 10-minutes old with gps coords that are now old. The proximity sensor code does not look at the timestamp to throw the transaction away but updates the device state based on it. I come along, see that it is old and throw the transaction away. I store the gps coords in iC3 in a table separate from the entity. Rather than throwing them away, I could also store their timestamp and reset them if the ones I have are newer than the device’s attributes.
Another problem I also kept running into that drove me nuts has to do with timing and HA running multiple threads.I would update the lat/long of the device based on the ios app data or icloud location data but the next time I read it to process another command would show the old data. The lat/long I used would be gone,along with the last location, interval, distance, etc. I found this by doing an attribute read right after I updated the attributes and checking to see if it had ever made it to the device’s entity state itself. Perhaps this is all timing related because everything seems to happen on a 5-second basis. The solution was to update the timestamp attribute, then read back the attribute’s state data and do a rewrite if the timestamps don’t match. Since I ran into these update issues, I have to wonder if other parts of HA also dealing with device location issues are losing transactions also. Or is it just because I am running on a 5-second cycle and a 10-second cycle would solve the problem. Another thing to look at.
These are a few of the things I have run into and hope it sheds a little more light on gps drift and timing issues.
Didn’t know any of that was going on, definitely provided me insight into the problem.
I chose to solve it (when it still worked–I suspect if I had the skills to turn it into a custom component and using device_tracker.see I could resurrect it; still struggling with that) by taking the lat-long and using a haversine calculation against a meta-entity lat-long and taking the smaller value (while in zone and not transition) until it basically would reach 0.01m - anything larger than the previous stored meter calculation would be thrown away. Worked perfectly.
My problem is that with the newer HA (worked fine in 0.7 branch) the meta-entity would reset the data to whatever was stored upon first entity storage, ie:
a) start HA
b) data received, store meta-entity data, all good
c) data received, store meta-entity data, state engine would restore immediately (~1s) previous data. I’d receive 100’s of notifications as my script would try to update the state data and state engine would re-write it back and trigger zone entry/leave notification automation over and over
I was able to work around it by removing the meta device from known_devices.yaml but it was never the same again and I kind of gave up hope of ever making it work again. The explanation you gave me makes me wonder if there were also other things going on that you were able to identity that I never did.
Even before I started using HA, GPS signal indoors was always sketchy at best as drift due to no line-of-sight would cause it, by design (after all, it’d be an approximation.) I still think ignoring GPS data within a zone (especially home) is probably the best idea; I’ve adapted my configuration around a bayesian sensor. Seems to work OK but again, not as good as my previous approach.
I installed the iC3 component and it’s definitely a step up from stock/iC2 but I still find my wife’s iphone drifts too much and triggers a leave and sometimes reentry (or just leaves.)
EDIT: I re-read your reply again and thought about something. Updates don’t appear to be atomic based on your explanation; one example I saw (and previously mentioned) was the composite device tracker custom component uses a .lock on the data to prevent other updates from clobbering it. Would something like that work here?
Just an update here - last night using iC3 my wife’s phone triggered 19 zone transitions
The bayesian sensor saved the day and prevented me from being in the doghouse with automations firing (and the fact I was home too; for 13 hours at this writing but I don’t have a iphone and using Ariela) due to this. I installed it yesterday afternoon (iC3) but around 11PM which I believe is her configured “no disturb” time is when this started happening. Currently, it shows her being home 3 hours of the 13 hours since last restart of HA when I installed iC3. My home zone is a 20m radius; used to be larger but I tried to tighten it up to be more realistic.
Glad I switched to Telegram yesterday as I was using html5/sms notifications (sms for her) and she was getting irate with all the text messages overnight; at least this is just one “big” message 
It’s funny how a lot of us struggle with presence detection, each using his/her own method to solve the issue and there’s still really no real repeatable/reliable method when GPS is involved.
EDIT: I should note that presently, the zone entry/leave notification is based entirely on the GPS tracker not the bayesian sensor (which would be more reliable.) I erred in that I said 3 of 13 hours; I meant it shows she’s been home 3hr at present since last transition.
I found an issue that will cause repeated polling of the device when the next update date is past midnight into the next day. I submitted an issue. I am using the prerelease however I would assume the current release has the same issue.
The constant polling when the next update rolls over to the next day been fixed in next update.
Awesome! Thanks.
I’ve submitted a few things I’ve found so far, being lazy and just attaching my version of the file with my in-line comments. It fixes a bunch of issues for me, hopefully it helps solve some issues for others. Lazy issues…
Getting this error…
2019-03-02 15:52:32 ERROR (SyncWorker_15) [custom_components.icloud3.device_tracker] Error Updating Device izzy_siphonex
2019-03-02 15:52:32 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
File “/usr/local/lib/python3.7/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/icloud3/device_tracker.py”, line 845, in _device_polling_15_sec_timer_loop
self._update_tracked_devices()
File “/config/custom_components/icloud3/device_tracker.py”, line 1040, in _update_tracked_devices
attrs[CONF_INTERVAL],
KeyError: ‘interval’
…where should I start?
Does it cause your HA to not let you connect to the UI anymore after this error? If so, there’s a potential infinite loop in the “_wait_if_update_in_process“ routine.
I believe your failed to update error is an error with the Waze routine failing for some reason… causing an exception in the icloud3.py component. It’s caught, but there’s some mishandling of the ‘update in process’ flagging that is being used.
@Ricshy In fact it does cause the UI to become non-responsive. Thought that was another issue. Interesting you were able to connect the two issues.
Any ideas on how to mitigate?
You can use the version in the prerelease folder on the icloud3 GitHub but you will see some debug info in the logs unless you feel like changing it… last I heard @gcobb321 was working out some bugs before releasing the next update … hopefully he can give us an update on a possible time frame for a new version. The prerelease version has been working well for me.
@gcobb321 I have a single family plan with 5 members (i.e. 5 iPhones). Do I setup an individual platform config for each device? Or just one with a list of included_devices?
just one if they are all already linked… if they all show up in your find my iPhone app they will show up with icloud3
@Bartem that’s what I thought. But saw the other devices listed as tracked devices in each device_tracker.*
Thought maybe it was aggregating tracking from them.