Radio migration in ZHA - should zigbee channel change?

Configuration Zigbee
,
1

Hey all

I’m trying to do a zigbee radio migration from Conbee II to SLZB-06M inside ZHA that I am using, and… I’m having issues.
In short - devices do not connect to the new zigbee device after migration.

A bit more details - I’m performing migration following the HA documentation, I did check conbee firmware (it’s OK), I updated and configure SLZB-06M, all according to the docs. During migration, IEEE is properly copied from conbee to slzb, automated backup restored, but devices do not connect. I was trying to power off all devices (cutting power at home) - no change. I have around 25 zigbee devices, some battery powered, some works as routers.

What I discovered is that few things changes during the migration.

  1. Zigbee channel changes from 15 to 25. I know that channel 25 is less occupied in here, but I was using the default 15, and not sure this is happening because of HA or because of SLZB-06M

  2. PAN ID and Extended PAN ID is different - not sure this is important at all

  3. Network key is different. How do I know? Once migration failed, I restored HA from backup, connected old zigbee stick and rebooted HA, and after reboot, ZHA was not working and suggested restore old config from backup (“Your zigbee radios network settings are inconsistent with the most recent network backup. This usually happens if another Zigbee integration has overwritten them… If you did not intentionally change your network settings, restore from the most recent backup” - after restore, on old stick, all works fine.

So - should Zigbee channel change during migration and if not - is it HA or the coordinator that is changing it?

regards

Mariusz

2

if i remember correctly you will have to go and repair your devices

3

I think that shouldn’t be required, at least looking at the guides - this is why IEEE is overwritten in the new coordinator…
Example video about that (unfortunately does not show the console so I’m not sure if channel changes or not)

Documentation says, that if you change the channel - you need to reconnect devices. I want to avoid that… I can see channel is mentioned in zigbee backup (channel 15) so not sure what and why it changes the channel (and if it is causing the problems)

4

just change the channel in zha

5

Tried that, but it’s not helping :frowning: Devices do not connect anyway. After radio migration ZHA in general seems… faulty (?). E.g. I can’t start another migration (to change back the radio or update config) - it gives me error without any text… below an example of 2nd migration (from SLZB to conbee II)

obraz
obraz1152×528 59 KB

6

I moved from a docker install to the full fat HASSIO on a different PC, and then I had to go around and pair everything back up again with the coordinator.

7

OK, but that’s completely different to what I am trying to do here… That’s why I would like to know, why HA is changing the zigbee channel during radio migration - and if this is by design (and devices should connect) or a bug or because of a coordinator (unlikely IMO)

8

Where you using that ConBee II with the ZHA integration before or where you using somethibg else like deCONZ/Phoscon or Zigbee2MQTT and are only now migrating to the ZHA integration?

And what firmware version was on the ConBee 2?

FYI, older ConBee firmware had bug that prevent full Zigbee network backup in ZHA, and without a full Zigbee network backup it is not possible to restore the full Zigbee network (inc. Zigbee channel used).

If you manage to create a full Zigbee network backup in ZHA then you should not need to re-pair Zigbee devices if all you are doing is a Zigbee radio migration, (and you did select to do a Zigbee channel change on purpose or by accident).

If you where using the ConBee with ZHA before then no, it should not automatially change the Zigbee channel as part of a radio migration, (and you should not need to re-pair all devices). The only pre-requicites are that you have updated ConBee firmware before migration (as bug in older ConBee firmware prevent full backup) and that you are actually uiing ConBee with ZHA before (and not using ConBee with deCONZ/Phoscon or other Zigbee gateway software). See both the ZBT-1 and the ZHA docs on those two topics:

as well as

and

If you are however using ConBee with deCONZ/Phoscon or other Zigbee gateway software then it is a different migratuin procedure which does require re-pairing devices (but still does not automatically change Zigbee channel), see:

9

Thx Hedda for your suggestions, although just now I made it work! And I HATE it!!
I mean I hate how it is documented…

So first answering your question and later - the solution.
Yes, I have been using ConBee 2 for few years, and yes, I’m aware about the bug and I checked it - firmware is fine (I think I wrote it in the original post)

Now - what I believe happened and why I had these issues.

During the process of migrating the ZHA radio, I followed this document Zigbee Home Automation - Home Assistant

In this document it says “Under Restore Automation Backup, choose the latest automatic backup and select Submit.” and I did exactly that.

Now, what I think that happens during the process is that there are TWO automatic backups performed - one before migration (before old device is disconnected) and second after, with a new device. I think that because the screen that allows me to restore the config looks like this

obraz
obraz736×342 35.9 KB

It’s in Polish, but it says “Please select automated backup to restore” and you can clearly see there are two backups. What I realised just now, is that 25c3 is PAN ID of my old ConBee II device followed by EXTERNAL_PAN_ID (starting with C1) while the other one, with PAN ID 4549 is the new (SLZB-06M) device.

Following the documentation, I was restoring the newest one. This is why I had new channel for Zigbee (set automatically - less occupied). Once I tried to restore the previous one - all worked fine!

The only thing I had to do in addition is to fix ZHA. It said it had problems, I clicked it, it said that channel (and other parameters) was changed, but in fact it wasy saying that the change was from new config (enforced by SLZB-06M) to old (from ConBee II) - so basically it was cause by backup restore. I confirmed to maintain the new config - and all devices are now connected to SLZB-06M - FINALLY

I registered an issue for the same, hope that helps others

10

FYI, I wrote that part in the documentation, (if I had
not there there Likley would be no documentation about it there at all as too few who contributing to the documentation), and I have never seen that problem you describe, so probably better if you submit a new issue for ZHA core in Home Assistant core instead as do not think what you describe happens to everyone → Issues · home-assistant/core · GitHub

If you you ”hate” how the documentation is written then why not contribute better documentation yourself, anyone can contribute to make it better it just as I have tried to do over the years, it does not help complaining about it here, this is an open source project so the documentation does not write itself → home-assistant.io/source/_integrations/zha.markdown at f0bf2f81c2ffc629b32443ab48b2540e61790879 · home-assistant/home-assistant.io · GitHub

PS: May I also suggest you read this and follow some of the advice there → How To Ask Questions The Smart Way I think that are several sections that apply here,like example How To Ask Questions The Smart Way and How To Ask Questions The Smart Way

11

Hey - I’m sorry, I was probably a bit emotional because I’ve spent a lot of hours trying to solve it (and now I am spending a lot trying to solve matter/thread issue on conbee)

I assumed (as you wrote - wrongly) that what happened to me is common. I couldn’t find any resource in the internet that would give screenshots or video about the process in details and I couldn’t compare to what I am having. That’s why I said “hate”. To be very clear - HA documentation is really good, but I’m not HA developer so I have no idea whether what happened to me is something that is normal but undocumented, or it’s not normal and a bug, and should be registered as one - this is why I created an issue towards documentation.

If you believe that’s documentation is correct but something is wrong with… what, ZHA? (but then I wouldn’t be the only one that has this issue, right?) then I’m more than happy to register in the proper place - I wanted to help others, this is why I explained the root cause - so others may find the answer.

For the same reason, I didn’t want to make a PR towards documentation - I just don’t have experience with other devices to judge whether what I had is normal or not.

I hope I explained myself - sorry if what I wrote was rude, that was not my intention.

PS. I wanted to check “How to ask questions” but looks like server that hosts it is having issues, I’m getting 503

12

heh, not this thread, but I found you there as well

Unfortunately I’m having issues that many reported on the internet
here Is beta ready? · Issue #3 · dresden-elektronik/openthread-r21 · GitHub

and here Matter, Thread, Conbee2 Problems

And again, no idea whether this is my config or something else… I think I checked everything, ipv6, comissioning via android, comissioning directly from matter ui in HA, trying via websocket of matter server… same error all the time (as explained above). I have only one matter device at home, and I don’t have HW to test any of these Matter Example Apps but welll.

I will create issue in dresden-elektronik repo but I don’t expect help there, looking at the number of responses… anyway - thx again, I think I will stop for the moment playing with matter/thread in HA