search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
69.87k stars 28.97k forks source link

ZHA shows 2 coordinators after migration #118237

Open cemilbrowne opened 1 month ago

cemilbrowne commented 1 month ago

The problem

I migrated from HA Yellow built-in zigbee radio to a Skyconnect, prior to migrating from HA yellow -> Rpi (HA Yellow hardware was dying).

Everything now appears to work, but my ZHA config appears to show two 'EZSP by Silicon Labs' devices, and they both appear to be connected - impossible since I've turned off the HA yellow.

Somehow, it appears the config is split across both. Both appear to have different IEEE mac addresses.

I'm also (potentially coincidentally) having some zigbee issues, specifically Network Busy 161 errors. I have a total of 29 devices.

What version of Home Assistant Core has the issue?

core-2024.5.5

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

ZHA

Link to integration documentation on our website

https://www.home-assistant.io/integrations/zha/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 1 month ago

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

Code owner commands Code owners of `zha` 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 zha` 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)

zha documentation zha source (message by IssueLinks)

puddly commented 1 month ago

Both appear to have different IEEE mac addresses.

This would be a problem and means that your Zigbee network is not in a good state. The IEEE address is rarely used in communication but if your coordinator's original address was not copied, your new coordinator is only superficially working. Any more complex device operations (e.g. joining) will cause unexpected failures.

To fix this, download a backup JSON file from the ZHA config page:

image

Update the firmware of your SkyConnect (https://skyconnect.home-assistant.io/firmware-update/) and replace all instances of the incorrect IEEE address with the address of your original coordinator. Then, perform a migration and re-configure the current coordinator. When you upload the fixed JSON, the new address will be written.

cemilbrowne commented 1 month ago

Hi @puddly ,

Thank you for the troubleshooting. Will try today. For my reference:

1) is there an obvious way to determine "correct" and "incorrect" IEEE addresses? Are they in some way inscribed on HA yellow? Given that in theory we copied over addresses, I want to make sure I use the right one. 2) I don't see a firmware update available for SkyConnect at that link. I've found updates at SIlabs. 3) I assume I'll manually edit the backup - am I then restoring manually edited YAML file?

Also, interestingly, I was able to join a device yesterday without issue (seemingly).

Lastly, I'd propose an update to the documentation around migrating to a new radio.

In the case of HA yellow, it's not possible to unplug the old radio, leaving one in the uncomfortable position of not knowing what the right course of action is. I'd suggest we make that part of the workflow a little clearer. Otherwise, moving network appeared to function immediately and well. Kudos!

johnlento commented 2 weeks ago

I actually ran into this issue today to and am sort of dead in the water. I was getting all kinds of Watchdog errors on a ZBDongle-P so I thought I would migrate to a ZBDongle-E and compare. I did my migration and it was successful but I noticed both coordinators too like in this post. I ended up deleting the old but the network on the new coordinator never really came back. I ended up trying to migrate back to the ZBDongle-P but with the same results.

I actually have a ZHA backup from before I mucked with it however following the above steps cause an "Unknown error". I have flashed, re-booted, migrated, etc but everytime I go to upload the manual backup and restore I get "Unknown error". The debug logs have this:

2024-06-25 06:27:30.603 ERROR (MainThread) [aiohttp.server] Error handling request Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py", line 452, in _handle_request resp = await request_handler(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/web_app.py", line 543, in _handle resp = await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/web_middlewares.py", line 114, in impl return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 92, in security_filter_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 83, in forwarded_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 26, in request_context_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 85, in ban_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 242, in auth_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 32, in headers_middleware response = await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 73, in handle result = await handler(request, **request.match_info) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 81, in with_admin return await func(self, request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 285, in post return await super().post(request, flow_id) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 70, in wrapper return await method(view, request, data, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 122, in post result = await self._flow_mgr.async_configure(flow_id, data) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 368, in async_configure result = await self._async_configure(flow_id, user_input) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 414, in _async_configure result = await self._async_handle_step( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 517, in _async_handle_step result: _FlowResultT = await getattr(flow, method)(user_input) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/zha/config_flow.py", line 464, in async_step_choose_automatic_backup return await self.async_step_maybe_confirm_ezsp_restore() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/zha/config_flow.py", line 483, in async_step_maybe_confirm_ezsp_restore return await self._async_create_radio_entry() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/zha/config_flow.py", line 769, in _async_create_radio_entry await self.hass.config_entries.async_setup(self.config_entry.entry_id) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1809, in async_setup raise OperationNotAllowed( homeassistant.config_entries.OperationNotAllowed: The config entry HubZ Smart Home Controller - HubZ ZigBee Com Port, s/n: 915002D9 - Silicon Labs (zha) with entry_id 193501118fea3668995281cd29570750 cannot be set up because it is already loaded in the ConfigEntryState.SETUP_IN_PROGRESS state

I also see many:

Source: components/zha/radio_manager.py:203 Couldn't add Key(redacted)

Any ideas on how to successfully restore?

johnlento commented 2 weeks ago

For those that may run across my post...it turns out the restore works but just says unknown error. I had to reboot after the failed restore and let the stick initialize. Once it did, I just re-migrated again for good measure, and it worked fine.