Any updates on migrating to a newer version of Openhab?

Any updates on migrating to a newer version of Openhab? Just curious, 2.5 is working fine, I remember there being talk of it some time ago but haven’t seen anything recently!

You are right… there hasn’t been much effort towards this… migrating to a newer OS was higher in our priority list and @hestia_hacker’s recent amazing work for Debian 9 (Stretch) left us a bit worried about how much more juice can we pull out of Pi Zero as it is not as responsive with Stretch as it is now with (ancient) Jessie.
Maybe newer OpenHAB will be heavier, maybe not. This is not something we have explored yet. Any help would be welcome

Oh true, I’ve only ever ran mine on a raspberry pi 3 so I forget that it was originally intended to run on the zero. If I could be any help with it I certainly would. I am not even remotely close to knowledgeable to help with that, I know just enough to get stuff working around my house with Openhab, I wouldn’t be any use with the under the hood stuff, at least not yet anyway.

I’ve been away for a while, but I’m back now and once again working on getting updates to the HestiaPi images. The roadmap is roughly this:

  1. Get things working acceptable well on Stretch (perhaps setting the CPU speed issues aside)
  2. Attempt to repeat this process on Debian 11 (Buster)
  3. Attempt to switch the Buster image from build-from-source to using the versions of software from the official repos (Debian or the vendor, whatever works)
  4. Attempt to switch from OpenHAB 2 to 3

I’m currently not targeting Debian 11 (Bullseye) because it seems to be way less stable for my automated builds (mainly with the network just dropping connections or the qemu process mysteriously disappearing). I’m not sure if this is an issue with the CI environment, qemu’s emulation, or something else, but I don’t want debugging that to hold up progress on HestiaPi work. So that’s why I’m currently targeting Buster instead of Bullseye.

1 Like

One thing to keep in mind looking long term is both that Buster is already end of life and OH 4 (work has already started) requires Java 17 which, based on some preliminary reports, doesn’t support Buster very well.

As for the weight, OH 3.0 was roughly the same as OH 2.5. OH 4 has just started but the work being done and proposed shouldn’t change the load significantly.

1 Like

Buster is the current LTS and will be supported until June 30th, 2024.

OH 3 requires Java 11, which will not run on the CPU in a Pi Zero. The is because all the implementations of the JVM require hardware floating point unit (FPU).

I believe the 64-bit RaspiOS does start with buster, but that image doesn’t boot in qemu.

The 64-bit RaspiOS buster image does work in qemu, but the libwebkit 3 package is gone and so we can’t build kweb on there. This means the LCD display won’t work on Bullseye until we find a replacement browser.

In summary, upgrading to OH3 means:

  1. Switching hardware (e.g. Rsapberry Pi Zero 2 W)
  2. Likely switching browsers (e.g. Midori)
  3. Likely upgrading to Bullseye

I am going to take a break after we are able to ship the Buster dev image, but when I come back I can do some tests on hardware to see if I can get the current stack (Buster/kweb/OH2) working in 64-bit mode on a Zero 2.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.