Okay, so I’ve found the old network configurations deep in an old log in the recycle bin, and I updated the coordinator without resetting it. Apparently it is going back to the wrong configs automatically. Not sure if this is the correct behavior or some bug.
If it is the correct behavior, how did the coordinator changes configs in the first place without a rest!
Hi @chris
I tried resetting the coordinator and setting the original configs, but the coordinator is not reinitializing and the port is getting shutdown after saving the configs.
I restarted the system multiple times to reinitialize the coordinator with the new configs, the logs showed the correct configs at the beginning, but at the end, the Channel and Extended Pan ID are not updated.
I also tried using static thing definition and it reverted back to old configurations.
Attached a log for reference.
I am using cc2538 with Zigbee 3.0 firmware, and It used to run perfectly.
If you are resetting the dongle, and reverting to old configuration, it will not work. You cannot reset the network - once the network has been reset it is effectively destroyed as security will no longer work.
So what does the reset switch do if not changing the configs? Assume I want to use this same dongle to start a new network.
Just to be clear, I am reverting to the configs I used the first time and not the default ones. And only 2 configs are not getting updated now with or without resetting the dongle.
Also, the real question, how did it change in the first place! I know we can’t speculate without data, but that’s strange.
It will change the config - the issue is that it will also reset the security system. In the TI chips there is no alternative. Once the security counters are reset then this is effectively a new network, and all devices will ignore commands from the coordinator.
Fine - my point was that if at ANY point you have reset the dongle, then it is game over. You cannot simply change the PAN ID etc back - it doesn’t work like that.
That’s what I already questioned, but I’m afraid that I don’t know. I already speculated that maybe there is something in OH that can send the incorrect configuration - maybe the UI can also do this - and maybe there’s a bug in the binding. Or maybe some combination of certain factors, but I can just speculate about this - I’ve no way to be sure, and no way that I can change anything unless I have a clue what to change.
So did changing the config without resetting should have been the correct way? I tried it but it didn’t work.
I also still don’t understand, why I can’t change the zigbee_channel anymore?
I’ve read some people did exactly what I’m doing with different TI dongles, that is taking over an existing network by using the same coordinator config.
Do you think that reflashing the dongle firmware will help me take back control of the configs?
Since there are no logs, I can’t be sure what happened. I can’t be sure if the dongle was, or was not reset. I don’t know if it’s the dongle that was reconfigured, or if something else happened. Maybe something changed the config and the first time you turned it on it was reconfigured - I really don’t know.
All I can really do is offer suggestions as to what might have happened.
I can’t really tell what the state of your system is sorry. The channel is not normally changeable by the binding IIRC.
So, unfortunately I can only repeat what I’ve already said earlier. If the dongle was reset at any time, then you cannot restore an existing network - it is simply not possible. It’s very easy to say that “others have done this” but a) I don’t know what has happened with your system, and b) I don’t know what these other people did, so I’m not sure how you are able to conclude (as I think you are?) that it is possible? I don’t think it’s really possible to say that you are doing “exactly” the same thing though as there’s no enough information is there?
You should simply be able to reset the dongle to get the dongle working I think. I’m not super familiar with the TI dongles, but typically reflashing firmware will not change the network configuration. Maybe it’s possible to erase this as well.
Thanks for the detailed answer.
I did a test using a different dongle/system, I set up a network, connected some devices, and waited until everything became online, then I changed the coordinator configs, which caused the network to become offline, and finally, I completely removed the coordinator thing.
I re-added the coordinator with the same original configs and it got connected back to the network.
As I too don’t understand what caused this, and AFAIK the configs should be changeable even after a reset (especially the channel), it seems like there is a bug in the Z-Stack 3.0 that is causing this.
What supports this conclusion as well is a thread post from another user mentioning the same strange behavior with Z-STACK 3.0.
The expanid is getting reset to the dongle mac address and the channel to 11. I double checked with another dongle and the same happened.
If you change the config, then it’s likely to break things. I’m not really sure what you are changing here, but I would generally suggest not to change the configuration since not all configuration can be changed, and even the config that can be changed can cause problems as it may not propagate through the network.
Again - not all configuration can be changed, and configuration that can change may not be a good idea to actually change since it may not get propagated to all devices - depending on how well they implement some of the lesser common parts of the protocol.
If the extended PANID is changing (I guess this is what you refer to?) then this will break the network - it cannot be changed.
Yes it changed from the initial value I set when I first created the coordinator, and that appears to be what broke my network, not the long time of power outage. And as I said before, it seems to be a problem with the firmware Z-Stack 3.0
Does that mean I don’t have to backup a coordinator like a ZWave controller to be prepared in case the hardware breaks ? Just keep the network key ? (which is in the openhab config so backed up anyway)
You do - but it doesn’t save information about other devices - just the controller. The information that gets saved is mostly around security since if the keys are lost, there’s no going back.
No - it’s not just the key that you see in the UI - there are some counters that are also saved as these are also needed to be restored.
Currently only the Ember chips allow this information to be read out. There is a command to do the backup and restore in the UI.
Thanks. The reason to ask ultimately is that I have an Elelabs controller in a remote location that doesn’t answer (see below) and the Elelabs python tools are hanging on readout, too (OH down of course)) but I was hesitating to reset it so far. Meanwhile I did but that didn’t help either.
Really? Haven’t seen that. Where exactly in which UI please ? As I said it’s an Elelabs controller, it has an Ember chip.
2021-03-24 22:42:14.433 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Connecting to serial port [/dev/ttyAMA0] at 57600 baud, flow control FLOWCONTROL_OUT_XONOFF.
2021-03-24 22:42:14.460 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Serial port [/dev/ttyAMA0] is initialized.
2021-03-24 22:42:24.470 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - No response from ezspVersion command
2021-03-24 22:42:24.472 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP Dongle: Version returned null. ASH/EZSP not initialised.
2021-03-24 22:42:24.477 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Network state is updated to OFFLINE
2021-03-24 22:42:24.480 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - null: networkStateUpdated called with state=OFFLINE
You can generally reset the controller - it’s what the binding does every time it starts and it won’t hard anything unless you initialise the network. This will reset everything, and even if you use the same network key, it won’t work.
It’s not in the UI - it’s a console command. I think it’s something like smarthome:zigbee backup. This creates a short output, and you can use the same command with the output pasted back to restore the network.
Found it, openhab:zigbee netbackup it is. Thanks!