I’ll look into this. From what I can tell, there are new ‘battery_level’ and ‘battery_charging’ attributes defined in HA’s const file that Google Maps Location Sharing uses, whereas my Life360 implementation used the ‘battery’ attribute that was defined in the Device Tracker component.
1 Like
So, the device_tracker component provides a “see” method for platform code to use to indicate when a device has been seen.One of the parameters of that method is battery. That’s what my Life360 platform code (and others) use to report the device’s battery level. (You can check it out on the services page. Just select the device_tracker.see service.) This ends up in the device_tracker entity’s ‘battery’ attribute.
The see method also provides a way for the platform code to add other, “non-standard” attributes to the device_tracker entity. My Life360 platform uses that to add a ‘charging’ attribute (among others.)
Now, for some reason, when the google_maps device_tracker platform code was updated to add battery level/charging status, it didn’t use the standard battery parameter for the battery level, but rather added it as a “non-standard” attribute named ‘battery_level’. If you ask me, that’s incorrect. They should have used the standard ‘battery’ attribute reporting mechanism. It also added the charging status as attribute ‘battery_charging’.
So, although I think the google_maps platform is wrong in how it reports the battery level, I could update my composite platform to look for either the standard ‘battery’ attribute, or the non-standard ‘battery_level’ attribute. If either is found it will go into the standard ‘battery’ attribute.
Regarding the charging attribute, it looks like ‘battery_charging’ is a bit more common than ‘charging’, so maybe I should change both my Life360 and Composite platforms to use ‘battery_charging’. That’s a bit of a breaking change for the Life360 platform, but probably worth it.
EDIT: See new issue #60.
1 Like
Do you find this works better than other router based (not ping/imap) presence detection? I have iphones, and use asuswrt device tracker, and it has been 100% for me, but I’m always interested in finding new ways to track devices without draining battery.
I was using the Unifi component which worked ok but always lagged on departure detection; it was close to 100% but I didn’t like the lag.
With this component it is much much faster.
I use it and the iOS app for location combined in the excellent composite_device_tracker mentioned above and it is 100% solid and very quick.
I was running some door-triggered checks but have retired those as it works so well.
Give it a shot. I would not be surprised if it outperformed the ASUS tracker as well.
1 Like
/custom_components/device_tracker/iphonedetect.py
In your config add:
device_tracker:
- platform: iphonedetect
hosts:
iphone_one: 192.168.2.12
iphone_two: 192.168.2.25
Thats all you need…
Thanks, I will do. It’ll be tomorrow though.
1 Like
thanks!
to not hijack this thread any further… sorry @pnbruckner, and reference for the iTunes device_tracker you might consider creating a dedicated thread for that? I would have know about it if not for your answer here, so guess maybe a lot of other people would like to try too.
Does iphonedetect require running iTunes somewhere on the same subnet 24/7?
No you just need to use iTunes to enable wireless syncs on the device and then you are good to go.
OK. New devices now appear in known_devices.yaml, but don’t appear in the developer tools states list.
Never mind. Got it.
First response - the beta seems to work. I’ll let you know if I notice any issues.
1 Like
Released 1.6.0
In addition to ‘battery’ attribute, also accept ‘battery_level’ attribute, and use for ‘battery’ attribute. Accept either ‘battery_charging’ or ‘charging’ attribute and use for new ‘battery_charging’ attribute.
This looks great! I’ll give it a go over the next few days.
1 Like
EDIT: I’ve done a few restarts (unrelated to this) this evening and at some point it seems to have righted itself. I’ll try to keep an eye on it and report back if it happens again
I’ve now updated to the new life360 component and I’m using the composite beta and I have noticed something strange with ‘charging’ (which I suppose could be something to do with my config?)
Is there any way to incorporate “picture” into this, like is done in the normal device tracker?
(change the icon?)
I made a fix with the charging attribute in b3 and the final release. Although it wouldn’t explain this. Look at the “last entity id” in the composite and the “last seen” time. It is showing data from google_maps from 22:07:27, but look at the google_maps entity itself – its “last seen” is 22:15:57. So these two don’t correlate in time. It looks like the phone’s charging status changed between 22:07:27 and 22:15:57. It’s only reporting what it gets.
If you want to verify, look for the state_changed events for these devices in home-assistant.log. All the raw data will be there.
1 Like
So it is true that some device_trackers provide a picture from the server (such as google_maps and life360.) But the way the device_tracker component level code works, is, that information is only captured and saved (in known_devices.yaml) when the device is first seen.
So, if the composite device is first seen when it gets an update from a tracker that does not have a picture, its entry in known_devices.yaml will not get a picture. Then even if it gets an update from a tracker that does have a picture, it won’t be used by the component level code. Also, what if the different “input” trackers have different pictures? Which should it use?
The best way to add a picture to the composite tracker is to edit known_devices.yaml and copy the picture (URL) from the tracker that has the picture you want to use for the composite.
@pnbruckner I am checking this again and I am not sure I follow your explanation.
Right now I have the following (copied form the States page, all omitted fields are either not relevant here e.g. gps_accuiracy or are identical e.g. latitude and longitude)
device_tracker.person_composite
"last_entity_id": "device_tracker.life360_person",
"last_seen": "2018-11-10T09:45:35+00:00",
"battery_charging": true,
device_tracker.life360_person
"battery_charging": false,
"last_seen": "2018-11-10T09:45:35+00:00",
device_tracker.google_maps_xxxxxxxxxx
"last_seen": "2018-11-10T09:45:34.472000+00:00",
"battery_charging": false,
EDIT: Maybe I should have included the fact that all device trackers show the same state i.e. a zone name which is not ‘home’.
Sorry if I am missing something obvious…
Ok, if you’re still using device_tracker.composite 1.6.0b2 then that actually would explain it. The bug in that version was, if battery_charging is False, then it would try to get an attribute named charging, which of course would not exist (so the value would be None.) And if the value it got was None then it would not update battery_charging in the composite device. So once it became True it would stay that way. The change in 1.6.0b3 (and the final release, 1.6.0) fixes that.
BTW, while checking how my devices have been working (to see if my composite was acting the same way), I discovered that for the same device/phone, sometimes Google reports the battery is charging, whereas Life360 reports it is not. I’ve seen this on two Android phones. Not sure which is correct, or if they’re just reporting a different status – e.g., plugged into a charger vs actually charging (i.e., level < 100%.)