It is very frustrating to have a need to USE one’s Openhab only to discover it is no longer functional because a faulty update was designed so that applying the update breaks the system. I’m getting the “UNINITIALIZED - HANDLER_CONFIGURATION_PENDING” on everything, and now I have a research project to figure out how to fix it. Thanks, just effing great work.
If an update is KNOWN to destroy functioning systems, the update should never have gotten out. The tools to make an update work should be included as part of the update, otherwise you are no better than Microsoft, and your update is arguably malware.
I mean this criticism in the best most positive and constructive manner possible, but I still mean for it to be harsh criticism. Its well deserved. I mean, who would think its OK to push out something that you know is gonna break everything?
Now, I get to spend a few HOURS this week figuring out what the update did to crater my system and how to undo it. Really, really appreciated, developers.
I followed your guidance to clear up my Z-Wave network and did a hard reset. Now, I have a proper network again. Thanks for the hint!
Still, the root cause of the trouble is unresolved (thread with logs):
Would you have a solution approach for me? Some others have the same issue for thermostats, but in the respective discussions, there is no solution presented. @chris was involved in the discussions - maybe there is some solution I did not see?
mhilbush the fact that people volunteer lots of time to work on the software does not excuse the fact that you put KNOWINGLY out an update that destroyed my functioning system. I believe that’s inexcusable, and if you think that’s acceptable approach to managing an open source app, then you need to look in the mirror for the problem and I need to find a replacement for openhab.
I respect the effort. I have no respect at all for cutting corners and pushing out something with a sick excuse of well, they will figure it out. Keep the darned update until it can go out with the necessary mechanisms to ensure with some reasonably high probability that OPERATING FUNCTIONAL systems that people depend on the tool will continue to work.
Your update is, from my perspective, destructive malware because you (and all those wonderful volunteers) didnt finish the job and pushed it out too soon.
I have about reached the end of my rope with openhab.
My openhab implementation is over 100 miles away from me. And its busted now and does not work. And cannot be fixed (because of the obtuse design of openhab, read my other rants) so I cannot fix it until I can get there to work on it.
Great, its free, love the work of the volunteers, but MAYBE the job should be completed before pushing it out next time.
Just to be sure: What’s the meaning of the WakeUp-Interval? I set it to 300sec. I thought the device will store the set value when it arrives and if the WakeUp occurs, the set value will be “executed”, i.e. applied.
Am I wrong?
Any command you send to the device is queued, then sent to the device when it wakes up. Note that the queue is volatile, meaning that if you restart openHAB or the zwave binding, whatever was in the queue is lost.
In my case, the transmission is fine (from what I read from the logs) but still the values are not accepted. Only when I manually wake up the device and send a new set value in that moment, the value is accepted.
Otherwise, the next report from the device resets the item I use for set point values back to the old value stored in the device.
you are right, thanks for the hint. Indeed, this was an item I created while I had troubles with the Z-Wave Network itself. Clearly, it can’t work - and it is also assigned to a node 7 which does not exist in the current setup (with a new Z-Wave network from scratch).
I will correct this tonight. I am not too optimistic as I tested also in PaperUI control and the items used there are automatically created - but still, this needs to be corrected to work in BasicUI and elsewhere. I will report if this does the trick
Should I reduce the updateInterval from 300 to a lower value? Maybe this is why the set point value is not correctly transferred?