**iCloud3 v2.0 is now available. Go here for the latest version.
Gary Cobb, aka GeeksterGary
Edited Dec 1, 2019
**iCloud3 v2.0 is now available. Go here for the latest version.
Gary Cobb, aka GeeksterGary
Edited Dec 1, 2019
Looks good!
You say the IOS app will notify Home Assistant. I assume that means you need to have the IOS app connect over the mobile network (i.e. have the hole punched through the firewall).
Could you please confirm?
Thanks!
Yes, the IOS app needs to be running on the device (iPhone) in order to provide location information to HA. I connect securely through duckkdns and letsencrypt (part of duckkdns) on my Hass.io based rig. There are lots of docs and YouTube videos available that will help you set it up and they will be a lot more useful than I can be.
Hi Gary,
impressive work - really cool!
A few questions - sorry if the answers are just too obvious, but I couldnât find themâŚ
ios:
I suppose this should stay in configuration.yaml
(as notifications will otherwise stop to work, e.g.)?
Device ID
My iPhone has two identities in known_devices.yaml
, one from iCloud and one from the âDevice IDâ field in the app (Home Assistant for iOS 1.5.0).
Is this kind of âun-intendedâ behaviour due to me not naming the device in the HASS iOS-app the same as the device is named in iCloud?
Hass iOS-app vs. iCloud - 1
At present, my sonâs iPhone is on a separate iCloud account - and tracking his device is based on the device tracker resulting from having the Hass iOS-app installed on his phone. Of course, his phone does not show up with the new attributes from your custom component. How should I configure the component in order to track devices on different iCloud accounts?
Hass iOS-app vs. iCloud - 2
Kind of opposite, my iPad is tracked via iCloud but the Hass iOS-app isnât installed. However, attributes originating from your component are added to the tracker in Hass. So, what will be the actual difference between devices with or without the Hass iOS-app installed?
Donât get me wrong - thereâs absolutely not any kind af malice in my questions - Iâm impressed and it might be not getting the finer details - and I do know some of is kind of not related to your work, but only âexposedâ due to the work youâve done
Regards,
Chr.
Hi Gary,
Iâm posting this here instead of GitHub as I was unable to complete the account creation regime with my current configuration.
Iâve been using icloud2 for several weeks now and still canât get the location accuracy necessary to open the garage door as i approach the house. I believe Iâve followed your instructions with this device_tracker.yaml entry:
- platform: icloud3
username: !secret icloud_user
password: !secret icloud_passwd
account_name: gklocation
include_device: Gary
exclude_device: GaryOld
- platform: icloud3
username: !secret icloud2_user
password: !secret icloud2_passwd
account_name: sklocation
include_device_type: iphone
Iâm attempting to setup two phones (7 & 8 running latest iOS), each on their own iCloud account. User account sklocation populates with all the attributes. User account gklocation does not. GaryOld is excluded from tracking as expected, but Gary doesnât adopt icloud3 attributes. Iâve tried different combinations of include_device, device_type, and as below, called out the devices by name. No luck. Any suggestions?
Iâm on 64-bit Hassio V85.1, RPI3b+ and V1.5.0 iOS app on the phone. No errors reported other than the unsupported warning similar to icloud2.
I set this up and nothing happened. I got the notification to authenticate with my iCloud account, but there were no new devices. So Iâve disabled it.
cbh:
ios: Yes
Device ID , Hass iOS-app vs. iCloud - 2 - Yes. The IOS app issues zone enter/exits and pushes location updates to HA; the iCloud Find-my-Friends issues location updates and other device information when asked by iC3. They must map to the same device. If they do not, or if the IOS app is not installed on the device, the zone enter/exits will not be picked up when they actually happen.
They will be updated, however, on the next poll by iC3. The problem with not having the IOS app installed is if you are in a zone and on a 2-hour polling interval, it could be 2-hours before the device goes to a not_home state. With the IOS app, it picks up the zone exit, pushes it to HA, gets picked up by iC3 and changes the state within a minute or two of exiting the zone.
My config is iPhone Settings>General>About=Gary-iPhone, IOS App name=gary_iphone (HA85+) (or garyiphone HA84 and earlier). Special characters (â-â) get mapped to â_â by HA and must be accounted for. I could have set it to Gary_iPhone but didnât.
Hass iOS-app vs. iCloud - Set up another device_tracker: iCloud3 platform with your other account and have an include_device statement in each account for the device in that account.
@gcobb321:
Thank you very much for the explanation - have reconfigured and now have one device_tracker.
per phone (and that from two different iCloud accounts) which seems to work.
Might be the explanation for the delay I had with presence detection (in some way, kind of weird the name proposed in the Hass iOS app isnât the exact same as the device is called in settings - to avoid this type of mix-up - but thatâs another subject).
Looking forward to (the expected) positive change in presence detection
Thanks again!
Nothing original to show - my config is basically copy-pasting from:
Most probably, my contribution has been messing up the code while figuring out what to change and what to leave to get it work - so I would definitely suggest looking at the original examples
OK. Iâll continue to fiddle until both phonesâ attributes appear.
Perhaps, something that I canât show (because I deleted it), could be what youâre looking for:
Changed the device name in iOS settings to something new and added the same in the Hass iOS app - and then removed references to the old names in the config (in .storage\core.device_registry
, in .storage\core.entity_registry
and in known_devices.yaml
).
(And, of course, used the mandatory time for finding groups, automations etc. with the old names that I forgot about firstâŚ)
Iâll try your approach if/when Iâve reached my limit⌠Changing .storage\core.device_registry
looks straightforward, but .storage\core.entity_registry
lists sensor IDâs. Did you just delete the sensors from the file?
yes - youâre not supposed to do it, youâll find loads of warnings on the forum about it, Iâve spent hours trying to find where I screwed up while doing it before - youâre warned⌠Do for crying out loud backup the file before editing it and definitely also stop hass.io⌠ReallyâŚ
If you decide to do it anyway (as everybody else):
Make sure to delete the complete entity - and if youâre deleting the last one in the file, that the new âlast oneâ does not have a ,
after the }
Got it! (i hope)
I use HA ios app device tracking at the moment whereas I used the icloud component in the past. The icloud component really killed my iphone battery (and the one from my wife as well) and it also killed both my apple watch batteries like crazy.
Even with a once per 60 minutes polling it drained the battery really fast. My question is, what is the hit on the battery with this component? Because with only the HA ios app I have great battery life, and automations work great, however it isnât always as accurate.
I have also had good luck with both BT tracking with my iPhone (not BLE) and using the HA iOS app. No apparent impact to the battery.
How iCloud3 minimizes battery impact
I, the guy that developed the program, have used an iPhone X until December (iPhone XS since then) and have noticed no noticeable effect on the battery. Most of the time I am in a zone (Home and others) that is on a 2-hour inzone (configurable) polling cycle. As soon as I leave the zone, the IOS app generates an exit zone notification and actual polling begins. I just picked 2-hours but it configurable and could be 6, 12 or whatever works best in your situation.
A lot of work has been spent minimizing battery usage and the polling interval calculation is a major part of that⌠The base iCloud component calculates the polling interval on the distance from home, not the time it will take to get there. iCloud3 uses the driving time/distance from the Waze mapping service (except for the last mile). This makes determining the polling interval much more accurate. For example, itâs a 20-minute drive home â the next poll is in 12-minutes. If, at that poll, I am now 10-minutes from home, the next poll would be in 6-minutes. The interval is determined by taking 60% of the Waze drive time (configurable) until the last mile. Then it goes to a 15-second poll to trigger âarrive homeâ automations.
Another way it minimizes battery usage is by creating Dynamic Station Zones. If you havenât moved very much during 2 polling cycles (shopping, friends house, doctors office, the beach, etc), a DSZ is created with the current location and you are now on a 2-hour polling cycle. When you leave the DSZ, the IOS app notifies HA of the zone exit and you are back on the time/distance cycle.
Service Call commands let you pause and resume polling. For example, you are on a trip far from home. It makes no sense to poll the device even though the polling interval would be very large. If you are out of the country I am sure the driving time returned from the Waze service would be unrealistic. When you arrive back in the country, resume polling and it will be gin in 15-seconds.
Gary
It sounds pretty good, I might give it a try. Though my current setup works perfectly fine (only ios HA and tado device tracker). But this seems like what I was searching for when I first started using the icloud (aka idrain) component in hass.
Version .86 - 1/22/2019 now on Github
I just pushed out an update that: