D’oh! Sure enough, there it is! I don’t know what I have misconfigured, but for some reason github doesn’t notify me by e-mail when someone opens an issue in my repo. I get e-mail notifications for other things, but not that. Argh!! And when I’ve looked recently, I didn’t notice it because github didn’t mark it as new either.
Anyway, thanks. I’ll look at the unifi code, but clearly it is putting a timestamp in the last_seen attribute instead of a datetime like Google Maps Location Sharing and my Life360 trackers do. I suppose an issue against the unifi component could be opened asking for it to be changed to a timezone aware datetime in UTC (which might be a breaking change), or I could look at changing my code to try it as a timestamp if there’s an exception using it as a datetime.
It currently only supports device_tracker entities whose source_type attribute is either ‘gps’ or ‘router’. What is the source_type’s of the entities you’re trying to use? Are you seeing any errors, and if so, what are they?
Also note that the composite entity will not update until one of the “input” entities updates. Which means, when you first use it, the composite entity will not exist (and won’t be added to known_devices.yaml) until one of the input entities updates.
I’ve updated the candidate code to (hopefully) handle a timestamp (as either a number or a string representation of a number), so it should now work with your Unifi tracker if you’d like to give it a try.
I’m starting to look at adding support for bluetooth trackers. I’m reading the code (specifically bluetooth_tracker.py since I haven’t used this myself yet), but it would be helpful if someone who is using bluetooth could send me what the state of their bluetooth device_tracker entity looks like. You can do that here, but to keep the traffic on the community forum down, it might be better to send the info to me via private message, or via my github issue. Of course, please redact any personal information you’d rather not share. Thanks!
That’s what I was looking for. Thanks! Basically, it’s state is ‘home’ (and presumable ‘not_home’ otherwise), it’s source_type is ‘bluetooth’ (so far no surprises), and there are really no other relevant attributes I need to worry about or take into account.
FWIW, this, and binary_sensor, were pretty easy to add (assuming I haven’t made any serious oversights.) I’ll have a candidate version to try in github soon.
Will binary sensors be treated the same as router, as in only change to based on Home and ignore not_home? I dont have bluetooth, but would assume the same?
Hopefully the answer is in the update of the doc page, but in general (at least this is the goal), for any non-GPS-based input (i.e., bluetooth or router device_tracker, or binary_sensor) the “home” state (‘home’ for device_trackers, and ‘on’ for binary_sensors) will always be used.
Their other states (really only ‘not_home’ or ‘off’) will only be used if there are no GPS-based device_trackers used in the composite (or if the GPS-based trackers haven’t been seen since restart.) And in this latter case, the state of the composite will be ‘home’ if any of the input entities are ‘home’/‘on’, and ‘not_home’ if all of the input entities are not ‘home’/‘on’.
As an FYI I think Bluetooth LE has a source_type of “bluetooth_le” as well; I do not run a tracker of that type any longer due to range issues but I recall that was what it reported.
If you dig deep enough both the bluetooth and bluetooth_LE built in trackers have issues. This is why many use external trackers like room assistant or monitor.sh
It has to do with the command line scanner being called which blocks.
Also on a RPI you may have wifi issues while BT is scanning.
I’ll look into trying it out! I’m having issues with the google maps component at the moment though (not related to the composite, just me being unable to set up the google maps one).
So far the beta composite component seems to work just fine, but just to be sure Im doing it right: the device_tracker Ping would be ok to use as a router based device_tracker? Ive set it up as such, and no error messages are displayed, but I cant find the Ping device_tracker in your doc’s…
Was wondering if it would be cool to display the tracked devices on the more-info card. At the moment, there’s no visual clue this entity is compiled of more than 1 device, and it would be of great added value if we could see that on the more-info. Imho…
Consider that a feature-request
Cheers,
Marius
My docs refer to types of trackers based on their source_type attribute, not specific tracker platforms. The ping tracker’s source_type is router. So, yes, if you use a ping tracker with the composite tracker it will work and be treated as a router type tracker. In theory any tracker platform whose source_type is bluetooth, bluetooth_le, gps or router (and I think that is all the types there are) should work, but only a few have been tested so far.
Not sure how to handle the frontend side, but at a minimum I could easily add an entity_id attribute that lists the entities that have contributed to the state of the composite tracker. Good idea!
