Composite Device Tracker Platform

Share your Projects!
274

I am confused… you now mention "ignore **non-**GPS updates except for home " algorithm while the GitHub states:


**require_movement**  ( *Optional* ):  `true`  or  `false` . Default is  `false` . If  `true` , will skip update from a GPS-based tracker if it has not moved.

which led me to understand that if set to true, and the GPS-based tracker has no moved, it will skip this GPS-tracker, and then only update based on the other (non GPS-) trackers. (which in my case are networked trackers that flip frequently, so the CC follows that, as long as the GPS-trackers has not moved…)

275

It keeps track of which device_tracker's it has seen. It does not forget a device once it has seen it (unless it has fatal errors.) So, even if it skips some updates (if the tracker is no longer moving), it still remembers that it has seen it. Once it has seen at least one update from at least one GPS-based tracker, it will then ignore updates from non-GPS trackers unless they are home.

276

I have what is probably a lazy question, meaning I am sure the answer is in this thread somewhere.

Am I right in thinking that the Composite Tracker adopts the actual state of the last seen tracker? i.e. if the Life360 state is ‘driving’ will the composite have a state of ‘driving’?

And if yes, would I be right in thinking that if using a second GPS based tracker in parallel, this state of ‘driving’ may not be very useful as the second GPS tracker will probably cause the state to flip-flop between ‘driving’ and ‘away’?

This is all prompted by my very late realisation that Life360 can be configured to take ‘moving’ and ‘driving’ as its state.

277

For GPS-based trackers it only uses the GPS data (and some other attributes if they exist, like for battery, last_seen, etc.) It does not use the state string.

1 Like
278

Hi @pnbruckner,

I’m using/evaluating your composite tracker and wonder about something: in the code, I find this:

                # If router entity's state is 'home' and current GPS data from
                # composite entity is available and is in 'zone.home',
                # use it and make source_type gps.

Why are you making it source_type gps in this case?

The reason I’m asking is that I also use a binary sensor. Currently, the binary sensor is on and it still shows source_type=gps. I would have thought that the binary_sensor has precedence and would result in source_type=router.

If I read the docs about the Person component, also there the device_trackers that are not GPS get precedence.

  1. If there are stationary trackers (non-GPS trackers, i.e., a router or Bluetooth ‘device_trackers’) presenting the status ‘home’, the tracker most recently updated will be used.
  2. If there are trackers of type ‘gps’, then the most recently updated tracker will be used.
  3. Otherwise, the latest tracker with status ‘not_home’ will be used.

Could you shed some light on this?

Thanks,
Ronald

279

I didn’t write the person component, and honestly don’t agree with how it works (which is why I don’t use it.) You’d have to ask whoever wrote it why they decided to implement it that way.

As far as which type “takes precedence,” that’s not how it works. The latest to update “takes precedence.” I.e., the newest, most up-to-date information is used. The main exception is, if GPS-based trackers have been seen, then for non-GPS-based trackers, only their 'home’ state will be used, because they (well, at least, router-based ones) are notoriously bad in guessing when the device is no longer home. (And that’s just what they do, they guess.)

Now, getting back to your question about why the source_type is changed to gps. That’s necessary to use GPS data, otherwise it would be ignored by the device_tracker component-level code.

If you want to know which entity contributed to the current state of the composite device tracker entity, just check its last_entity_id attribute.

280

Thanks for the clarification!

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: