I had been running openHAB2 on a raspberry pi3 for a few months gradually adding z-wave device. I decided to run the “Upgrade System” and “openHAB Stable” from the “openhabian-config”. After the upgrade all my z-wave devices, except the z-wave controller (Aeotech Z-Stick gen 5), now show a status of “UNINITIALIZED - HANDLER_CONFIGURATION_PENDING” and I cannot control them at all from openHAB. Any suggestions how to get them back working.
Yes, there was a warning when upgrading which you probably did not read.
Perform the steps mentioned in the first post and you should be good to go again:
2 Likes
I had seen the post about the zwave binding. Just didn’t realize doing the “upgrade system” and “openHAB Stable” from the configuration tool upgraded you to the development version.
It doesn’t - it upgrades you to the release version.
1 Like
Sorry, maybe the link to that older post was misleading. The action to be taken are the same, though.
1 Like
At the time of that posting, it referred to the development version. But the changes eventually migrated from the development version to the milestones and now, as of this Monday, to the Release version. When you upgraded your openHAB Stable you upgraded from OH 2.3 to OH 2.4. That posting applies to every version of OH released after the date of that post.
FWIW, this is really not the best way to make a good impression on non-expert users of OH. I am running OH on a RasPI. I just did an apt-get upgrade which I do regularly for security reasons, and it bombed my entire OH home installation. This has resulted in an extremely low SAF, and an unscheduled loss of time tomorrow while I delete all Things from my system and start over. I can do that, but it SURE would have been handy to have a screen pop up during the upgrade with some sort of warning and the option to bail out of the upgrade so that I could do it sometime when I have free time available. Imagine what impact this has on someone who is an enthusiast but is not really a computer expert. We really need to watch out for how this affects our user base.
1 Like
This should be standard operating procedure when upgrading ANY mission critical software. If you cannot afford the down time do not upgrade, even for security updates.
There is no way to create a pop-up like you describe when using apt. Apt doesn’t allow it.
1 Like
sudo apt-mark hold openhab2
sudo apt-mark unhold openhab2
http://manpages.ubuntu.com/manpages/xenial/man8/apt-mark.8.html
We did have this so I’m not sure why it didn’t happen. Maybe it was only added to the milestones - I’ll enquire as it was certainly the plan, and it was certainly implemented a few months back.
Thanks @chris I have seen all sorts of pop-ups during APT installs including various notices about the specific package upgrade, requests to enter passwords, etc.
@rlkoshak, yes, of course - don’t mess with a critical system unless you have a day available to troubleshoot the upgrade. But…
The world of security is driving a change in the way people think about upgrades of critical systems. DevOps and NoOps are driving continuous release - See www.kali.org for an entire Linux distribution that is on a rolling, continuous release schedule.
Given that some of the largest botnet attacks have been fueled by small IoT devices, it might be a good idea for our community to seriously consider how we can allow continuous upgrades as well.
Just a suggestion.
We do, but continuous doesn’t mean without work. If you can’t afford the time to back out a change or an upgrade gone wrong, don’t do the upgrade. DevOps and NoOps environments are set up to let you quickly roll back but you have to be running a whole bunch of infrastructure to enable that. VMs, Kubernetes, Containers, etc. Are you running all of these too? That is why developers and integrators can rapidly try stuff out and back out or pivot when necessary. It is wholly unreasonable to expect a home user to have this sort of infrastructure in place. And without that infrastructure you can’t do DevOps at home. So we are back to don’t do the update unless you have time to fix what broke or roll back to the previous version until you do have time.
And personally I DO run OH in a VM in a container (I don’t have enough variability to justify using something like Kubernetes or OpenShift). But I’m in the extreme minority but I can help you or others if you want to go down that path.
OH is working towards being more nimble with upgrades and updates. Not too long ago we got support for back porting important bug fixes (security related ones would be important) to the previous releases and we now have milestone builds. I do think the project is slowly moving in the direction of more continuous releases. And in fact we do have continuous releases in the nightly snapshots.
I asked about this from @Benjy and he indicated that apt wouldn’t allow it. Did I misunderstand or are you talking about some other way to generate the pop-up? It would be pretty cool if we had something like that to list all the breaking changes.
In one of the 2.4 milestones we had such a warning - the milestone after the Zwave change. So, it does seem to be possible. It’s not a popup as such, but then apt is not a GUI - it lists these changes, and I think the user has to press the Y button to accept them.
Unfortunately, we didn’t it seems flow these changes through to the 2.4 release. In future we need to try and ensure that the final release versions get this sort of information and not just have it in the milestones…
The alert that we had was the following -:
ALERT;ZWave Binding: Major changes have been merged to support features such as security. All things must be deleted and re-added. Refer to https://community.openhab.org/t/zwave-binding-updates/51080 for further information.
Apt will still display the list of breaking changes, but after the installation has taken place, the message for ZWave should have been there:
I will be looking for a way of notifying the user before the upgrade, but I’m not able to work on things for a bit at the moment.
1 Like
I was ignoring the warning and have removed all things to get them back on-boarded again… Thanks for the advice to get it back working! 
But the error message “503 Jersey not ready…” is something I hadn’t before the upgrade… Any advice how to fix this?
I was already deleting the cache and the temp folders but no change…
Many thanks!
BR
Uwe
One quick note to, perhaps, close off this discussion. I have found that doing a backup, then running the upgrade (apt upgrade), and then doing a restore, gets rid of the Uninitialized Handler Configuration Pending message, while restoring the system to operation without having to reconfigure all Things and Items, or worse yet, having to reinstall OH and start configuring from scratch.