I am running OH 2.5.12 on my Linux home server (Ubuntu 20.04).
I have 48 things, 160 items and a dozen of rules.
What would be a good upgrade strategy?
Or should I better rebuild everything from scratch with the latest version (4.1.2)?
Docker or native install?
Thanks!
I rebuilt my system when moving from 2 → 3 and I am quite happy that I took the time to do so. There’s so much additional configuration available, especially for items, that while you can just move from 2 → 4 (for the most part) you do loose out on some of the best new features. You can retrofit all that information onto your old item definitions, but in the end that probably winds up being the same or more work as just starting from scratch. That’s especially true if you spend a little time getting used to the new MainUI first and learn about how to easily add bulk item via the model and other quick tips like that.
I’ve used both over the years. I moved from native to docker when I also went from 2 → 3. I was very happy with the native install, the only reason I moved over was that I wanted an excuse to learn docker and that was a great opportunity to do so. I find they have different advantages and downsides. So unless you really need something like a full docker stack, I would say that this remains a personal choice, and my main advice would be to go with the one you feel more comfortable with creating and restoring backups.
3 Likes
When I went from 2.5 to 3 I had 2 openHab installations on different computers and I created new OH 3 rules and items and also changed from DSL to javaScript rules and UI only on the 3 version.
I did one rule at a time from the 2.5 and disabled the converted rule on the 2.5 as I went until I swapped everything over.
Then I shut down the 2.5 install.
When I went from 3 to 4 I just did an upgrade but backed everything up first and I am using a VM so I also did a snapshot.
Good luck.
1 Like
I basically followed and recommend the same approach as @JustinG and @ubeaut. It was a great opportunity to reassess what worked and what didn’t work as well in how I structured my configs.
The only things I have to add are:
-
Do not skip the Getting Started Tutorial. Those who have the most trouble with OH 3.0+ are not brand new users to OH, it’s old OH 2.5 users who fail to review Getting Started.
-
Use the Remote openHAB Add-on during your transition. This lets you mirror all the Items you already have in your OH 2.5 instance in the OH 4.0 instance. That way you can move stuff over little by little and both instances of OH will work together.
-
If you plan on utilizing the semantic model, I recommend recreating your Item from scratch using the “add equipment to model” options. It’s a lot less work than trying to retrofit your existing Items into the semantic model.
Your system is relatively modest so migration should not be too huge of an effort. Personally, I migrated everything one binding at a time. So I’d move the Things and the Items and then any rules that use those Items for a single binding. Once tested I then moved the next and so on. That’s not the only way to migrate but it worked for me.
2 Likes
The only thing I can add is to not get lazy midway through and leave your rules as they are (since they already work). Rip the bandage off and transition your rules as soon as possible. Then, you’ll have immediate access to all of the good stuff that’s come along in OH3/4.
I’m not speaking from experience AT ALL.
(Yes, I am speaking from experience.)
1 Like
Thank you all, @JustinG , @ubeaut , @rlkoshak , and @rpwong for sharing your own experiences and giving recommendations.
I suppose I will do a from scratch install of 4.1.2 and rebuild one-by-one what I have.
2 follow-up questions:
- Can I install OH 4 in parallel to still having OH 2? (I do not expect to run them in parallel.)
- I have been managing things and items in text files (so I can version-control them). Is this still possible in OH4?
Thanks again!
This will be difficult, as openHAB 4 requires Java 17, which will not run openHAB 2.
Yes, you can still use textual configurations, but all UI created stuff is stored in JSONDB files, with automatic backup. Those files can also be version controlled.
The benefit of UI created Things and Items is to be less error prone, as you get the correct syntax from the UI.
1 Like
This might be the reason to try docker. You can absolutely have OH4 running in a docker container in parallel with your native OH2 install.
As @hmerk said, text configuration is still an option. However, it is even possible to use a vcs with the UI configurations. All the configurations you make are stored in yaml files in the /userdata/jsondb folder in you OH configuration folder. These files have been specifically formatted at this point (i.e., all the entries in the yaml arrays and objects are sorted) so that versioning and diffs are easy and sensible. I use a vcs for all my UI configurations.
2 Likes
I started out using files but the UI is better and as already stated does version control automatically.
The UI does everything and you don’t have to worry about syntax etc.
I liked the files but I thought I will ditch DSL and files and see what happens. It works well. My install is similar in size to yours. I think you will find it easier/better .
You can do it any way you want, those are just my thoughts/observations.
Just to circle back around. If you are using managed configs and want to use version control, you’ll want to capture all of $OH_CONF except for installed libraries (e.g. $OH_CONF/automation/js/node_modules). You’ll also want to capture most of $OH_USERDATA except for cache and tmp and possibly persistence (probably don’t want to version control your databases).
I use Docker so my $OH_CONF and $OH_USERDATA folders are in the same root folder so I can check them all into one repo easily. My .gitignore file is as follows:
userdata/*
!userdata/secrets
!userdata/etc
!userdata/jsondb
!userdata/config
!userdata/habot
!userdata/openhabcloud
!userdata/uuid
!userdata/zigbee
!userdata/zwave
userdata/jsondb/backup
userdata/backup
.Trash-1000
conf/html/hum.jpg
conf/html/light.jpg
conf/html/power.jpg
conf/html/temp.jpg
conf/automation/lib/javascript/personal/node_modules
conf/automation/js/node_modules/*
!conf/automation/js/node_modules/rlk_personal
*py.class
*.swp
*~
*.old
If you are not familiar with the syntax, I ignore everything in userdata and then add back in the folders I want to VC (the most important folder is jsondb. In conf I exclude all the node_modules except for my personal library which doesn’t come from npm out there in the wide world.
1 Like
This will be difficult, as openHAB 4 requires Java 17, which will not run openHAB 2.
I don’t see a problem with having different JREs installed for different apps, as long as each app gets its JRE via JAVA_HOME it needs.
I did not say it’s impossible 
So here’s my plan: Install OH4 in parallel to OH2. Looks like all involved directory hierarchies are named “openhab2” so I expect OH4 to live under “openhab4”.
I intend to run it with a new z-wave controller (Zooz 800), separate from the existing one (Aeotec Z-Stick Gen 5). I expect them to coexist.
Reason: I will get solar panels installed on the roof in a few weeks and wanted to base-line the temperature in the attic, but the Zooz temperature sensor doesn’t work with OH2.
This approach gives me plenty of time to install and learn OH4 while my OH2 installation keeps playing.
I know, later, when migrating “stuff” from OH2 to OH4, logically moving z-wave nodes to a new controller can be painful. I guess I’m deferring this pain to the future. LOL
Does this all sound reasonable?
No, the home folders have gone back to just "openhab` since OH 3.0. Because OH 1.x and OH 2.x were so different at that time they use “openhab2” to help make them more distinct. However, since OH 3 the changes are not so drastic and there’s no reason to use different folders.
Because it’s not in the device database?
As long as your old controller works, you could have both controllers operating independently on the same OH instance. Maybe you don’t need to move the nodes over at all.
This might be a problem. The OH Zwave binding only partially supports up to 700 series controllers. I don’t think it works with 800 series controllers at all. You might need to use something like zwave2mqtt to use this controller.
Sounds what I want to install OH4 while still keep OH2 working.
Yes. From this thread: Adding Zooz ZSE44 temperature sensor I figured it might be easiest to see whether OH4 supports the sensor out of the box.
Given that I want to rebuild my stuff in OH4 anyways, I am not concerned at the moment about the migration effort.
Now, an ideal situation would be to keep OH2 working while I migrate, i.e. rebuild, individual things/items/rules in OH4.
I can see that this may take months for me.
But for this I need another zwave controller.
Good you just told me: I was able to cancel my Amazon order for the Zooz 800 controller 
I just realized I still have a Nortek HUSBZB-1 lying around, because I wanted to play with Zigbee, which I never did. This controller also does zwave.
So, that’s my plan: Install OH4 while OH2 keeps working. Using the Nortek controller so I can connect the Zooz temperature sensor
That’s what I use. I can confirm it works well with the Zwave and Zigbee bindings.
1 Like
It’s been in the database since April 2022, so it’s definitely in OH4.1.2.
Given the size of your system, I’d think days, not months. While you do need to review the Getting Started docs, you aren’t entirely learning from scratch. Once you’ve made a few things and items, it’ll be pretty smooth sailing adding everything else.
You can avoid the Z-Wave hassles by using the Remote Binding (as suggested earlier) to access your OH2 system from OH4. Then when you’re ready, just move the Z-Wave controller to OH4.
Before you get too invested in Z-Wave, it’s definitely worth seeing what’s available for Zigbee in your area. I’ve generally found them to be significantly less expensive and easier to find than Z-Wave sensors. Apparently, the new Sonoff temp/humidity sensors are pretty good.
1 Like
I’m not thrilled with the Zooz ZSE44 temperature sensor. It goes through batteries too quickly - at least it reports that it goes through them quickly. I used to replace the battery when it reported below 20%, but now I’ve realized that it continues to work even when it reports 0%. Weird. Maybe you will have better luck.
The Zigbee sensors are cheaper and some of them have much bigger batteries and so far they last much longer. I’ve been trying Tuya, but they seem to stop reporting for a few hours every once it a while. Generally this seems to happen when the battery is new. Slightly irritating.
I’m now trying the Sonoff SNZB-02P. It doesn’t use AAA batteries, but maybe it will behave better than the ones above.
1 Like
Thanks @jswim788 for the info. I just ordered a Sonoff SNZB-02.
So, I’ll get into Zigbee then on my OH2 installation.
My immediate itch is getting temperature readings from the attic before the solar panels get installed.
Note that there is a SNZB-02 and SNZB-02P. The latter is newer and has a larger battery.