This topic can be used to discuss problems/experiences/questions on the openHAB 2.5.9 release - see details at https://github.com/openhab/openhab-distro/releases/tag/2.5.9.
This is a little bit off topic @Kai, but I saw that a PR I’ve been working on was migrated to 3.0. Do I continue to work on that PR it in the 2.5.x branch (I have quite a few uncommitted changes), or do I need to start working on it in the master branch? If the plan is already in a post somewhere, can you please point me to it?
@Kai @maintainers I have to say thank you for a great job. You put in a lot of effort reviewing all the PRs. I never saw a number < 100 open PRs and you brought it down to < 80. It’s fun working with you guys. Thx
On your announcement post you have a
: on the end of the Release Notes URL.
Thanks, took the liberty of fixing it (there were already quite a few clicks to the invalid url).
Yeah, that’s off-topic here, but let me nonetheless quickly answer it: Ftr, you are referring to this - I actually used you (no, your PR) as a guinea pig here. I have prepared a Jenkins job that’ll make it hopefully easy for people to port their contributions to openHAB 3. I’ll very soon provide more details on what how to proceed with PRs and contributions!
Thanks. Can I go ahead and commit my changes to 2.5.x? Or should I just wait for the details?
-> Discussion for all contributors on how to proceed with PRs in future goes to https://github.com/openhab/openhab-addons/issues/8512.
One small issue:
There is a typo in the link to documentation of venstarthermostat:
When you click on the bindings name in PaperUI it normally leads to the documentation:
In link there is a “s” missing in the word venstar
https://www.openhab.org/addons/bindings/ventarthermostat/ and it leads to 404.
please change it to:
Hmm that is no typo in the link, but a bug in the feature name of the binding and requires a fix in the binding feature.xml. The documentation is only derived from that information.
OK. You are right. There is the “s” missing.
Rest seems to be OK.
openhab> bundle:list -l |grep venstar 210 x Active x 80 x 2.5.9 x mvn:org.openhab.addons.bundles/org.openhab.binding.venstarthermostat/[2.5.0,2.6)
I’ve just upgraded from 2.5.5 via apt. openHAB runs as a service on my Pi. During the upgrade, I see this:
Setting up openhab2 (2.5.9-1) ... [openHAB] Listing important changes for version 2.5.9: Warning: Velbus Binding: The channel names of the following modules have been renamed from "CHx" to "input:CHx": VMB2PN, VMB6IN, VMB6PN, VMB7IN, VMB8IR, VMB8PB, VMB8PBU, VMBGP1, VMBGP2, VMBGP4, VMBGP4PIR, VMBGPO, VMBGPOD, VMBPIRC, VMBPIRM and VMBPIRO. [openHAB] openHAB was not running so will not start after upgrade. [openHAB] Please use the command: sudo /bin/systemctl start openhab2.service
But openHAB was running prior to starting
sudo apt upgrade, so not sure why the install thinks openHAB wasn’t running?
Not a big deal, it’s easy to start, just thought it was strange.
Because apt upgrade stops openhab before upgrading, then does the update and then should start openhab back up
I have seen the list of changes for addons. Where can I see the list of changes for openHAB itself and HABPanel?
There are no changes to either openHAB core or HABPanel in this release.
Looks like docker isn’t working correctly - when I boot up the new image the docker upgrade script says ‘You are already on openHAB 2.5.8’ and does nothing after completing the backups. Then it seems the container eventually shutsdown/crashes and restarts a minute later and continues this loop.
Am I the only one who dreads upgrading? I love OpenHAB and after I get it stable it JUST WORKS, but every upgrade or reboot takes several tries to get everything loaded again.
Seems like there’s no guarantee what order things get loaded in, and it never fails that something ends up broken until a couple of reboots.
Is there a key to getting upgrades/reboot to go smoothly?
Almost everything I have is Z-Wave/MQTT based, and the things come up fine, but some items and groups are randomly not there when it boots.
This is not a complaint (unless it’s a complaint about my OpenHAB skills), just looking for guidance to make this less painful.
This is true. However I think if you wait enough at first startup (after upgrade) and not restart openhab at the first error, you just need to restart openhab once and everything is back to normal.
This is a known problem that hits some people. It only occurs when the cache get’s cleared which happens automatically on an update.
Hopefully this won’t be a problem in OH 3. I know there has been some work on changing how stuff starts up in OH 3.
As Kristof indicates, after an upgrade wait long enough for everything that is going to load finishes loading. Than usually a single reboot is sufficient.
I handle all my updates using Ansible and run in Docker. When a new Docker image is pulled my task will wait for five minutes and then restart the container. Haven’t had a problem since and pretty much only have about 6 minutes of down time.
I need to update the role to only do the wait and restart when the actual version of OH changes. The Docker Image changes far more frequently so most of the restarts of OH are unnecessary.
I run a full update of all of my machines and docker containers every few days and very rarely encounter a serious problem that takes much time to solve. It’s when I wait for months before updating that I have that feeling of dread because if something goes wrong it’s going to be a lot of work to find out why and fix it.