-
-
Notifications
You must be signed in to change notification settings - Fork 28.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unifi integration devices become unavailable periodically #114196
Comments
If it started to show up in the last few days it's something in your system either unifi or home assistant. Try restarting everything. |
It has probably been going on longer than a few days, just not noticed I think. |
@Kane610 I started looking into this yesterday because I have been noticing something similar the past few days, maybe since I switched to unifi network application 8.1.113 If I have everything (HA and unifi) up and running, and then restart just the unifi network application, I get an unexpected response (in HA unifi integration) after authentication in aiounifi and the websocket crashes and doesnt seem to recover If I then "restart" the unifi integration, it all comes up perfectly This is reproducible for me everytime
I can do some more testing and try and get you a clean debug log, but I did want to echo that this seems to be an actual issue to me @Gazoonky what version of unifi are you running? |
Exactly the same version as yours @xconverge . I can also reproduce the issue by restarting UniFi application, just as you have. I've added some log entries in my original post. |
I also had lags in several devices/entities updates. |
How do you only restart the network app? |
I run it self hosted with this container https://github.com/linuxserver/docker-unifi-network-application So I just restart the container running the network application in docker If you are on a UDM I would try something like this https://community.ui.com/questions/Restarting-Network-Controller-Via-SSH/584f72c6-c37e-4e8c-abfc-7f3b826eaf33 |
In HA, Settings, Add-ons, UniFi then restart. |
Running UDMP, I can't reproduce it by just restarting the controller. I do get something similar but not exactly the same when restarting the controller. |
So are you suggesting it's the UniFi Network application add-on that is causing the problem? |
No, only that its not trivial to recreate |
Seeing this error in your provided logs is something new |
Does it recover and reconnect for you or stay disconnected until you reload the integration? |
It reconnects properly after |
Here I generated a fresh log set for you since I can reproduce the problem every single time I restart my unifi network application:
What is that "Talking to UniFi OS device:" log statement, it changes state between the retries and the reload |
It is just a log to show what the hosting way of the network app, it performs a get request towards the direct url and if it receives a http OK then it is determined to be a Unifi OS system |
Assuming you mean Unifi OS as in what runs on a UDM, in my case it should ALWAYS be false because I do not run unifi OS. The fact that the retries all show it as true seems strange to me, and the reloads show it as false (And work) I will look at the code but is there any behavior difference or is it just a log? |
Aha there is a functional difference, so I think this check needs to be tweaked a bit, if 8.1.XX branch of unifi controller maybe started returning OK for this even in the case of a self hosted controller?
let me figure out if I can tweak this code a bit to just always return false and see if my problems go away |
It should be False yes
It is unknown to me if this is something that has changed recently, I would guess that it is
It adjusts the url paths as they are different between Unifi OS hosted apps and self hosted, one example https://github.com/Kane610/aiounifi/blob/145e60e4239964b5f99e91e6cb5c6fcda0dd5817/aiounifi/interfaces/connectivity.py#L60 |
Is there a way for me to edit the code for the HA integration without forking it to a custom_component? Otherwise I can move over to the aiounifi repo instead and try to run some tests from that side instead |
Depend on how you run your Home Assistant instance, it's a bit more cumbersome to edit files in a container environment as it gets reset on restart. There is no reconnection logic in the aiounifi library but would be quite easy to just doa loop somewhere in the main.py if you run it from the CLI which shouldn't really be far away from how the integration handles reconnects |
Ok, I will just pull the unifi integration into a custom component for now so I can continue to help/test effectively |
Ok having a bad time trying to get it done, so I will just move over to the aiounifi repo later tonight and see if I can come up with a reproducible test file and example and maybe a solution I think any code change would be there anyways |
@Kane610 I am able to see the similar behavior with aiounifi. Restart unifi, then try to connect:
It is also detecting it as unifi OS on these fail attempts, but changing the code to always return false for that made no difference to behavior for me. So to me, the library seems like it is working pretty well or at least throws manageable errors, which brings me back to why does reloading work when reconnecting does not... I pulled the integration out to a custom_component now and it is running, so I can test any ideas I come up with, not really sure what's going on yet |
Got it! this is the proper fix Kane610/aiounifi#625 This is the hack that I used to test it from this integration
|
Fix is merged and will be part of 2024.4 release. Try out the beta if you want it early |
Hi |
This has been communicated as fixed, try out the beta and see if that resolves your problem |
2024.4 has indeed fixed the issue for me. Thanks |
👍 glad my comments/fix made sense here, I was starting to feel crazy |
Thanks for contributing ❤️ |
The problem
Unifi integration usually rock solid but in last few days, possibly longer and I haven't noticed, all devices become unavailable and remain so until Unifi integration is reloaded
What version of Home Assistant Core has the issue?
core-2024.3.3
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Supervised
Integration causing the issue
Unifi
Link to integration documentation on our website
No response
Diagnostics information
config_entry-unifi-8cb5385598408770151668677b786035.json
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/unifi/hub/websocket.py", line 104, in _reconnect
await self.api.login()
File "/usr/local/lib/python3.12/site-packages/aiounifi/controller.py", line 74, in login
await self.connectivity.check_unifi_os()
File "/usr/local/lib/python3.12/site-packages/aiounifi/interfaces/connectivity.py", line 51, in check_unifi_os
response, _ = await self._request("get", self.config.url, allow_redirects=False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aiounifi/interfaces/connectivity.py", line 122, in _request
async with self.config.session.request(
File "/usr/local/lib/python3.12/site-packages/aiohttp/client.py", line 1194, in aenter
self._resp = await self._coro
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aiohttp/client.py", line 425, in _request
raise RuntimeError("Session is closed")
RuntimeError: Session is closed
Logger: aiounifi.interfaces.connectivity
Source: components/unifi/hub/websocket.py:80
First occurred: 21:36:08 (4 occurrences)
Last logged: 21:45:20
Server handshake error connecting to UniFi websocket: '200, message='Invalid response status', url=URL('wss://192.168.2.23:8443/proxy/network/wss/s/default/events')'
Logger: homeassistant.components.unifi
Source: components/unifi/hub/websocket.py:82
integration: UniFi Network (documentation, issues)
First occurred: 21:36:08 (4 occurrences)
Last logged: 21:45:20
Websocket setup failed
Additional information
Unifi Network application 3.0.4
The text was updated successfully, but these errors were encountered: