Composite Device Tracker Platform

Share your Projects!
281

I’m using two device_tracker to check if I’m at home or not.
One is source_type: router (device_tracker.iphonex) and the other is sourc_type: gps (device_tracker.iphonex_2)

If I leave my appartment the device_tracker.iphonex changes to not_home, but device_tracker.iphonex_2 stays home.

I’ve created another device_tracker with this component: device_tracker.iphone_wolfgang.

I was expecting that the change of device_tracker.iphonex will change as well the state of device_tracker.iphone_wolfgang. But it still shows “home”

device_tracker
device_tracker734×430 36.4 KB

282

By design it specifically does not do that. Please see Watched device notes, especially the second paragraph. Also, my reply just above.

As I said, router type trackers are notoriously bad at guessing when a device has left home. They have no way of knowing a device has left, and rather use an algorithm to guess when they are likely no longer home. GPS based trackers, on the other hand, know when a device has left. So when a GPS based tracker is used, then the not_home states of non-GPS based trackers are ignored. To say that another way, when both GPS and non-GPS based trackers are used, they all contribute to transitioning the composite tracker to ‘home’, but only the GPS based trackers contribute to transitioning the composite away from ‘home’.

If you want it to work the way you expected, then you might be better off using the standard Person component.

283

I’ve installed this thru HACS and also added into configuration.yaml the following:

device_tracker:

  • platform: composite
    name: me
    time_as: device_or_local
    entity_id:
    • device_tracker.platform1_me
    • device_tracker.platform2_me

with my devices, and it shows in HACS that it’s Not Loaded even after reboot. Also all my trackers are showing unsupported source_type: None as others have said. this is after a reboot.

EDIT: I also rebooted again and same deal. I do not see any reference to my “me” tracker in the states entity area in developer tools.

Also now I’m getting errors like the below that didn’t exist in my logs before installing composite:

2019-11-18 20:23:14 ERROR (MainThread) [frontend.js.latest.201910251] https://:8123/hacs_frontend/main.js?v=0.17.3:1:1 Uncaught SyntaxError: Identifier ‘e’ has already been declared

284

If you’re having problems installing it via HACS, then ask the HACS author for help. AFAIK this works with HACS, but HACS is very hard to keep up with. The alternative is to do a “manual” install as described on the doc page.

Assuming it is installed correctly, but it’s still not working the way you expect, try enabling debug and then look in home-assistant.log (for lines containing custom_components.composite) for clues. You can enable debug by adding the following to your configuration:

logger:
  default: info
  logs:
    custom_components.composite: debug

This might be normal. Often tracker entities are restored without their full state. This is just the way the device tracker component code works. The composite code allows for that by effectively ignoring this issue at startup (and prints a warning, not an error, just so you know it’s happening.) But if you get an error, then this is not normal (and will prevent the composite tracker from monitoring the offending entity further – i.e., until the next restart.)

Wait, so are the entities not getting created, or are just showing warnings, or showing errors?

No idea what that is. That is a frontend error. You might want to check your GUI configuration.

285

Thanks I’ll look into these things but keep in mind the frontend errors go away if I remove the composite install.

286

But that doesn’t necessarily mean the root cause of the error is the composite tracker. It could be you have something conditionally enabled based on an entity existing, but then what that does is wrong. Or maybe your system isn’t installed properly. Or, … Honestly this is the first time anyone has ever mentioned a frontend error when using my custom composite integration. I’m not saying it’s not the root cause, just that I find it highly unlikely. In the 1.5 years or so that I’ve been using HA I’ve never even seen a frontend error anything like that.

287

Wait, “hacs_frontend”? Sounds like a HACS issue.

288
289

So some issues have been identified with the new require_movement feature.

The first is, if one or more of the “input” trackers gets created (during startup) after the composite tracker then the (unfortunately) usual WARNING about source_type being None can turn into an ERROR, resulting in the input tracker being ignored.

Next, although the feature was intended to deal with multiple devices, where one or more might be “left behind”, it also affects the device(s) that are being moved around. And it also affects when one is using multiple services on the same device (assuming the feature is enabled.)

The second scenario is this… If the device movement slows down enough (saying walking slowly after driving), the difference between updates might not be big enough, so the composite tracker will get “stuck” where the last “big enough” movement ended. And if this happens right outside a zone, although the device is eventually moved into the zone, the composite will never reflect that.

Lastly, the battery attributes (charging & level) might not be very appropriate for a composite tracker. E.g., with multiple devices, which device’s battery it’s displaying depends on which is moving. And if multiple ones are moving then it will be constantly switching back and forth. Even for a single device, with multiple services (e.g., Life360 & Google Maps, like I use), it will switch between what each service reports, which can be different. (E.g., Life360 & Google Maps report battery charging differently.)

So, I’m thinking of dropping the battery attributes from the composite. One can always make a template sensor if they know their situation and how to properly combine multiple battery attributes in a way that makes sense.

Regarding the first issue (warnings & errors), I’ve made a fix which seems to work. It’s available here if anyone would like to try it out before I release it. If you do please let me know how it works for you.

Regarding the second issue (getting stuck with low movement), I need to do something that handles this situation better, such as taking an average of all updates that didn’t have enough movement so that “drift” (e.g., slow walking) is taken into account. If anyone has any good ideas about the best way to handle this, by all means…

Regarding the third issue (battery attributes), unless there’s an uproar of complaints, I’ll probably delete them. This is your chance! :slightly_smiling_face:

290

An updated beta is available via the same link. It still really only addresses the first issue, although it should do a better job of it now. It also completely eliminates warnings before HA is fully initialized.

291

Phil, long thread TL;DR but a quick scan flagged this.
Not sure of your intent but a lot of parents track their kids battery status. No battery = no phone. Can’t call home if there is a problem etc. Big worry.
I don’t particularly care but I must admit I’ve prompted the wife to find a power socket a couple of times :man_shrugging: :smiley:

Sorry, re-read. I’m fine with your proposal

1 Like
292

This does not affect the battery related attributes of the device_tracker entities the composite tracker monitors. It only means that the composite won’t try to combine the individual battery attributes into something that makes sense anymore, because there’s just too many cases where this doesn’t make sense. If someone cares about battery attributes they can just look at the individual device_tracker entities directly. Which is what I meant by:

Sorry, re-read. I’m fine with you being fine with it. :stuck_out_tongue:

1 Like
293

I’m fine, that you’re fine, that I’m fine with it :rofl:

I’m guessing that you have a “very dry” sense of humour :smiling_imp:

294

Released 1.10.1

(As noted above) fixes require_movement feature when state transition of input tracker is missing GPS data in old_state. Also ignores warnings during entire HA initialization period.

295

So I finally had some time to work on this. The change was very simple and it seems pretty “safe”, even though I have no way of directly testing it. I went ahead and created a beta version. If you give it a try let me know how it works for you.

296

I’ve loaded the beta.
It might be a long shot to ‘prove’ it fixes anything but I’ll keep a look out at it and let you know if anything is amiss generally.

1 Like
297

would love to assist in beta testing, but what exactly would we be looking for? What is the change you’ve made, and do we need to set anything in the config?

forget the above… I’ve found it:

                # Otherwise, if new state is 'home' and old state is not 'home'
                 # and no GPS data, then use HA's configured Home location and
                 # make source_type gps.
1 Like
298

I think I might have found a small ‘bug’(?).
When HA starts there seems to be an inconsistency between source_type and last_entity_id.
Unless I’m misunderstanding what those attributes mean.

Not a big deal as it soon sorts itself out as soon as a GPS tracker reports with its first update.

image
image699×263 20.6 KB

299

There are a couple of scenarios (one which you asked for) where it will have GPS data even when the last entity to update was a non-GPS based tracker. In order for that GPS data to be actually used (by the device_tracker component-level code), the source_type attribute has to be changed to gps.

So, what it is telling you is, the last entity to update the composite tracker’s state was device_tracker.XXX_unifi, but the scenario meant that useful GPS data was also available (probably from the last GPS based tracker that updated to Home, or maybe the case you asked for.)

EDIT: Since gps_accuracy is not zero, that means the GPS data came from the last update of device_tracker.google_maps_XXX. If it was the scenario you asked for gps_accuracy would be zero.

1 Like
300

Released 1.11.0

Use Home location for non-GPS tracker without GPS data. Also round timestamp to nearest second.

1 Like