ioBroker.zigbee: Adapter not starting after 1.5.5 update

Thank you for the detailed breakdown.

• Updating the network: Previously you could have ran into problem pretty quickly by updating configuration and easily losing your network, the startup strategy SM and several protections are there to prevent such situations. Rather fail with a warning or error than to lose your network by making a small mistake. Updating the network in the means of actually updating the network without the need to re-pair devices is pretty complicated and may not even be possible on a lot of LE devices, so that’s why you are basically unable to “change network parameters” without re-pairing devices.

Just to clarify. When i mentioned “keep the changes and reprovision the network” in my post above this implied that all components need to be paired again to the new network. I do not currently see an option for an automatic network parameter change.

A.

So my suggestion here is: If this value is once known, fetch it and make the field in IOBroker non editable. I think this would lead to less confusion in future. I really have no idea, if I changed this value in past because of the change from a cc2531 to the current CC2538. If I did that, it would make sense why all this happened. And I’m sure im not the only one who (maybe) did that.

This is not a sensible option. The user should have the option to change the network parameters if desired. Else we could also do the same for channel and PanID, which, if changed on an existing network will currently generate a similar error message.

What is considered is to not throw the adapter in a startup loop but generate a message for the user offering one of 2 choices:

• undo the change and start with the existing parameters
• keep the changes and reprovision the network. A.

And let me ask: Why is this field from the Extended PAN ID editable at all? For me, it looks like this would lead to problems every time you change that to something random?! If there is a EPANID from the adapter itself, why not use that and make it non editable, even not visible?

Edit: I sniffed my Zigbee Network with Wireshark and got the real Extended PAN ID broadcasted to the Zigbee network, it’s not the “configured” one but the one from the adapter itself. With this knowledge, the set EPANID in IOBroker is somehow useless from my sight of view…

When the adapter is initially installed, the ext-pan ID needs to be set by the adapter configuration. Without this, the herdsman would always use DDDDDDDDDDDDDDDD as extPanID, which can cause issues when running multiple instances.

The entire issue with reversed pan ID’s is caused by a refactoring which was done in the Herdsman about 2 weeks ago. It seems (even though this cannot be certain at this point) that a bug in this refactoring caused the entry to be reversed at some point. The entire method of checking extPanId vs a stored extPanId is also a new addition in the Herdsman as a result of this refactoring.

Unfortunately, the text in the error messages may cause confusion when considering the iobroker.zigbee Adapter, as “configured” refers to the entries made in the iobroker.zigbee Adapter configuration, while “adapter” entry refer to the ExtPanID stored in the backup of the zigbee network configuration. This does match the result from your network sniffer. This PanID was at one time set from the zigbee Adapter, and has been used since to safeguard your zigbee network. Why this does not match the entry you had in your configuration is very hard to determine at this point.

The ExtPanID from the configuration is transferred to the zigbee-herdsman in reversed byte order. For Compatibility, this has to remain as any change on this will cause similar issues to the one you had for people updating to 1.5.5, which adds to the confusion of the error message as the “configured” PanID will have a reverse byte order to what has been entered in the zigbee Admin.

A.