Openhab4 M1 - earlybird?

Hi, sorry if this was discussed already - but a quick search did not find any OH4 discussion ongoing.

I recently did not touch my OH installation too much, except config changes. By accident (apt-get update) i updated today to OH4 from OH3.4.2 and realized in a second that there is an issue. By the help of the community i now have Java17 on the radar. Reading some M1 discussion i scanned some issues/changes regarding rules that require some action, but not sure if this is ment for me as i do rules completely in txt configs.

So, after long writing - is M1 already a good point to start if i would like to have a mostly stable version that will not force me to go back after short time? Coming from 3.4.2 is there any big changes that will take some of my nights to migrate?

Many Thanks for enlighting. i guess there will be many others with similar questions soon…

@sihui thanks for the link. that was the doc i read before and was not sure if there is any implication for me.

As written above, i’m not using this block-rules-style tool and only have rules based on txt-files. so will i have to install and use this nashorn-addon, i guess no - which means except Java17 i should be fine. JS scripts i also do not remember to have ever used over the years.

In my opinion, no. If you need stability, stick with the most recent stable version. You should only use a milestone if you’re interested in testing and reporting bugs, as the goal is to get feedback from users. Some folks would say that it’s fine by the time of M2 or M3, but I think the only reason to use a milestone in a production environment is if you need a specific feature/fix.

This isn’t to say that a milestone will definitely give you problems. It might work perfectly well. However, if you run into trouble on a milestone it’ll be more difficult to debug your system due to the added uncertainty.

Personally, I stick with stable versons and usually wait until a few weeks after a release to update. Unless there’s a major security patch, I’ll leave it to the many early adopters we have around here to work out the early bugs.


Absolutely not. M1 is not stable yet, still has lots of small issues. Only use it if you are able and willing to keep up with updates, fix and make changes as needed.

For stability stick with 3.4.x.

The only exception is if you need a new feature badly enough. Even then, wait for M3 probably

In what language?

I can only agree with what’s been stated here so far. The milestones are for testers and those willing to help find and report problems. This is always the case. Milestones within a major version (e.g. 3.3 to 3.4 M1) are usually pretty solid because breaking changes are kept to a minimum. But between major release versions even the milestones can be pretty heavy with lots of breaking changes.

After all is said and done, the likelihood that you won’t have to make changes to your system to upgrade to 4.0 is going to be low. For now, if you are using JavaScript for anything (including transformations and Blockly) you will need to make changes. Java 17 is required which might require an update of the OS. Any add-ons that are not official (e.g. those on the marketplace and those downloaded from elsewhere like GitHub) will likely need to be recompiled to work with 3.4 and 4.0. There may be changes in specific bindings to account for.

As of this writing there are a number of known regressions and bugs, though most of them do not prevent OH from coming up and operating. 4.0.0 M1 is fully functional and works pretty well, but not ready for those who are not wanting to help test.

Thanks for your reply.

I totally understand. i guess its fine to test but not to complain in the end that the system itself is not behaving 100% like it should and also not to expect the community to fix all issues that arise by sending a few threat messages.

My most generic question…does Java17 force to have a 64bit OS or its fine and works with Bullseye 32bit on Raspi4 ?

Language i’m not sure, but the old old style…like:

rule "Speedtest init"
    System started

That’s DSL rules, so not affected.

No, if you have a 32bit OS with a 32bit Java 17 version, that’s fine.

I´ve got another one. I´m still with 2.5. Does it make sense to wait a few weeks to transfer to 4.x or is it better to transer initially to 3.4. and then to 4.x as I wouldn´t understand nothing any more going straight to 4.x?

4.x is months away, not weeks away.

I strongly recommend moving off of 2.5, because there’s a security vulnerability that was patched two years ago in OH3. So to answer your question directly, you should move up to 3.4 now. I’d probably suggest that even without the security issue, because you’ll benefit from past discussions about moving from OH2 to OH3 (particularly breaking changes).

You can try doing an in-place upgrade (after cloning your system to ensure a fallback path), but I’m of the opinion that it’s best to start with a completely fresh OH3 and build it to match what you’re doing with your OH2 system. This enables you to see how things have changed and take advantage of OH3’s capabilities, as opposed to just importing your OH2 config files and making them work. It will also prepare you more for OH4; you’ll be able to do an upgrade and focus on OH4’s breaking changes.

It’s going to be a huge jump either way.

It probably wouldn’t be too bad to start the transition to the OH 4 milestones, and gradually move your system over little by little. But keep in mind that there are lots of changes and there will be regressions as you go that you’ll have to keep up with.

You’ll probably want to review all the announcements for 3.0, 3.1, 3.2, 3.3, and 4.0 M1 for any additional breaking changes which might impact you.

Right OH, OH 4 is no where near as different from 3.0 as 2.5 was from 3.0 nor as different as 2.0 was from 1.8 so the docs are still pretty accurate.

If you decide to initially upgrade to 3.4.2, pay attention to the OS and Java requirements. You don’t want to upgrade to OH 3.4.2 only to have to install a new OS because Java 17 isn’t available on it.

Do not skip the Getting Started Tutorial no matter what you choose. The people who have the hardest time migrating are those who skip that.

it will be a relieve for the experts here as i will first time in my life (after many years with OH starting at 1.x) to give openhabian a try. I have some customizations but over the years they become less and less…so i guess it could work…

For Openhabian, as its 3.4.2, i guess i have to set the installation path or similar to testing and it will upgrade to OH4? as the standard Dec’22 image will come with 3.4 on it.


In openhabian-config there’s a menu option to choose between the release (3.4.2), testing (4.0 M1) and snapshots. Once up you can change between versions from there.

But be aware that restoring a backup must be performed on same-version to same-version. You cannot restore a 3.4.2 backup on a 4.0 M1 server. Restore does not go through the automated upgrade steps and potentially leaves your configs incompatible. So restore first, then upgrade (if you plan to do an in place upgrade of an existing system).

thanks for telling me. still uncertain and most likely i wait till easter bunny is visiting town. so i have more time to go back and forward…and most likely its already M2 or M3

Don’t forget there is a Remote openHAB addon and the MQTT EventBus rule template. If you have the hardware (it’s easier to do on separate machines) it makes a lot of sense to run both in parallel, moving stuff over Thing by Thing, Item by Item, and Rule by Rule.

1 Like

Russ, Rich, thanks a lot for your quick reply.

Understand the security issue. However time is the bigger factor for me. I have very little time compared to the time of first setting up OH without kids and without work during lockdowns. That’s why I try to figure out the most efficient way. Even thought of moving to a different system like HomeAssistant but the changes are probably even worse with different logic.

Tough. Either way it’s probably best to get another raspberry and do it step by step.