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.
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…
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.
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?
Yeah you will see them all in that attributes field for every device but it should only create an entity for and track the devices you want it to if you use include/exclude
Since upgrading to Home Assistant 0.88 I have been getting the following error:
## Log Details (WARNING)
Sun Mar 03 2019 18:08:49 GMT-0500 (Eastern Standard Time)
Integrations need to be in their own folder. Change device_tracker/icloud3.py to icloud3/device_tracker.py. This will stop working soon.
The current file structure is like this: config > custom_components > device_tracker > icloud3.py
The error states that I should be doing this: config > custom_components > icloud3 > device_tracker.py
I have not made the change yet and was hoping someone could confirm that this is correct and will not break what is currently working. Thanks,
@kartcon The guys at HA have changed the way custom component files are stored. The old way is to put icloud3.py in a
‘custom components/device_tracker’ directory. The new way will be to refer to the icloud3.py program as device_tracker.py in the ‘custom components/icloud3’ directory. From their description of what is going on, it’s to have all files associated with a custom component in one place. Right now, both methods work. In the future, we’re going to need to change some file and directory names. I may try to adhere to the new names when I release the next update.
@bartem The coding is done and appears to be working without any issues. Now for the fun part, documentation changes and getting all the files together for a release. Then the HA guys changed the way custom component files are referred to. Oh well. I have a bunch of other things going on but hope to have it out by the end of this week.
Some of the features include (1) tight integration with the HA ios app, (2) improved Dynamic Stationary Zone operations, (3) improved error handling, (4) detailed debug type logging can be turned on and off without restarting HA, (5) better handling of old data and GPS accuracy issues, and (6) improved interval timings.
