Composite Device Tracker Platform

Share your Projects!
1

Composite Device Tracker Platform Composite Device Tracker Platform

Click the link above :arrow_up: to get the custom integration.

Continuing the discussion from Composite GPS-based Device Tracker?:

Ok, well there wasn’t much discussion, but… :slight_smile:

As I understand it, if you have a GPS-based device tracker and one or more network-based device trackers for a given person, they can be combined by simply editing known_devices.yaml. However, what do you do if you have more than one GPS-based device tracker per person? I couldn’t find anything that would combine them (although I’ll admit I didn’t look too hard. If something already exists for this situation, please let me know!)

“But why would you have more than one GPS-based device tracker per person”, you ask?

Well in my case I’ve been using Life360 to provide presence detection for a few family members, and it’s worked pretty well. I also started using Google Maps Location Sharing for family members that weren’t using Life360. I immediately realized that for some people I could use either … or both!

Then, as chance would have it, one of the people whose device location was being obtained via Life360 (but could be obtained via either method) put their phone into a power saving mode, which caused Life360 updates to become irregular. No matter what I changed in the phone’s settings to let Life360 run whenever it wants, nothing seemed to help. So I tried changing that user over to Google location sharing. But I discovered that it was inconsistent, too, on this phone.

After further monitoring with both enabled, I noticed that although they were both inconsistent, they weren’t inconsistent at the same time. To put that another way, when one would seem to drop out for a while, the other seemed to be updating fine, and vice versa. Weird, because they’re both running on the same phone, using the same GPS service. :thinking:

It occurred to me, I could use an automation that triggered on either entity (Life360 or Google Maps) updating, and use that to create a “composite” device_tracker entity using the device_tracker.see service. And it worked, and worked well!! The biggest downside was now my logs were clogged with this automation triggering all the time.

So, I decided to create a new Device Tracker platform that would do the same thing as the automation. And so far it’s working pretty well.

If anyone has a similar scenario and would like to try this out, by all means, follow the link at the top of the page … and don’t forget to let me know how it works for you, if you can think of any improvements, or if run into any problems using it.

10 Likes
2

Thank you very much for this. I’m actually in a similar scenario where I’m using life360 and gpslogger. My approach was to place both trackers in all automations resulting in entities leaving/entering zones twice.

I’ll definitely try your component.
Thank you again!

1 Like
3

I really like the idea of using the most updated information (as I argued in this post earlier). Your approach should work perfectly for GPS based trackers as the updated information is likely to be “correct”. However, it will not work for network (wifi) based trackers that often report incorrect states. For such cases, I created a meta_tracker python_script that can be called (here’s the automation) with varying degrees of delays depending on the type of tracker.

I like your component and will try to see if we can add some sort of delay based on the type of tracker.

1 Like
4

Thanks!

Agreed. And, to be clear, it was not intended to work with network-based trackers. In fact, it will reject any device tracker entity that does not have latitude, longitude and gps_accuracy (as I explain on my doc page.)

When I first starting using HA, I tried a few of the network based trackers, and not surprisingly, discovered they were almost useless (at least on their own.) And since I had been using Life360 (before HA with SmartThings, and even before I used any home automation), and found it very reliable, I went down that path and have been pretty happy with it… at least until I ran into this “power saving mode” situation.

I don’t currently use any network based trackers. So, really, my only intention was to merge Life360 and Google Location Sharing trackers (based on the same physical device) to get the best of both worlds, so to speak. Although, I imagine this could also work if you had multiple physical GPS-based devices (assuming you carried them all with you. :slight_smile: But, with some added smarts, I suppose it could also deal with a “left behind” device that, although it was “updating”, wasn’t really moving, either.)

Thanks for sharing your solution. If I had found that first I might not have had to create what I did. :wink: But it might help others (as it clearly has so far) that are using a combination of GPS and network based trackers that stumble across this topic in the future.

5

@pnbruckner
Thank you again for the component.
I’ve got it running combining life360 and Gpslogger. It works very very well.
In my view these components (gpslogger, life360) already work very well on their own.
Your component adds a significant level of redundancy and accuracy.

For “network” presence I use happybubbles it just works.

PS: one request if I may, would it be possible to add the json tracker in order to use with this component

It makes it simple to keep updated of any release/change you may make.

6

I’ve updated my repo to add support for custom_updater. See: https://github.com/pnbruckner/homeassistant-config#custom_componentsjson. (None of my code has version numbers, which I just added, so you’ll probably have to update.) Thanks for the suggestion, and let me know what you think!

1 Like
7

thank you for including in the tracker. works great.

1 Like
8

There has been some discussion in other topics and in my github repository about a new feature for this composite tracker that I’m considering adding. I’ll summarize here:

Add support for network-based trackers, but only use their transitions to ‘home’. I know that there are already multiple ways to combine GPS- and network-based trackers (including a native feature in the device tracker platform code itself), but I believe this new feature might handle the scenario a bit more cleanly. In any case, more details can be found here if anyone is interested in seeing or adding to the discussion.

In the meantime, I’ve updated this component (to 1.0.1) to add thread locking. I haven’t experienced it happening, nor have I received any reports that might indicate it has happened, but in theory it’s possible for multiple “input” entities to update so close together that they cause this component’s update method to run multiple times concurrently, which would possibly be bad. So to prevent that from ever happening I’ve added thread locking. This shouldn’t cause any noticeable difference in operation (other than potentially preventing weird “glitches”.) If anyone does see any negative side-effects, by all means, please let me know.

1 Like
9

I have a candidate version with the new feature that should be able to handle device trackers that are a mix of GPS-based (i.e., source_type attribute is ‘gps’) and network-based (i.e., source_type is ‘router’), or are all of one type or the other.

Before I “release it into the wild”, I want to do some more testing. Also, I’d appreciate any feedback from anyone else who would be willing to try it, or even just provide code review comments, suggestions, etc. You can find the code here. If you’d like to provide feedback, it’s probably best to do that via the pull request, or feel free to private message me.

10

I don’t know what time frame you’re looking at, (the way you seem to respond to requests and issues I am guessing I don’t have long :slight_smile:) but I’ll definitely try to look at this as soon as I can.

I have nothing to lose if it all goes wrong as I am not using location/presence for anything important yet.

EDIT: No time like the present! I’ve updated my config to include Ping, NMAP and Bluetooth (will that one be included as it isn’t Router based?) and done a restart. I doubt I’ll have anything meaningful until tomorrow though when someone goes out.

1 Like
11

Thanks for offering to try it out! And anytime is fine. I’m doing a lot of code reading (and guessing!) because I’ve only really tried the ping tracker, but I’ve also tried to simulate the nmap tracker, so I want to take this a little slowly to make sure I don’t do anything stupid and break it.

So far I’ve only considered source_type’s of gps and router, so no, right now it will not accept a BT tracker. But I’d be happy to try and add support for that, too, if you (or someone) can describe the behavior they see from it. Of course, I can read that code, too! :slight_smile:

1 Like
12

Not a lot to report so far (which may be a good thing).

I watched a family member out and about this morning and the sensor reported home, not_home and a zone correctly.

I’m using Google, Life360, Ping and NMAP.

13

Thanks a lot for this! Will take a look tonight and test it out. I think this will help tighten up my presence nicely without the spooky rules I have right now that then to break.

One thing that might be good is to also accept binary sensors with type presence as I use those with HomeKit to wrap a input Boolean exposed to the HomeKit side. When they work they work well but when Apple updates it can be iffy for a few days after

1 Like
14

EDIT: Yes it was a problem at my end, a throwback to before I was using your composite tracker which whilst I don’t think I have exactly stressed it, seems to be working flawlessly for me.

Please ignore this.

This might look a bit lazy but it is late here and I’m off to bed but I just noticed this and given that I think you are in the US you might see and want to confirm or deny it as an issue straight away (or you might not, which is fine).

All that means I haven’t done any investigation this end for which I apologise and it may well simply be my config.

Log Details (ERROR)

Sun Sep 23 2018 23:37:23 GMT+0100 (British Summer Time)

Error rendering data template: UndefinedError: 'mappingproxy object' has no attribute 'battery'
1 Like
15

Working well so far, one error with the UniFi wac component and posted an issue on github. I’ve had to travel for work and back later this week and will fix it if not solved prior,

I’m also using the ‘iTunes ping’ tracker for our iOS devices and it’s consistently a couple minutes faster to both detect arrival and departure over UniFi and thus far no false positives.

16

Good idea. Thanks, I’ll add that to the list…

17

Sorry, is that an issue with UniFi, or with my component working with UniFi? I looked around but couldn’t find any github issue authored by jwelter.

18

Quick question regarding this.
I plan on using SkyHub (a router based presence detection), Bluetooth and GoogleMaps for presence detection.

Are all these supported?

Also, one of my issues with my house is the thick stone walls, these make a dead spot in my kitchen. It means that bluetooth drops off (marks me as away) and the router marks me as home and away depending on where I am stood in the kitchen.
In this use case would your tracker take the most recent update (probably the wifi connecting/disconnecting repeatedly) or would it look at the other sensors/‘consider_home’ settings to make a decision?

Sorry for the newbie question, but the one thing I’ve never got the hang of over the various months of trying and giving up on with HomeAssistant was presence detection…

19

It has to do with the way the Unifi component exposes last_update_time not being compatible with your component so it throws an exception.

I simply disabled the Unifi component from exposing that field (it is configurable in the HA component) and that solved it for now; while I am on work travel.

I think it’s an easy fix once I figure out what it doesn’t really like (complains about no TZ being set).

20

No. As I said above (well, after I just edited it and added the operative word “not” :blush:):

So far I’ve only considered source_type’s of gps and router, so no, right now it will not accept a BT tracker. But I’d be happy to try and add support for that, too, if you (or someone) can describe the behavior they see from it. Of course, I can read that code, too! :slight_smile:

And so far even the support for routers hasn’t yet been released, although you can grab a copy of the candidate as mentioned above if you like. I am hoping, though, to release this soon. Seems like the testing so far has shown at least I haven’t broken anything, and the router support seems to be reasonable.

I explain this a bit in the yet unreleased update to the doc page, but basically, if you’re using a GPS device like Google Maps Location Sharing, then only the ‘home’ states of the router entities are used. So they can help make the composite device ‘home’, but they won’t change the composite device to ‘not_home’ – only the GPS device can do that. This is “by design” since router trackers tend to change “falsely” to ‘not_home’ a lot, and even when they do change to ‘not_home’ correctly, they are slow to do so by their nature.

1 Like