for presence tracking I use groups per individual, and have several trackers in that group.
network, bluetooth scanners, device_tracker ping , and also gps trackers. With all these the group state was always home/not_home.
Ive recently added a binary_sensor.ping to these groups, and all of a sudden the state of the group is on/off…
Does this tracker take presendence, and if so is that documented somewhere? Or is this unexpected behavior and should this be raised an issue.
whats even stranger is that the group doesn’t use the other entity’s any longer to change state, it only reacts to the binary_sensor. Making the group technique useless in this case…
When you care about the group state, then you should really only be using them with entities that have the same type of states – i.e., on/off, home/not_home, open/closed, locked/unlocked or problem/ok. Looking at the code I would say this is by design. (If you want to know more, take a look at the group code.)
In your case, a binary_sensor is not a device_tracker. Those are two different domains, that use two different sets of states. So you should not combine them into the same group, at least, not if you care about the state of the group.
But, if you’re interested, I just so happen to have a Composite Device Tracker that can accept both “normal” device_trackers as well as binary_sensors that you might find helpful.
yes thank you, I am using(trying out) your composite tracker already, should have thought about that and added the binary there.
What surprised me was that where my groups had about 4 or even more device trackers, and showing Home/Away, simply adding this binary_sensor ping changed that into on/Off and added the group control toggle back into the group, and even more surprising, added that same toggle to all other entities in the group.
Taken it out again, and will test with your now better filled composite component.
Yep. Remember, HA still hasn’t reached a 1.0 version yet, which means that you can’t expect the documentation to be extremely complete and accurate. IMHO to really use HA effectively (today) means one often has to just go read the code.
quite. And use it in the most versatile of ways one can imagine to test the components to the edges… My RPI3 is having a hard time.
getting back to this, and my struggle with the last_seen and lost_connection of the life360 tracker…
Ive setup your composite component tracker with 4 device trackers and 1 binary_sensor. 3 of the 4 device_trackers show not_home, only the life360 shows Home (…long story, not repeated here). The binary_sensor shows off.
Yet the composite component device_tracker show Home, and last seen by, you might guess it already, the life360 component, which hasn’t been in the house for over 2 weeks now
Is this the same theory as we’ve discussed in the other threads on the life360 component? Or would be able to handle it differently here, since it is a custom component you might be able to make it more tailor made.
… and that last_seen timestamp, I’m also guessing, is the last time it was seen at all, right?, and at that time it was at home, right?
FWIW, I can tell you you’re going to get the same behavior if you used Google Maps Location Sharing, and probably other GPS-based trackers. I don’t believe this is unique to my Life360 GPS-based tracker.
Yes, same thing. The GPS-based tracker is home because that’s the last place it was seen. And the non-GPS-based trackers assume the device is not home because that’s all they can do. It’s the same situation if the device was turned off (or put in airplane mode) and left at home. There’s no way for ANY device tracker to know where the device is at that point. So, GPS-based trackers will indicate the last place it was seen, and non-GPS-based trackers will do what they were designed to do and assume it is no longer home. You get different answers because of the way these two different classes of tracker work. They don’t really disagree, they’re just coming to different conclusions based on insufficient information.
I won’t, because as I’ve explained before, there’s no way to do it properly given the constraints under which device tracker platform code operates. But you’re free to change the code to do whatever you want. That’s the beauty of an open source project like HA.
This is the best explanation written hands down. Might I suggest you add that to you component, or maybe even request a change in the HA documentation. I think it would help a lot of people struggling with this.
Well, If you don’t mind, I’d rather rely on your skills in this component than mine. Wouldn’t dare to in fact, since it behaves 100% as per design. Not what I’d love to see, but you know, life simply isn’t like you want it now and then…
I’m glad I have my overdue sensor telling me the component is not to be trusted
My RPI3 is having a hard time.