Skip to content
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

Closed
bnordli opened this issue Jan 4, 2024 · 64 comments · Fixed by #110658
Closed

Unifi Network: Devices marked as "away" after Unifi Network Upgrade #107061

bnordli opened this issue Jan 4, 2024 · 64 comments · Fixed by #110658
Assignees

Comments

@bnordli
Copy link
Contributor

bnordli commented Jan 4, 2024

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?

Unifi log:
"Network has been updated to 8.0.26. View Improvements Today, 3:14:52 AM"

All access points device trackers went from "home" to "away" at 03:14:14.
All other clients went from "home" to "away" at 03:14:49.

Additional information

I do have Unifi Protect running against the same UDM, which did not experience any issues.

@home-assistant
Copy link

home-assistant bot commented Jan 4, 2024

Hey there @Kane610, mind taking a look at this issue as it has been labeled with an integration (unifi) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of unifi can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Renames the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign unifi Removes the current integration label and assignees on the issue, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

(message by CodeOwnersMention)


unifi documentation
unifi source
(message by IssueLinks)

@bnordli
Copy link
Contributor Author

bnordli commented Jan 4, 2024

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
Network has been updated to 8.0.24. December 14, 3:22:37 AM -> APs went "away" 3:20:17, came back "home" 3:22:38

@deexiz
Copy link

deexiz commented Jan 4, 2024

Same issue for me.
Related #106130

@igoraj
Copy link

igoraj commented Jan 4, 2024

+1

@SK360
Copy link

SK360 commented Jan 4, 2024

Same issue here on 3.2.7 & 8.0.24. Broke a ton of Christmas automations 😞

@tescher
Copy link

tescher commented Jan 4, 2024

Same, and integration reload fixes it

@DenisMir
Copy link

DenisMir commented Jan 5, 2024

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.

@Kiphouder
Copy link

Kiphouder commented Jan 7, 2024

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.

@akajester
Copy link

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

@SK360
Copy link

SK360 commented Jan 7, 2024

I updated to network 8.0.26 and reloaded the integration and it’s been solid… so far

image

@akajester
Copy link

I updated to network 8.0.26 and reloaded the integration and it’s been solid… so far

I'm also on 8.0.26, reloaded twice and each time it lasts for 10 minutes, now everything is marked Away again.

@tescher
Copy link

tescher commented Jan 7, 2024

@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

@akajester
Copy link

akajester commented Jan 7, 2024

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.

@akajester
Copy link

akajester commented Jan 7, 2024

Update: removed / readded the integration and it worked for a little while, now everyone is marked away again.

@cardinal808
Copy link

cardinal808 commented Jan 7, 2024

+1 Experience the same issue as discribed by @akajester
Reloaded full integration, but issue persists, after 300 seconds its set to away. Reloading fixes the issue, but only temporary (for 300 seconds).

@akajester
Copy link

akajester commented Jan 8, 2024

After restore to December it's still broken until reload of integration, then breaks again.
Current versions: Core: 2023.12.3, Supervisor: 2023.12.0, Operating System: 11.3, Frontend: 20231208.2

@5bomen
Copy link

5bomen commented Jan 8, 2024

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:
Core 2024.1.2
Supervisor 2023.12.0
Operating System 11.3
Frontend 20240104.0

UDM:
Network 8.0.26
UniFi OS 3.2.7

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.

@OwnsJo
Copy link

OwnsJo commented Jan 9, 2024

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.

@Kane610
Copy link
Member

Kane610 commented Jan 9, 2024

It's probably not the case. I've broken stuff before. Just this thing is really weird

@kezon
Copy link

kezon commented Jan 11, 2024

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.
If any testing or logs are needed, i am ready to participate.
Good luck and thanks for any updates!

@thomasfilius
Copy link

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

@Kiphouder
Copy link

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.

My temporary solution using Automation below.

Change entity ID to match your controller (possible to select from UI)
Change entry_id to match you Unifi ID (in .storage/core.config_entries -> ctrl F -> unifi)


alias: Temp - Unifi reload when state away
description: |-
  Temporary solution because of bug
  https://github.com/home-assistant/core/issues/107061

  Reloads Unifi when status of UDM is away. 

  Will probably run every 10 minutes.
trigger:
  - platform: state
    entity_id:
      - device_tracker.dream_machine_special_edition
    from: null
    to: not_home
condition: []
action:
  - service: homeassistant.reload_config_entry
    data:
      entry_id: XXXXXXXf7a8610XXXc5b3798bXXXXXXX
mode: single

@robmc-itpro
Copy link

Same issue here after updating to unifi network 8.0.26.

Core
2023.11.3
Supervisor
2023.12.0
Operating System
11.1
Frontend
20231030.2

@akajester
Copy link

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.

@5bomen
Copy link

5bomen commented Jan 13, 2024 via email

@Kane610
Copy link
Member

Kane610 commented Jan 14, 2024

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.

No changes yet, some people are not affected, doesn't help in identifying the issue :)

@cardinal808
Copy link

@Kane610 , anything we can do to support you?

@Sebazzz
Copy link

Sebazzz commented Jan 14, 2024

Also having the issue:

Core 2024.1.3
Supervisor 2023.12.0
Operating System 11.4
Frontend 20240104.0

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.

@Kane610
Copy link
Member

Kane610 commented Jan 16, 2024

It's all good now since the latest Unifi OS update!

I hope you're right

@cardinal808
Copy link

Sadly no. Updated to Unifi OS 3.2.9 and was working properly for 8 hours and then all my devices went away.

@5bomen
Copy link

5bomen commented Jan 17, 2024 via email

@robmc-itpro
Copy link

Same issue here after updating to unifi network 8.0.26.

Core 2023.11.3 Supervisor 2023.12.0 Operating System 11.1 Frontend 20231030.2

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.

@Kane610
Copy link
Member

Kane610 commented Jan 17, 2024

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

How do you mean that it resolve itself? Does it go to unavailable for some time and then works again?

@bnordli
Copy link
Contributor Author

bnordli commented Jan 18, 2024

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.

@gmc1122
Copy link

gmc1122 commented Jan 18, 2024

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.

@5bomen
Copy link

5bomen commented Jan 18, 2024 via email

@Dave-Jones-1963
Copy link

I have the same issue with 3.2.9, where can I configure the "Reload UDM if away" config, as an automation?

@ShogunMan
Copy link

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'.

@Kane610
Copy link
Member

Kane610 commented Jan 19, 2024

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?

@ShogunMan
Copy link

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.

@zwizard
Copy link

zwizard commented Jan 19, 2024

I upgraded my Network application to 8.0.28 this morning and that appears to have fixed it for me.

@Dave-Jones-1963
Copy link

I have the same issue with 3.2.9, where can I configure the "Reload UDM if away" config, as an automation?

All working a treat now!

@TroLoos
Copy link

TroLoos commented Jan 22, 2024

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.

@pashdown
Copy link

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.

@5bomen
Copy link

5bomen commented Jan 26, 2024 via email

@TroLoos
Copy link

TroLoos commented Jan 28, 2024

I would like to ask user that experienced problems for feedback - does 3.2.9 with newest Network App work stable?

@kezon
Copy link

kezon commented Jan 28, 2024

I would like to ask user that experienced problems for feedback - does 3.2.9 with newest Network App work stable?

Hi,
I am on unifi os 3.2.10 cloud key g2+ and the sutomatin did not triger since 20.1.24… seems way better now from this perspective. If you need more details, ask.

@bnordli
Copy link
Contributor Author

bnordli commented Jan 28, 2024

My Unifi OS updated to 3.2.9 at January 17. That night I had the same problem. My APs went offline 5 mins before the upgrade log note, and my automation reloaded the Unifi integration to get them back online.

They stayed continuously online until January 26, then Unifi Network updated to 8.0.28.

Ever since the problem has been even worse, experiencing frequent drop outs (like others have reported in this thread). See timeline for AP device trackers for today: (My automation reloads the integration if one AP is away for 10 mins.)

image

I will be happy to try to provide some debug information. Just let me know what would be of interest.

@Kane610
Copy link
Member

Kane610 commented Jan 31, 2024

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
2024-01-30 21:50:24.861 DEBUG (MainThread) [homeassistant.components.unifi] Last received websocket timestamp: 2024-01-30 20:50:24.438440+00:00

@kazimnami
Copy link

I have the same issue

@imuncas
Copy link

imuncas commented Feb 15, 2024

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:
2024-02-15 05:03:01.097 DEBUG (MainThread) [homeassistant.components.unifi] Last received websocket timestamp: 2024-02-15 04:03:00.711086+00:00
2024-02-15 05:03:07.114 ERROR (MainThread) [aiounifi.interfaces.connectivity] Input is a zero-length, empty document: line 1 column 1 (char 0)
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/aiounifi/interfaces/connectivity.py", line 175, in websocket
callback(message.data)
File "/usr/local/lib/python3.12/site-packages/aiounifi/interfaces/messages.py", line 56, in new_data
self.handler(orjson.loads(raw_bytes))
^^^^^^^^^^^^^^^^^^^^^^^
orjson.JSONDecodeError: Input is a zero-length, empty document: line 1 column 1 (char 0)
2024-02-15 05:03:07.122 ERROR (MainThread) [homeassistant.components.unifi] Websocket disconnected
2024-02-15 05:03:22.172 INFO (MainThread) [homeassistant.components.unifi] Will try to reconnect to UniFi Network

So looks like the suspicion was correct, something with the websockets, and the reconnect is not successfull.

@Kane610
Copy link
Member

Kane610 commented Feb 15, 2024

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?

@imuncas
Copy link

imuncas commented Feb 15, 2024

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.
Can you share the concrete config I should add for the log levels? I mean what concretely means "enable debug logging for the library". I currently use:

logger:
default: warning
logs:
homeassistant.components.unifi: debug

@Kane610
Copy link
Member

Kane610 commented Feb 15, 2024

logger:
  default: info
  logs:
    aiounifi: debug
    homeassistant.components.unifi: debug

@Kane610
Copy link
Member

Kane610 commented Feb 15, 2024

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. Can you share the concrete config I should add for the log levels? I mean what concretely means "enable debug logging for the library". I currently use:

logger: default: warning logs: 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

@github-actions github-actions bot locked and limited conversation to collaborators Mar 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.