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

Handle 'trailing' disconnect when station roams in 802.11r setup #22

Open ties opened 5 years ago

ties commented 5 years ago

[As a user] when a station (mobile phone) roams between accesspoints, I expect the station to be 'connected' while it is connected to any of the access points.

At the moment the script sets the status to disconnected when the connection to the previous access-point times out (see logs below).

I consider a station to be disconnected when it is not connected to one of the access points. I will try setting "disconnect on low ack" again (but this causes problems with Archer C7 V2) to reduce the duration of this period.

I log to a remote machine. In these logs the following lines appear:

/var/log/remote# cat AP1/messages.1 AP2/messages.1  | grep "84:c7:de:ad:be:ef" | grep hostapd | sort | ack -i ap1 --passthru
Nov 27 07:23:58 ap1 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 07:23:58 ap1 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 07:23:58 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 07:23:58 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 07:29:18 ap2 hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:de:ad:be:ef
Nov 27 07:29:18 ap2 hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:de:ad:be:ef
Nov 27 07:29:18 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: disassociated due to inactivity
Nov 27 07:29:18 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: disassociated due to inactivity
Nov 27 07:29:19 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Nov 27 07:29:19 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Nov 27 07:48:16 ap2 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 07:48:16 ap2 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 07:48:16 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 07:48:16 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 07:48:37 ap1 hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:de:ad:be:ef
Nov 27 07:48:37 ap1 hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:de:ad:be:ef
Nov 27 07:58:48 ap1 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 07:58:48 ap1 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 07:58:48 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 07:58:48 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 07:59:19 ap2 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 07:59:19 ap2 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 07:59:19 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 07:59:19 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 08:05:24 ap1 hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:de:ad:be:ef
Nov 27 08:05:24 ap1 hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:de:ad:be:ef
Nov 27 08:05:24 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: disassociated due to inactivity
Nov 27 08:05:24 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: disassociated due to inactivity
Nov 27 08:05:25 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Nov 27 08:05:25 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Nov 27 08:34:14 ap1 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 08:34:14 ap1 hostapd: wlan1: AP-STA-CONNECTED 84:c7:de:ad:be:ef
Nov 27 08:34:14 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 08:34:14 ap1 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: associated (aid 2)
Nov 27 08:39:25 ap2 hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:de:ad:be:ef
Nov 27 08:39:25 ap2 hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:de:ad:be:ef
Nov 27 08:39:25 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: disassociated due to inactivity
Nov 27 08:39:25 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: disassociated due to inactivity
Nov 27 08:39:26 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Nov 27 08:39:26 ap2 hostapd: wlan1: STA 84:c7:de:ad:be:ef IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

related to #16, #17.

ties commented 5 years ago

I added a source_name field containing the hostname of the station in the body of the pushed events in https://github.com/ties/openwrt_hass_devicetracker/commit/33923eba0f32a07bece8da3ef1b8b861b3c12a6d. Will try to normalise this data in an AppDaemon.

SaturnusDJ commented 5 years ago

@ties Did you get this working?

ties commented 5 years ago

@SaturnusDJ the source_name field is definitely working.

I have not created the AppDaemon (or, what I planned later, modified hass) yet. My notion for how device trackers track presence differs from how it is implemented in hass and likely conflicts with how people would be implemented.

I need to merge states at the device level, not at the person level. And I need a complex state machine (since the disconnect on AP1 can come after the join on AP2). I decided to wait for the person component to evolve.

"Merging" presence states was moved to the person component. This will work for my use case if hass/the API got a way of expressing presence per MAC x per source instead of per type x per MAC.

SaturnusDJ commented 4 years ago

Coming back to the source_name field... Today I uninstalled v0.1.1 and installed v0.1.4 and then manually copied the files in that were affected by the last commits. Uncommented the source_name field and gave it a value on each router. Nevertheless, the value is not shown in HA, and also not in the syslog of the routers.

ties commented 4 years ago

Today I uninstalled v0.1.1 and installed v0.1.4 and then manually copied the files in that were affected by the last commits. Uncommented the source_name field and gave it a value on each router. Nevertheless, the value is not shown in HA, and also not in the syslog of the routers.

That is strange. Are you sure it is running the correct code?

I do see the following in syslog:

Dec  4 18:34:33 <routername> /usr/lib/hass/push_event.sh: post response [{"attributes": {"friendly_name": "Named iPhone", "icon": "mdi:cellphone-iphone", "source_name": "<routername>", "source_type": "router"}, "context": {"id": "shd237cdsdghexidstring", "parent_id": null, "user_id": null}, "entity_id": "device_tracker.named_device", "last_changed": "2019-12-04T17:02:58.600164+00:00", "last_updated": "2019-12-04T17:34:33.132882+00:00", "state": "home"}]

I do also see the source_name in the home assistant UI once I open the device trackers history.

SaturnusDJ commented 4 years ago

Outputs:

Thu Dec  5 00:33:53 2019 user.debug /usr/lib/hass-tracker/push_even: build_payload 00:11:22:33:44:55 Mi_Hub.lan 99:00
Thu Dec  5 00:33:53 2019 user.debug /usr/lib/hass-tracker/push_even: post {"mac":"00:11:22:33:44:55","host_name":"Mi_Hub.lan","consider_home":"99:00","source_type":"router","attributes":{"source_name":""}}
Thu Dec  5 00:33:53 2019 user.debug /usr/lib/hass-tracker/push_even: post response [{"attributes": {"friendly_name": "Mi Hub", "icon": "mdi:home-plus", "source_name": "", "source_type": "router"}, "context": {"id": "09ff2f10c86d4cbc83f6bf7f3baba10f", "parent_id": null, "user_id": null}, "entity_id": "device_tracker.mi_hub", "last_changed": "2019-12-04T23:33:53.246467+00:00", "last_updated": "2019-12-04T23:33:53.246467+00:00", "state": "home"}]
~# cat /etc/config/hass-tracker 
config hass-tracker 'global'
        option host 'ip:port'
        option source_name 'Nicerouter1'
        option token 'token12345678'
        option timeout_conn '99:00'
        option timeout_disc '00:00:01'
...

Nothing for me. Also nothing when commenting out source_name and restarting hass-tracker service. uci get system.@system[0].hostname returns the hostname correctly.

mueslo commented 4 years ago

Seems like the source name is not actually being sent. Maybe I introduced a bug in the configurable source name.

On Thu, 5 Dec 2019, 08:11 SaturnusDJ, notifications@github.com wrote:

Outputs:

Thu Dec 5 00:33:53 2019 user.debug /usr/lib/hass-tracker/push_even: build_payload 00:11:22:33:44:55 Mi_Hub.lan 99:00 Thu Dec 5 00:33:53 2019 user.debug /usr/lib/hass-tracker/push_even: post {"mac":"00:11:22:33:44:55","host_name":"Mi_Hub.lan","consider_home":"99:00","source_type":"router","attributes":{"source_name":""}} Thu Dec 5 00:33:53 2019 user.debug /usr/lib/hass-tracker/push_even: post response [{"attributes": {"friendly_name": "Mi Hub", "icon": "mdi:home-plus", "source_name": "", "source_type": "router"}, "context": {"id": "09ff2f10c86d4cbc83f6bf7f3baba10f", "parent_id": null, "user_id": null}, "entity_id": "device_tracker.mi_hub", "last_changed": "2019-12-04T23:33:53.246467+00:00", "last_updated": "2019-12-04T23:33:53.246467+00:00", "state": "home"}]

~# cat /etc/config/hass-tracker config hass-tracker 'global' option host 'ip:port' option source_name 'Nicerouter1' option token 'token12345678' option timeout_conn '99:00' option timeout_disc '00:00:01' ...

Nothing for me.

— 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/22?email_source=notifications&email_token=AAGO7B7NDLVRZJAS75TQMUTQXBBJPA5CNFSM4GM27P72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF67XXA#issuecomment-561904604, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGO7BZCU3PIKSSKNJ47VBDQXBBJPANCNFSM4GM27P7Q .

mueslo commented 4 years ago

Oops, a quick glance over the code shows me that I did miss renaming a variable.

@SaturnusDJ let me know if https://github.com/mueslo/openwrt_hass_devicetracker/commit/23fa712a1d135f91acd1480860d5f60fea9086f7 fixes it for you.

SaturnusDJ commented 4 years ago

@mueslo that works! Via config and via commented out variant also. Great.

Hope the multi router setup issue can be solved soon too.

ties commented 4 years ago

Good to hear that it worked! It has been a while since I worked on this.

It definitely needs changes on the side of Home Assistant, right now MAC addresses are seen as unique while in fact the combination of <access point, mac> is unique.

andre-pt commented 4 years ago

hey great work! I have just integrated this component couple days ago and figured I have the same problem: I have multiple APs. I'm happy someone else raised before and it was already fixed :)

Would it be possible to create a package and publish it?

thanks a lot Andre

SaturnusDJ commented 4 years ago

@andre-pt That problem is not solved.

I was thinking to only use mobile app (iOS) now but it seems that app is also not reliable as sometimes it does not come up after restart of phone, etc. It is a painful fact that in some cases presence detection in Home Assistant is extremely hard to get reliable.

Can still try https://github.com/gcobb321/icloud3

(Of course these two possible solutions would likely not work to detect if a device is on a specific floor or near/connected to a certain access point.)

mueslo commented 4 years ago

Good to hear that it worked! It has been a while since I worked on this.

It definitely needs changes on the side of Home Assistant, right now MAC addresses are seen as unique while in fact the combination of <access point, mac> is unique.

One way to implement this would be to send not the mac address but explicitly the device id made up of access point id plus MAC address. Then you would get N*M devices if you have N real devices and M access points. You would then be able to merge them in the Person component. However, this seems like a very unelegant, dirty way to do this.