Unifi constantly going offline

Hi all

I’m using the Unifi Binding because I’m planning to switch the PoE ports (disable certain access points at night).
I noticed that the controller keeps flipping from OFFLINE to ONLINE and back again roughly every 10 seconds.

In the Openhab UI I sometimes see

COMMUNICATION_ERROR
Unknown HTTP status code 500 returned by the controller

In the event log
Thing 'unifi:controller:d6c963c630' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)

I’m using a DreamMachine SE. OH 3.3.

Any idea why that is happening or how I can further debug that?

I don’t think I can cleanly control the PoE ports if the bridge keeps going offline.
Thanks!

Which version of the binding do you use. There are some fixes related to the PoE ports, which are fixed in the market place binding. Can you test with the marketplace version of the binding?

I’m still on OH 3.3 and used the offiical binding. Thanks for the hint, will try the marketplace version!
Although it’s not a PoE issue, it’s the bridge connection going down. Didn’t start playing around with the PoE ports just yet. But maybe there’s also some improvement on the bridge connection.

There were issues with data retrieval which caused the bridge (which gets all data at once) to get an error resulting in the bridge going offline.

1 Like

Installed the version from the market place, doesn’t change anything unfortunately. It still flips constantly from OFFLINE to ONLINE and back again.
To make sure, I’ve installed “UniFi binding (beta)” under Settings → Bindings → Community Marketplace.

Will upgrade to OH 3.4 soon, will test again after that upgrade.

Also the upgrade to OH 3.4.0 didn’t change anything unfortunately :confused:

It could be parsing data fails by the binding. Can you run with log level debug/trace and see if you get additional exceptions. If so can you send the log to me via dm so I can fix that. Best is to run with the market place version as that is the most up-to-date for 3.4.

1 Like

Thanks a lot, sent you a log via DM. It was generated with the UniFi binding (beta) from the community marketplace.

Hey All,

i just want to show my intrest. Since 3-4 days my controller keeps flipping from on to off aswell. I’m running Openhab 3.4 with the official distributed binding for Unifi. Both are running on an RPi 4. Curiously disabling and enabling instantly makes the controller work again.

Have a nice day!

The official binding still have a bug that can cause this behavior. Can you try the marketplace binding. It might also be another problem, but using the marketplace binding might work in your case.

Thanks for your tipp. I switched to the marketplace version, but it did not change the seen behaviour. My controller still goes offilne (i usually notice it in the morning). The UI says there is a timeout for a response. I’ll probably automate the disable/enable routine to get around that quick and dirty.

Can you run the binding with log level set to trace and send me the log via direct message. If it’s not automatically going online again it means something else might be wrong with the binding. Because it should not stay offline.

I’ve updated the binding in the marketplace and improved the code to better handle certain edge cases. Can you check if this fixes your issues?

Unfortunately, same thing still happens.

In the events.log, here is the entry when the controller goes offline (note the exact time):

2023-01-14 12:46:19.539 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'unifi:controller:d6c963c630' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)

The openhab.log on TRACE only shows the NPE, but no information where it comes from:

2023-01-14 12:46:19.536 [DEBUG] [.internal.api.cache.UniFiClientCache] - Put #18 entries in UniFiClientCache: UniFiClient{
id: ... }
 - UniFiClient{...}
2023-01-14 12:46:19.538 [DEBUG] [.handler.UniFiControllerThingHandler] - Unhandled exception while refreshing the UniFi Controller unifi:controller:d6d963c63
java.lang.NullPointerException: null
2023-01-14 12:46:29.539 [TRACE] [.handler.UniFiControllerThingHandler] - Executing refresh job
2023-01-14 12:46:29.539 [DEBUG] [.handler.UniFiControllerThingHandler] - Refreshing the UniFi Controller unifi:controller:d6d963c630
2023-01-14 12:46:29.539 [TRACE] [.internal.api.UniFiControllerRequest] - >> GET https://192.168.1.1/proxy/network/api/self/sites
2023-01-14 12:46:29.560 [TRACE] [.internal.api.UniFiControllerRequest] - << 200 OK

Didn’t use marketplace bindings a lot in the past. I uninstalled and installed it again, that should install the latest version, right?
At least the updates from 13th January are in the description, so I assume that worked correctly.

I’ve improved the error logging. This should print the stacktrace. That should give information on where this goes wrong.
The correct way is indeed to uninstall and reinstall from the market place. New date is 16th January.

Mhh… this time, the binding doesn’t update. On the beta page, it still says latest is “13 Januari 2023”. Did something go wrong when deploying the latest version?

I haven’t updated the text on the marketplace topic, but in openHAB if you go to things and go to add a new thing you get a list of bindings. There it should show 16 januari.

Ah OK! Yes, it does:
image

But there is still no info in the log :slightly_frowning_face:

events.log:

2023-01-17 21:05:09.279 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'unifi:controller:d6c963c630' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)

openhab.log

2023-01-17 21:05:09.278 [DEBUG] [.handler.UniFiControllerThingHandler] - Unhandled exception while refreshing the UniFi Controller unifi:controller:d6c963c630
java.lang.NullPointerException: null
2023-01-17 21:05:19.280 [TRACE] [.handler.UniFiControllerThingHandler] - Executing refresh job
2023-01-17 21:05:19.280 [DEBUG] [.handler.UniFiControllerThingHandler] - Refreshing the UniFi Controller unifi:controller:d6c963c630
2023-01-17 21:05:19.281 [TRACE] [.internal.api.UniFiControllerRequest] - >> GET https://192.168.1.1/proxy/network/api/self/sites
2023-01-17 21:05:19.315 [TRACE] [.internal.api.UniFiControllerRequest] - << 200 OK

For completeness I’ll also report on this public topic that this issue has been found and a fix is available in the updated version in the marketplace (19-01-2023). It was at least present with UniFi Dream Machine devices that don’t report voltage/current of the PoE ports.

And for completeness, I’ll send a public “thank you” here and confirmation that my binding works very stable now :grin:
Thanks for keeping at it, appreciate your help!

1 Like