search

mueslo / openwrt_hass_devicetracker

Simple OpenWRT package which forwards device connection changes to a HomeAssistant instance
GNU General Public License v3.0
92 stars 31 forks source link

Distinguishing the location in multi router setup: 'floor detection' #16

Open SaturnusDJ opened 5 years ago

SaturnusDJ commented 5 years ago

Another way to improve this nice software. Let's discuss about this.

https://community.home-assistant.io/t/multi-router-floor-detection-how-to/85244

I see it is possible to have the script set _locationname, which normally is either home or _nothome which in turn results in the home/away badges in Home Assistant. By passing a custom _locationname that one is being displayed instead.

The question is if this would be the right way to go as it might break things that depend on home and _nothome.

SaturnusDJ commented 5 years ago

And here the question is if we can use _locationname to set custom, user defined states, and therefore we first need to be sure it won't mess up anything in Home Assistant.

ties commented 5 years ago

In addition, using this pattern may cause another issue. I have a set-up with two access points (with 802.11R) and the order of connects and disconnects may differ from what you expect. I observed this pattern:

AP1.connect
...time passes, client roams...
AP2.connect
AP1.disconnect
...
AP2.disconnect

I looked at the implementation quickly. Implementations of device scanners can add additional fields. The API call can not for now.

If I were to implement a fix for this I would add an additional field (to have different AP's report using a different name over the API, like device-trackers) and then use an AppDaemon to fix it for myself.

SaturnusDJ commented 5 years ago

As I am playing around again with the 2 ap's I am seeing that when switching between ap's only the router handles a DHCP related message. This message always appears when switching between the ap's. Might be useful.

Another option to deal with 'false _nothome messages' is to add an option to delay the home message for x seconds. Doesn't sound like the ideal solution but 1-2 seconds of delay might even be enough.

https://github.com/mueslo/openwrt_hass_devicetracker/issues/20 is interesting and highly related too.

SaturnusDJ commented 5 years ago

Ah got a situation now. Phone switched to other access point without disassociating from the original ap this time. So after a few minutes the original ap timed the device out and sent the _nothome state to HA.

ties commented 5 years ago

Ah got a situation now. Phone switched to other access point without disassociating from the original ap this time. So after a few minutes the original ap timed the device out and sent the _nothome state to HA.

I think this is fixable with an additional field containing the access point + change in home assistant.

Preferred approach: logic that sets present when mac has an active connection to an access point instead of last message for mac address was a connect on any access point or using location_name + an AppDaemon that combines the different messages intelligently.

SaturnusDJ commented 5 years ago

It's happening every time now. I am _nothome all the time haha.

@ties, you mean a master? Maybe set up one access point as such and the others just report to it. I guess there must be some functionality like that already in OpenWRT.

ties commented 5 years ago

@ties, you mean a master? Maybe set up one access point as such and the others just report to it. I guess there must be some functionality like that already in OpenWRT.

There is such functionality in OpenWRT but it is for authentication only. I am using 802.11R support so stations can roam between access points. This means that they key material they use is shared between AP's when a station roams between them.

Unfortunately there does not seem to be centralized tracking of connected clients for OpenWRT. In general this is called "wireless controller" functionality (and done by a central device instead of on an access point).

I am not_home +- 15 minutes after I move between accesspoints (some timeout) even though the 'new' accesspoint knows I am connected to it...

mueslo commented 5 years ago

I guess the solution is to add authority/client type devicetracker instances to this code where the clients simply forward all state changes to the authority and only the authority talks with HomeAssistant

Am Do., 10. Jan. 2019, 13:21 hat Ties de Kock notifications@github.com geschrieben:

@ties https://github.com/ties, you mean a master? Maybe set up one access point as such and the others just report to it. I guess there must be some functionality like that already in OpenWRT.

There is such functionality in OpenWRT but it is for authentication only. I am using 802.11R support so stations can roam between access points. This means that they key material they use is shared between AP's when a station roams between them.

Unfortunately there does not seem to be centralized tracking of connected clients for OpenWRT. In general this is called "wireless controller" functionality (and done by a central device instead of on an access point).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mueslo/openwrt_hass_devicetracker/issues/16#issuecomment-453077315, or mute the thread https://github.com/notifications/unsubscribe-auth/AAzvh_3w8niRu5ihojJJSrMdn-PPYfTbks5vBzA0gaJpZM4ZWmIS .

ties commented 5 years ago

I guess the solution is to add authority/client type devicetracker instances to this code where the clients simply forward all state changes to the authority and only the authority talks with HomeAssistant

That would definitely work and is 'cleaner' in my opinion than doing new state transitions with a presence plugin for hass after the /api/.../see call has been made (I was thinking of a 'presence fusion' plugin).

My standard approach nowadays for this would be mqtt + a daemon that interprets the state transitions. Unfortunately a daemon in python is a bit heavy for openwrt but this could run on the hass side.