I had a 3.3 snapshot installed as I needed an update in the Kasa/TP-Link binding
Due to the RHSB-2022-001 Polkit Privilege Escalation - (CVE-2021-4034) vulnerability, I updated my Ubuntu server. Since my apt install was setup for snapshots, my OH instance got upgraded too.
Sorry - not really. There should be no problem upgrading the binding and there haven’t been any changes (other than database). Have you checked the logs to find out what is happening? Really without more information it’s impossible to help - sorry.
Due to the update there might be a mix of installed and cached information. Hence in a case like that my first attempt would be to clear the cache after stopping OH:
Had exactly the same issue after upgrading to snapshot #2722 - nothing helped, rebooted several times but always same situation.
Most of Z-wave devices showed ERROR:HANDLER and only a minority was green. Could not find out if there was something systematic.
My solution for now was to downgrade to the snapshot before, then everything worked again.
I guess this is just luck, and probably not related to the ZWave binding since there have not been any changes to any code.
I didn’t see anything wrong in the logs - they seemed to start quite a bit after the controller starts, but I’m not sure if having full logs will help a lot. The ZWave side seems to be working fine and I can’t see why OH isn’t creating the handlers.
Had today the same Error Message with missing configuration. So i checked the config and found some strange value -1 instead of 255 and this was flagged as error.
On an other device i only had to click on reinitialize and it is up an running again
I had a bit of a challenge adding my Things. Some took several tries.
Now I know that nodes are stored on the stick. I have weirdness going on
I have tried deleting these from my inbox but they keep coming backed
Hmmm. Ok, I think that OH Core has made some changes to check some configuration, and maybe this is causing the issue and preventing the handlers starting.
@J-N-K I think I saw you created a PR to do some configuration checks? I didn’t follow it closely, but just saw the emails… Do you think this could be causing the issue?
@chris Yes, I assume that could be the reason. The Che l is now more strict than before (in fact, it didn’t exist before, only for entering the values on the UI, not during initialization).
I foolishly did not try controlling the devices before doing configuration and save.
Possibly device is online but new code is preventing status being updated as parameters are failing validation?
Or device needs a save to make configuration correct so it initialised.
When I test by disabling the controller and enable it again the same devices showing error:handler and can not be controlled. Going to the thing config and saving fixes and devices behave as they should.
Based on all the discussion by the OH heavy weights I think you may have more than one problem. As to my Node 3 comment, it was late last night and I didn’t elaborate. The problem (seen with the log viewer) was that several messages to Node 3 were timing out. It does look to be a levitron ZW4SF_01_008 (fan controller). As to nodes 17-19, they are clearly duplicates and in the debug log only node 19 seems to be active. It is some kind of battery device because I see “wakes”.
A rebuild may not be a bad idea. Hopefully that would clear up the other issue with the configuration PR.
The other thought is to use the Silabs PC controller and clear out extraneous devices and then go to the devices you know you have and check the configurations ala @robmac post.