-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
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 Network: Devices marked as "away" after Unifi Network Upgrade #107061
Comments
Hey there @Kane610, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) unifi documentation |
Possibly related: #104576 But I don't have any intermittent drop-offs, only after update of the Unifi Console. Looking through an access point history (which should always be "home"): UniFi OS has been updated to 3.2.7. December 15, 3:26:38 AM -> APs went "away" until manual integration reload |
Same issue for me. |
+1 |
Same issue here on 3.2.7 & 8.0.24. Broke a ton of Christmas automations 😞 |
Same, and integration reload fixes it |
Same here integration reload did fix it. Pretty annoying. We had all the shutters go up due to a automation looking at the tracker state. |
Same issue, reload fixes it for 10 minutes, after that, status is away again (and automations for when everyone is away run). When within the 10 minutes, I turn off wifi of a device, the device is marked away and when I turn on, it's home again. So it seems the integration only functions correctly the first 10 minutes. Anyone with a better solution then reloading the hub every 10 minutes? Ps I also noticed that in previous versions of HA the devices presence was unknown after reboot until the device connected to the network. Now it shows the last status. |
Same issue and behavior here |
I'm also on 8.0.26, reloaded twice and each time it lasts for 10 minutes, now everything is marked Away again. |
@akajester you must have some additional going on. When I reloaded the integration (after 8.0.26) mine also has been running fine for several days now. Your 10 minute thing must be something else or some interaction with something else going on in your system |
I did a full reboot of the rpi system and reloaded the integration and it started working, showing the proper device state. When I left wifi my phone went into Away status, but it never comes back. I checked the device status in Unifi and it's online, but in home assistant it's still offline. Also in Unifi the home assistant account has not logged in since I reloaded the integration. So something is definitely still wonky here. Like the integration will only login once to get the state, then just doesn't anymore. I'll try removing/readding the integration. |
Update: removed / readded the integration and it worked for a little while, now everyone is marked away again. |
+1 Experience the same issue as discribed by @akajester |
After restore to December it's still broken until reload of integration, then breaks again. |
Same here - I am using the UDM Pro, latest Network version, rebooted all Unifi devices, but still experiencing presense detection issues. Somehow HA looses visibility on all persons after a short time. HA: UDM: I have now created an automation that reloads the Unifi integration when it detects that the tracker of my UDM is away. That solves the issue for now. |
Many companies like Life360 & MyQ have removed API access to third party like HA - I hope unifi isn't doing the same.. Ended up doing the same as @5bomen - made node red flow to reload Unifi integration everytime is goes away. |
It's probably not the case. I've broken stuff before. Just this thing is really weird |
I confirm same behavior and symptoms as for many above, same latest versions of all systems - 8.0.26 network on cloud key gen2+, core 24.1.2, supervisor 2023.12, os 11.4, fe 20240104. |
Having the same issues as above with a UDM Pro on v8.0.26. HA core 24.1.2, supervisor 2023.12.0, OS 11.3 |
My temporary solution using Automation below. Change entity ID to match your controller (possible to select from UI)
|
Same issue here after updating to unifi network 8.0.26. Core |
Was this issue fixed? because it's been working for me for over 7 hours after the last upgrade and reload. |
My automation for recovery of an 'away'-status UDM just triggered, so I am
afraid not. 😞
Op za 13 jan 2024 04:39 schreef akajester ***@***.***>:
… Was this issue fixed? because it's been working for me for over 7 hours
after the last upgrade and reload.
Core 2024.1.3, Supervisor 2023.12.0, Operating System 11.4, Frontend
20240104.0.
—
Reply to this email directly, view it on GitHub
<#107061 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASNL62ABFNM3ENT4U4MFHQTYOH6XZAVCNFSM6AAAAABBMQMW52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQGI4DINJXGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
No changes yet, some people are not affected, doesn't help in identifying the issue :) |
@Kane610 , anything we can do to support you? |
Also having the issue:
Symptom is that device trackers either don't update (stay home or not_home) or they go eventually to the not_home state. My computer for instance, suddenly went offline at 00:03 in the night, as far as Home Assistant is concerned. Nothing was logged at the Unifi side. At the Home Assistant side, nothing stands out in the logging. BTW: The symptoms seem to happen at my side far less frequent. |
I hope you're right |
Sadly no. Updated to Unifi OS 3.2.9 and was working properly for 8 hours and then all my devices went away. |
Same here, my automation that reloads the integration when my UDM is
reported away has already triggered 7 times since upgrading Unifi to 3.2.9.
Op wo 17 jan 2024 om 00:01 schreef cardinal808 ***@***.***>:
… Sadly no. Updated to Unifi OS 3.2.9 and was working properly for 8 hours
and then all my devices went away.
—
Reply to this email directly, view it on GitHub
<#107061 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASNL62CMSY7FBEP7EC4WEQ3YO4BDPAVCNFSM6AAAAABBMQMW52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUGY2TONZQGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
The issue has calmed down quite a bit for me. Much less frequent and it tends to resolve itself, where as before I was having to reload the integration. I haven't made any changes since my last post. |
How do you mean that it resolve itself? Does it go to unavailable for some time and then works again? |
The issue repeated after update to UNiFi OS 3.2.9. My UDM Pro updated yesterday at 03:18:44 (according to the log), and both my APs went to "away" at 03:16:26, while the other device trackers changed to "away" at 03:15:26 (assuming that was when the UDM restarted to apply the update). I then have created an automation to reload the Unifi integration if an AP is away for 10 mins, and the device trackers therefore went back to "home" at 03:26:26. I have not updated HA since the OP. I have no problems with the device trackers between router updates. I have a 90 second time out for "time to away" on the integration configuration. |
It's been doing it for a while now, definitely before 3.2.9. At any rate, how do you "reload" the Unifi integration. i don't see a service call function to do just the Unifi integration (a single integration). Is there some other command to do that? I know you can reboot, but certainly not going to reboot ever 10 min. |
For reloading the Unifi integration you can call service named Home Assist
Core Integration: Reload config entry and target the Unifi integration.
This is what the yaml looks like:
alias: Reload Unifi if UDM away
description: ""
trigger:
- platform: state
entity_id:
- device_tracker.udm
from: home
to: not_home
condition: []
action:
- service: homeassistant.reload_config_entry
data: {}
target:
device_id: bbab3bd65606c58ad2f9fef71c3ca973
- service: counter.increment
metadata: {}
data: {}
target:
entity_id: counter.unifi_reload
mode: single
Op do 18 jan 2024 om 16:34 schreef gmc1122 ***@***.***>:
… It's been doing it for a while now, definitely before 3.2.9. At any rate,
how do you "reload" the Unifi integration. i don't see a service call
function to do just the Unifi integration (a single integration). Is there
some other command to do that? I know you can reboot, but certainly not
going to reboot ever 10 min.
—
Reply to this email directly, view it on GitHub
<#107061 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASNL62DA6KARX4PKIFTBFRLYPE6ITAVCNFSM6AAAAABBMQMW52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJYG4YDSMZVGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I have the same issue with 3.2.9, where can I configure the "Reload UDM if away" config, as an automation? |
Yesterday my UDM went 'away' 3 times for less than 30 seconds before coming back. No need to reload the integration any more as it picks up the correct status within a reasonable time. Still puzzled as to why it goes 'away'. |
You don't see any error messages in your logs? |
No, but I have quite strict log settings. Anything above warning should log anyhow. |
I upgraded my Network application to 8.0.28 this morning and that appears to have fixed it for me. |
All working a treat now! |
Honestly, I think the problem lies in underlaying Unifi OS - I have upgraded to 3.2.7 some time ago and even without Network upgrade, the problem showed up. I then downgraded Unifi OS to 3.1.16 and all was fine again. I am running now 3.1.16 OS with Network version 8.0.26 with no issues at all, and my Network has been upgraded several times in the meantime, none new Network version introduced this problem. I keep my fingers crossed that 3.2.9 with newest Network version solved this issue. |
How is this entity created? I can't find any reference to itself in the existing entities or with the "Configure - Create entities from network clients" menu, with either the name or the mac address of the UDM. |
In the Unifi integration specify that you want to monitor the Unifi network
components. It will automitcally generate a device tracker for each
component. The UDM will have the name you gave it.
Op di 23 jan 2024 18:27 schreef pashdown ***@***.***>:
… entity_id: - device_tracker.udm
How is this entity created? I can't find any reference to itself in the
existing entities or with the "Configure - Create entities from network
clients" menu, with either the name or the mac address of the UDM.
—
Reply to this email directly, view it on GitHub
<#107061 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASNL62H2UAQPXJDTHXF5YU3YP7XI5AVCNFSM6AAAAABBMQMW52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBWGU3DMOJWGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I would like to ask user that experienced problems for feedback - does 3.2.9 with newest Network App work stable? |
Hi, |
I've provided an additional log with the upcoming 2024.2.0 release (#109167) By configuring debug logging only for the integration and not library it will not be overly many prints logger:
default: info
logs:
homeassistant.components.unifi: debug This log should be seen every minute and then we can conclude if web socket stops altogether |
I have the same issue |
I've upgraded to 2024.2, and added the log messages. The issue is still happening, here are the logs, when my automation kicks in to reload the automation: So looks like the suspicion was correct, something with the websockets, and the reconnect is not successfull. |
Great! Can you enable debug logging for the library and catch the debug message which should show the content of this faulty web socket data? |
I can try. although not so easy. Sometimes it runs stable for a few hours, sometimes it's only 10 minutes and need to reload the integration. The log I configured previously was producing a lot of log messages, was very difficult to find anything. logger: |
logger:
default: info
logs:
aiounifi: debug
homeassistant.components.unifi: debug |
I've added code to catch that message and also print the bad data, it will be a part of the next release |
The problem
After the Unifi Network application updated (from 8.0.24 to 8.0.26) on my Unifi Dream Machine Pro, all device trackers was set to "away".
After reloading the integration, the trackers went back to "home", as expected.
I have seen this several times before, both when the Network application or the Unifi OS itself was updated, so I guess the errors coincides with the "soft reboot" of the UDM.
No relevant lines in the console logs (debug logs were not enabled).
What version of Home Assistant Core has the issue?
core-2023.12.0
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Container
Integration causing the issue
Unifi Network
Link to integration documentation on our website
https://www.home-assistant.io/integrations/unifi
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Additional information
I do have Unifi Protect running against the same UDM, which did not experience any issues.
The text was updated successfully, but these errors were encountered: