Zigbee CC2531 works for some minutes and then remains "uninitialized"

Tags: #<Tag:0x00007f4333e4aef8> #<Tag:0x00007f4333e4ae30> #<Tag:0x00007f4333e4ad68>

Hi there,

I am running OH 2.5.3 within a Docker Container on my Synology DS1815+ NAS. The system was working fine (incl. ZigBee Binding and the CC2531 Stick) for maybe a half a year.

“Suddenly” I had a problem. When rebooting the Synology (and an automatic restart of the OpenHAB Container) the CC2531 works fine for maybe 2-3 minutes (I can control all my ZigBee Items, etc.). Then the status starts flickering in between “offline”, “communication error”, “online” (and even working for some seconds again!) and a little later falls into “uninitialized”.
Restarting the OpenHAB Docker Container doesn’t solve the problem. Only restarting the NAS (and after some minutes the story repeats).

So my first idea was a defect CC2531 USB Stick. I’ve replaced it by a new one. Added some ZigBee items to the new one, but finally the behavior was the same.

The CC2531 is still visible within the Docker Container on BASH as /dev/ttyACM0; all access rights are fine as it seems, like e.g. doing that within BASH:

ls -l /dev/ttyACM0

results in

crwxrwxrwx 1 root dialout 166, 0 Mar 10 04:30 /dev/ttyACM0

Just for a try I’ve bought an “active USB extension cable” (with a chipset and the option to add an external 5V Power Supply), added the external power supply, just to ensure it has nothing to do with e.g. less power. This also wasn’t solving the issue.

That’s what I see within the logs of OpenHAB:

08:00:25.474 [ERROR] [org.openhab.binding.zigbee.console ] - bundle org.openhab.binding.zigbee.conso
le:2.5.12 (253)[org.openhab.binding.zigbee.console.internal.GeneralZigBeeConsoleCommandProvider(3540)] : Error during instantiation of the implementatio
n object
java.lang.NoClassDefFoundError: com/zsmartsystems/zigbee/console/ZigBeeConsoleDeviceFingerprintCommand
at org.openhab.binding.zigbee.console.internal.GeneralZigBeeConsoleCommandProvider.(GeneralZigBeeConsoleCommandProvider.java:67) ~[?:?]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_232]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_232]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_232]
at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_232]
at org.apache.felix.scr.impl.inject.ComponentConstructor.newInstance(ComponentConstructor.java:309) ~[bundleFile:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:277) [bundleFile:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:114) [bundleFile:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:982) [bundleFile:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:955) [bundleFile:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:900) [bundleFile:?]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212) [org.eclipse.osgi-3.12.100.jar:?]
at java.security.AccessController.doPrivileged(Native Method) [?:1.8.0_232]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210) [org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111) [org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45) [org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508) [org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [org.eclipse.osgi-3.12.100.jar:?]

Does anybody have an idea, what I should do next?

I guess it might something about that message:

Error during instantiation of the implementation object
java.lang.NoClassDefFoundError: com/zsmartsystems/zigbee/console/ZigBeeConsoleDeviceFingerprintCommand
at org.openhab.binding.zigbee.console.internal.GeneralZigBeeConsoleCommandProvider.(GeneralZigBeeConsoleCommandProvider.java:67) ~[?:?]

BR, Stefan

Maybe this might be another starting point for a good idea to solve it:

You have upgraded the zigbee binding to a new version (2.5.12) but the dependencies are not compatible as they are still very old (1.3.2). You need to upgrade everything together, or don’t update anything.

Hi Chris,

thanks for your help. I assume that happend, when starting an OH3 Container by incident with the Folder Mapping to OH2.5.3 some days ago.
My intention was to prepare the upgrade to OH3 and I’ve started the container, stopped it after “a few seconds” while getting aware of the fact that I should do it within it’s own folders…
So maybe there was some kind of upgrade started… not so nice, but finally my fault (a typical PICNIC story…).

Might it be a hard job to explain to me, what I have to do in order to fix it (e.g. by updating the dependencies)?

BR, Stefan

There is a script that might help.

Thanks a lot.
I did it, but I am a little confused about the result, showing that:

The line with “Waiting” is confusing me.

But besides that confusion:
It is running much more stable and longer as before. Means, since the restart the CC2531 is “online” and remains online. It is sometimes flickering into “uninitialized” to “unknown” for maybe 1 second and then it comes back as “online” again.

UPDATE:
After 19 minutes online time of the Cotainer it is again “uninitialized” and remains in that stage

You still have the same problem - you are running an old version of the dependencies (the zigbee libraries, which are 1.3.2) and a new version of the binding. The line that is “waiting” is probably upset as it is looking for classes that don’t exist in the old version of the libraries you are running. The others are probably resolving, but 1.3.2 is 12 months old and I don’t remember what has changed (a lot though).

This may or may not be the cause of your problem, but without more information it’s really not possible to comment further. I’d strongly recommend looking at the logs to find out what is wrong.

OK. Thanks, Chris.

I did it now again in single steps. Means: using the mentioned script to uninstall the binding.
After seeing the success, restarting OH container just to be sure.

Running then the script again to install it.
Again restart of OH container.

Now the result is different, which is promissing:

At the moment it is “online”. We will see what happens.

First of all: thanks for that great support!

Update after 10 minutes online:
Status starts “flickering”, finally same story again… “uninitialized”…

If you don’t have another idea for a quick fix, I maybe just should proceed my fresh and clean install of OH3 and maybe this will solve the problem.

It’s hard to know what is happening here as you now have 3 versions running.

Ok, my only other suggestion above was to use the debug logs, but if you don’t want to go down that route then a fresh install might help - or it might not - it depends on what is causing the problem and this is what the logs would help you with.

Logs are not my friends at OH, that’s why I was giving it a try the other way around.
The only reason for that is, not being familiar with those besides some “log:tail” quick analysis (mostly leading me to typos) in the past. So maybe I am too lazy…

I’ve also seen, that there are several versions, but I thought that was due to the script. Just giving me some time to think about it, I also understand, that this shouldn’t be the result, of course.

I did again the uninstall part of the script, because if I got you correct, I should first of all get rid of the former installation(s).
It was prompting success. Then I did a first check:

Hm… still something left. But ok, let’s restart the container and do it again:

The lines are back like zombies…

Ok, did I miss somehting? reading the md-file again, I do not see, what I’ve not done so far.

Stupid question: I never removed the ZigBee binding or related Things within PaperUI. Should this be done e.g. before using the sh-script to uninstall it?

Current state, after having the container running for
…15 minutes is “online”,
…20 minutes is “online”,
…23 minutes is “uninitialized”

What part of the logs would you need for a first guess?
Maybe this should be the point stopping me being lazy on OH logs.

The part that shows the problem. If it takes 23 minutes, then you should record 23 minutes to see what is happening.

You can also view the logs here -:

I will try and look if you post it, but am very busy moving home right now so am ducking in and out quite a bit.

Great - thanks!
That will be helpful in the future.

Besides that:
I did the migration to OH3 that evening. It was on my to-do list anyway…
Therein the CC2531 works like a charm again and I’ve moved in the meantime maybe 100 items, a couple of rules, etc. with success.
The other stuff will follow and is less relevant for daily life.

@chris: Hope moving your home works fine - I’ll keep fingers crossed.

1 Like