Zigbee network offline after powering OFF coordinator for 2 weeks

I have a relatively large Zigbee network with ~30 devices mixed between routers and end devices, and I had this network working fine for some time. The coordinator was shut down for 2 weeks before I turn it back ON, and now all the network appears as offline.

I wonder is this something built into the Zigbee protocol? or is it something related to openHAB Zigbee binding? Has anyone experienced this before?

You unplugged the coordinator for 2 weeks & then plugged it back in?

I had similar experience when one of IKEA bulbs was switched off for some time. It was simply forgotten by coordinator. Maybe here is the same case. The coordinator has forgotten all items.
Check how the DB file looks like. Maybe you need to connect them once again.
It shouldn’t has negative impact as all entries in configuration.yaml are kept.

One of my test configurations here has 32 bulbs. It is no problem to turn them off for any period of time - they are not forgotten ;). I’m not sure if it’s been turned off for 2 weeks, but this should not matter - it’s certainly been powered off for 1 week, and there is no problem with this at all.

If you turn off the coordinator though, it will take time for the system to re-establish the mesh. The system will be slow while this takes place.

You don’t say what version of the binding you’re using - I would strongly recommend the latest binding.

The coordinator doesn’t forget devices - there is in fact nothing for the coordinator to forget. The coordinator doesn’t even know what devices are included in the network, so it can’t forget :slight_smile: So long as the network key does not change, a device can participate in the network. Of course if it’s off for a while, it needs to re-route everything in the mesh, and this can take some time.

I’m not sure what this yaml file is? The binding stores all data in a set of XML files - if you delete these files then the device will be lost. It’s possible for it to be rediscovered if it’s active in the network again, but you will normally need to turn it on/off/on so that it sends out an announcement so it can be rediscovered. Deleting these files for battery devices can make them difficult to rediscover - this depends on the device, but if the device sleeps a lot, then it will likely not be discoverable without further manual intervention to wake it up.

I’m talking about zigbee2mqtt where file configuration.yaml is used. And also here is a DB file where all connected items are listed. So when I said that “controller has forgotten my bulb” I meant entry for this particular item disappeared from this file.

If my info was not released to the question - sorry :wink: I tried to help :slight_smile:

1 Like

I am on 2.5.8

They’ve been offline for over a day now, I will look into the log to further investigate this.

So why did you tag the thread for the Zigbee binding then? zigbee2mqtt has a different developer.

Sorry guys, I’m confused now.

I thought the original question by @abol3z was about the zigbee binding. I see the tags have now changed to indicate that this is about zigbee2mqtt binding, but I think that is only because @smarthomepch responded about zigbee2mqtt. :confounded:

@abol3z please can you confirm what binding we’re talking about? You do say the “openHAB Zigbee binding” - so I’m assuming that @Bruce_Osborne set the tags incorrectly?

I didn’t tag anything. Just replied :frowning:

I did. Since @smarthomepchansewered your question to @abol3z I assumed they were the original poster.

It is openHAB Zigbee binding, and I tagged the question with zigbee tag only!
I will fix this now

1 Like

I have been thinking about something like this:
I have some houses in the mountain that I want to be solar powered.
In december/january the system will have to be powered down, because there is no sun here in Norway.
At the same time I do not want to remove batteries from sensors…
So, wil the sensors find the network and continue to work after two months?

In theory, it should be ok, but to be honest I would suggest to remove the batteries as they may be dead by then anyway.

What will happen is that the battery sensor can only communicate with its parent. When it finds the parent is gone, it will start searching for a new parent. This will perform scans on all available channels also in case the coordinator moved to a different channel. In theory it will do this forever, so when you power things back up in a few months, it should then find a parent again, and continue working.

However… Two issues I can see. You could find that implementations decide that after some period of not finding a parent that they perform a reset to get out of any “strange state” that they might be in given they aren’t receiving anything. Additionally, you might find that after 2 months of scanning for a parent, the device will have used a lot of battery and could be dead. This is especially likely if the temperature is low - as I could imagine it might be…


I’ve upgraded to 2.5.9-SNAPSHOT and zsmartsystems to 1.3.8 and after one day all devices are still OFFLINE.
I’ve attached a log. I used the online log viewer and I found that most of the transactions are TX only, which seems strange. I tried to permit join, nothing happened.

If devices are not responding to the binding, then this is what you would expect.

So, back to my question.
From your experience, is it a Zigbee protocol behavior or something that the binding is not handling correctly?

That’s a lot of work to rejoin all devices, and I am afraid that it might happen again in future.

I have no idea really - there’s next to nothing here for me to be able to say what has happened.

The ZigBee protocol will handle this fine. The binding should also handle this fine. Maybe somewhere along the line you’ve managed to reset the stick, or something else has happened that has changed network keys or something that makes the network unusable. Without seeing logs from the past that shows what happened, it’s unfortunately pretty much impossible for me to say what the problem is.

All I can saw now is the from your log, it appears no devices are responding on the network. If you have a network sniffer, it might help see what’s happening, but if the network was reset, or some other reconfiguration took place, it’s not going to show up.

1 Like

Thanks, will try to debug this further to see what is wrong, otherwise I’ll have to rejoin everything.

If you keep debug logs, then we can possibly try and work out what happened, but otherwise it’s problematic to know what occurred in the past.

If I had to guess, I’d say that this is a binding issue - or something with the way that OH sends updates to the binding - maybe the UI somewhere sent a configuration with a changed network key, or a reset network command. Unfortunately I can only speculate though - if we can work out what happened, then we can improve it, but otherwise I’m afraid there’s little really to go on - sorry.


I would love to provide anything that might be helpful. Unfortunately, the log I sent is all I have. The binding generates too much when in debug level and it erased older logs.

I am sure that there was no human interaction with the system as it was completely OFF during the 2 weeks (power outage)

I’ve checked the coordinator to see if something erased the network data, and it seems like it did change. The coordinator configs are different than what I initially set!
I’ve checked the backups and they all have the new data!

Any idea how to trace this back? Is it recoverable without resetting the coordinator if I set the initial data again? I extracted the old Pann ID, Extended Pan ID, and Channel, but I can’t find out the Network Security Key