openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.9k stars 3.59k forks source link

[unifi] wireless client status does not change to offline #14006

Open resetpointer opened 1 year ago

resetpointer commented 1 year ago

Hi,

I am using OH-3.3.0 and w/ unifi binding. Everything works with unifi like being able to acquire IP address, RSSI, uptime etc.... The only problem I am facing is that the online status of a wireless client does not change to offline. I am not sure if that's typical, please advise if it should go to offline status.

thanks

ref: https://www.openhab.org/addons/bindings/unifi/#wirelessclient

One thing that's a little unique about my setup is that I have two network interfaces, with is directly attached to IOT network the another one is a public network. not sure if that is the issue.

resetpointer commented 1 year ago

I just found out that if I set considerHome to anything less than 20 second with a bridge's refresh rate at 90second, wireless online status won't update properly. As far as I can remember, this was not documented anywhere on the online unifi document.

Would someone explain why a considerHome setting from 1-10second causes online status not to update properly? Also, if this is a known bug, should we update the unifi document or at least have the extension default to a minimal period that's known not to cause the issue?

Thanks

Hilbrand commented 1 year ago

online status not to update properly?

Can you be a bit more precise by what you mean with 'not to update'?

The online status is determined in the binding by looking at the last seen status that is reported by UniFi. If you set your refresh rate at 90 seconds this means every 90 seconds it queries the UniFi controller and the last seen value it gets is used in the off/online calculation. Because the last seen value is always in the past it will offset the last seen with the consider home value. By default this is set to 3 minutes. Also because the UniFi api doesn't seem to always update last seen directly when a device goes off/on line this default value is relatively high. As there is some margin needed. If you set considerHome to a very low value (and certainly with 90 seconds bridge refresh). I expect it to always report offline, because the computed last seen will always be in the past.

Consider home was intended to increase the window to determine if a device is off/online. In that context making consider home smaller than the refresh rate could be seen as invalid. Maybe the binding should be changed to make considerhome offset with the refresh rate, or a warning should be given if consider home is smaller than the refresh rate.

resetpointer commented 1 year ago

Thank you for the clarification on refresh rate and considerHome settings.

What I found was that having a low considerHome value causes Unifi binding not able to detect true online status of a device.

so for example, with the following settings:

Bridge unifi:controller:home "UniFi Controller" [ host="11.0.1.90", port=8443, username="user", password="password", refresh=90, unifios=false ] {
        Thing wirelessClient onePlusPhone "TestPhone" [ cid="oneplus5t", site="default", considerHome=7]
}

Switch   MyPhone           "My Phone"             { channel="unifi:wirelessClient:home:onePlusPhone:online" }

MyPhone Switch would go online and never go back to offline despite the fact that it has disassociated from the Unifi Access Point. In some other test causes (ie. considerHome is set to 10), MyPhone would go online and then about 7 seconds later, it would go offline and never go back to online.

To your first point: "it queries the UniFi controller and the last seen value it gets is used in the off/online calculation". Does that imply that the Unifi Controller and OH server have to time sync with an NTP server and/or must be in the same time-zone?

To your second point: "making consider home smaller than the refresh rate could be seen as invalid. Maybe the binding should be changed to make considerhome offset with the refresh rate." If this was true, it should be documented or the runtime software should auto-adjust considerHome value to avoid this bug!

I also want to let you know that I figured about a way to get realtime status update from wireless clients as they join or depart from Unifi AP. This method does not involve polling. What I did was that I setup syslog on unifi to forward all syslog messages to OH3 Server. After that, I created a small syslog bridge that forwards all unifi's events to OH-Core. I just want to share this in case if anyone out there wanted instantaneous updates from Unifi. thank you.

Hilbrand commented 1 year ago

MyPhone Switch would go online and never go back to offline despite the fact that it has disassociated from the Unifi Access Point.

If you run the binding with TRACE log enabled you can check what UniFi actually reports. Is this on the IoT network? maybe on that setting UniFi never reports as offline?

In some other test causes (ie. considerHome is set to 10), MyPhone would go online and then about 7 seconds later, it would go offline and never go back to online.

Having a low considerHome would make the device go offline an likely never come online again, as the lastseen + considerhome is likely always in the past due to the polling frequency.

Does that imply that the Unifi Controller and OH server have to time sync with an NTP server and/or must be in the same time-zone.

The code computes with UTC. Therefor time-zone should not matter (assuming UniFi reports in UTC). The time should be in sync; that is, there is always some margin when using seconds resolution.

it should be documented or the runtime software should auto-adjust considerHome value

Could be good change to set consider home to be at least the refresh rate.

I just want to share this in case if anyone out there wanted instantaneous updates from Unifi.

This might be a good idea to post as topic on the forum in the tutorials-examples/solutions section.