Question: Is it possible to use a binary_sensor Class presence with this integration

[pnbruckner]

Question: Is it possible to use a binary_sensor Class presence with this integration

[pnbruckner]

What is the entity ID of the binary sensor? Based on your config above and a brief review of the eap225 code, I'm guessing it is not binary_sensor.justin_phone_in_wifi. Please look on the STATES tab of the Developer Tools page to get the exact entity ID. I'm actually guessing you should change the config of the binary sensor to:

binary_sensor:
  - platform: eap225
    name: justin_phone_in_wifi
    mac: 64:a2:00:71:a2:4c

Notice the difference in the name option.

In any case, you must configure the composite device tracker to use the exact entity ID of the binary sensor.

[j54j6]

Thank you for your answer, unfortnetally i didn't receive an email about your reply (maybe my setings are wrong ^^) -
I've looked up the ID and you're right - the ID was wrong (the name was binary_sensor.binary_sensor_justin_phone_in_wifi) - I've created a new one to test it again and it still don't work :/

Here is my full config and in brackets the ID shown on dev Tab

configuration.yaml:

binary_sensor:
  - platform: eap225
    name: justin_phone_in_wifi [binary_sensor.justin_phone_in_wifi]
    mac: 64:a2:00:71:a2:4c
device_tracker:
  - platform: composite
    name: Test
    time_as: device_or_local
    entity_id:
        - binary_sensor.justin_phone_in_wifi
        - device_tracker.privphone02

This time it works well if I only add the first sensor (binary_sensor.justin_phone_in_wifi) - but if I add the companion App tracker (device_tracker.privphone02) - only home is shown (Smartphone is not in wifi (first device tracker is away) and my smartphone is not connected to the cell to prevent sending my gps data to my home assistant... - the states are updating in states Tab. It doesn't work either when I modify the binary_sensor.justin_phone_in_wifi on the states page :/

Sry. for my late response, I will check my settings and reply ASAP :)

Thank you for your effort and help ^^

[pnbruckner]

@j54j6 please see Watched device notes for a description of how this works. Specifically, if you specify any GPS-based entities (which I'm guessing device_tracker.privphone02 is), then the non-GPS-based entities (e.g., binary_sensor.justin_phone_in_wifi) can only set the composite tracker's state to home. To put that another way, binary_sensor.justin_phone_in_wifi cannot set the composite tracker's state to not_home (aka "Away".) This is by design, because most non-GPS-based entities only do a good job of indicating when a device comes home, but they do a pretty poor job of indicating when a device leaves home.

[j54j6]

oh man... this was stupid -.- - yes thank you I need to read more carefully :/... But then this integration doesn't work for me... in my case the problem is the "away" state not the "home" state... The companion App on my girlfriends IPhone doesn't work properly, the App were killed every two days and my HASS doesn't recognize that the App is not working anymore... - in this case I need to modify the integration for my, I think "special" needs...

thank you for your effort and sorry for this stupid mistake - I defnitly need to read the doc more carefully next time :D

[pnbruckner]

@j54j6 no problem.

I might consider extending the configuration to allow an option per entity_id which says whether or not to use non-home states for the entity (which, by default, would be true for GPS entities, and false for non-GPS entities, to retain the current behavior.)

Again, when this was written, the assumption was that non-GPS entities do a pretty poor job of indicating when a device leaves home. (They usually have some, "hey, I haven't heard from the device for a while, so it must have left" algorithm.) But, if there are any non-GPS entities that do indicate when the device has left home in a timely manner, it would be nice to use that info.

[j54j6]

Yes, of course ^^ - In my case this option would work perfectly... My WiFi AP is a very reliable source for the "home" and "not_home" state but I want to use the zones from my companion App also and for this case is your composite tracker perfect -

If you plan to extend your application I'll be waiting until you released the new Version and use (like at the time) only the wifi tracker, for my current automations (vacuum and my shutters..) this is absolutly good...
Alternativly I'll fork your Integration and extend this repo myself^^

[pnbruckner]

@j54j6 I have a draft implementation. I'll try to test it out thoroughly tomorrow. If all goes well I might be able to release it soon.

[pnbruckner]

@j54j6 so there's a potential problem with using the off (aka Away) state of a binary sensor (or the not_home state of non-GPS-based trackers like routers, bluetooth, etc.) if there is also a GPS-based tracker specified.

E.g., let's say the binary sensor is on (i.e., Home), and the GPS-based tracker is also Home. Now let's say the GPS-based tracker changes first when it leaves home and immediately goes to another zone, so that its state is the name of that zone. (Maybe there is a larger HA zone specified around Home, e.g., "Near Home".) Now the binary sensor changes to off since it detects it has left home. That would change the state of the composite tracker from the name of the other zone to not_home (aka Away.) Now the GPS-based tracker updates and it's still in the other zone. So, the state of the composite tracker would go:

Home -> Near Home -> Away -> Near Home

That is not optimal.

But I would think this probably isn't very likely (i.e., I doubt most people would have another zone so close to the Home zone), so maybe it's not really a problem. Also, the binary sensor (or non-GPS-based tracker) probably wouldn't update again while it's off (or not_home), so again, this probably isn't a real concern.

Thoughts?

I'm going to commit the changes in a PR so you could try it out if you like.

[j54j6]

that's indeed not optimal in all sorts... In many of my automations (where is only checked if the state doesn't equal to "home") this behaviour is not a problem at all but I think if you want to use these Zones lets say to open your shutters when you come back home (i.e Home -> near home (shutters close) -> away (binary sensor) -> near home (shutter open) and then you go away (shutters need to close normally but the binary sensor already triggered the automation for the away close shutter state, that would be surely not optimal (you can prevent this behaviour by checking the state of the gps tracker seperatly or say "go down every time the state is "away" but then you need to keep track for the gps tracker specially and this is not a good solution I think - and the shutters in this case get quite stressed over time...

Maybe a self defined "cooldown time" (in seconds) in combination with a piority option (i.e. the GPS Tracker is the priorised one) is a opportunity so you can i.e. the GPS Sensor changes to as you have defiend to "near_home" and 20 seconds later you will lost your wifi connection - the GPS tracker did have a accuracy by 5 meter i guess... than you can set the cooldown to 35 seconds (my AP is checked every 30 secs) and in this time all other sensors can change to off or whatever - your GPS tracker is the only entity that can modify the state within this cooldown time... - and oterwise if the binary sensor is the priorised sensor it works vice versa (I don't know a usecase for this but maybe there is one^^) - thoughts for this? - did you see any problems occuring when using this?

[pnbruckner]

The way I've always looked at this is that all these "input" entities are pretty much always "stale", so it tries to always use the least stale information.

I.e., for GPS-based trackers they are only valid the moment they update, and then as time goes by that information becomes more and more stale. (Actually, even when they update in HA they can already be somewhat stale due to polling, which is why I try to use the last_seen attribute as opposed to the last_udpated state field.)

For non-GPS based entities it's even worse. They are typically valid the moment they change to on or home, and then, like GPS-based trackers, they become more and more stale as time goes by. When they change to off or not_home, that's not typically because they have sensed the device has left home, but rather they have decided the data is so stale that the device must have left home. To me, those entities changing to off or not_home is not new data; it's simply an indication of the lack of data.

This is why the original implementation was only to use the on/home states of non-GPS entities, unless there are no GPS-based entities specified. But I can see that maybe some non-GPS based entities could possibly determine when a device has actually left (as opposed to just not seeing it home for a while), so it makes sense to at least allow the option of using the "non-Home" states of some of these entities.

As far as "cooling off" periods or anything like that, I'd prefer not to complicate this integration with algorithms like that. To me, that belongs in the implementations of the entities that are used as inputs to this integration. One of the reasons I don't like the implementation in the built-in person integration is it tries to do that kind of thing (prioritizing, etc.), but it does it very poorly, IMHO.

BTW, this integration has the "require movement" feature, which turned out to be much harder than I expected. I actually don't like it as it stands, but I haven't removed it in case anyone actually found it useful.

[j54j6]

hmm.. then i think we need to live with this behaviour ^^ - I will test the other branch tomorrow and hope that this is already enough for my needs... Normally my Wifi (binary sensor) recognizes much faster that I'm away than the companion app

[pnbruckner]

@j54j6 just wondering how the changes worked for you.

[j54j6]

There are some Problems when chaning the state... But I didn't find the problem so far, I will reply again if I can send anything productive for you :) - For now it is working more or less well ^^