I read a lot about upgrading OH2.5 to OH3 and its difficulties. So I decided to ask the community about how to do it best in my case.
OH2.5 is running directly on an x86 Debian 10 server w/ software raid. The server is also working as a time machine and video surveillance server (Zoneminder) and doing some other tasks.
I have 150+ devices connected to OH2.5. Most devices are Homematic/Homematic IP and Philips hue. Others include Daikin ACs, Denon AVRs, Gardena Mowers, one Chamberlain garage opener and a few Shelly devices. In addition the server hosts a Mosquitto MQTT broker which gets the information from a few OwnTracks instances on smartphones for GeoFencing. Things are created using paper UI, items, rules and sitemaps are created by files.
A display server fetches information from OH2.5 using the RestAPI. Some functionality is also glued together using bash commands and the RestAPI. This way I transfer data from the Senertec Dachs BHKW (Combined Heat and Power Plant).
I also installed grafana and influxdb for persistence and graphs particular for heating, power consumption and the like.
Now, what would be the best way to upgrade the system to OH3 ? I cannot afford a long downtime since a lot of automation is used for our home (which is a former farm). It seems to me that the best would be to do a fresh OH3 install on the very same machine and manage to let it use a different port than 8080. Would that work ? Can I switch influxdb to this instance later as soon as all items are registered on OH3 ? This way I could run OH3 as a second instance and move the rules file by file to the new instance.
Please comment. I would also be glad to learn how to install OH3 parallel to OH2.5.
If you can I’d set up oh 3 on a different machine. Use the Remote openHAB binding to mirror the Items from your OH 2 instance in OH 3. Reimplement the automations binding by binding on OH 3 is a kind of dummy mode. When satisfied it all works disable the OH 2 stuff and move to the next thing.
This way you can minimize the down time during the transition. There might be down time for one technology but not the whole OH instance.
Once everything is moved over, cut a backup, instead OH 3 on the main server, and restore the backup there.
It could be made to work all on one machine but that will introduce an extra layer of complexity and it’s already complex enough.
Yeah, that is something I want to avoid - although it might be possible. Does it work to do this on an RPi even the target will be an x86 machine ? Is it recommended to dockerize OH3 even if I go this way ?
I thought it might be a way to put OH3 into a docker container and define port 8081 (for example) as the OH3 access port instead of port 8080. The same must be done for the caraf console IIRC. What about Grafana and Influxdb ? These can be the same for both installations, can’t they ?
What do you think ?
Sorry for not following your suggestion in the first place. I think this way I can switch from one installation to the other much easier.
Many recommend against using Docker on an RPi because of the limited memory. I only recommend Docker if you already know what Docker is, how it works, and what it’s intended to do. Docker could be a convenient way to manage openHAB but far too many don’t know how is works and run into problems.
But in general, it’s going to be way less work to set it up on a separate machine and then migrate it back when it’s done.
There are a whole lot more ports involved than that. Some bindings open their own ports too. In addition OH and many OH bindings depend upon sending and receiving broadcasts and other similar network activities which requires the container to be on the same subnet as the things using the broadcasts. That’s why the recommended Docker deployment is to use --net=host and not try to expose. That’s also one reason why it’s challenging to run two instances of OH on the same machine.
Yes but in OH 3 some bindings changed the types of some Items which will cause some problems. I think that the InfluxDB 3 binding also does some modifications of the database during an upgrade which could cause some problems for your OH 2.5 instance.
I guarantee you it will not be easier. Been there, done that. Once you go through the hours worth of effort getting all the ports identified and forwarded correctly and get OH 3 running on the same machine, you won’t have a fully functional OH 3 instance anyway because it’ll be behind in a Container without the same access to the network as the OH 2.5 instance which will break worst or change the behavior of bindings at best (e.g. you’ll have to manually add your Chromecasts because without --net=host your OH 3 instance can’t discover them in the normal way).
Thank you very much for your detailed explanations. I really appreciate that. I will install a fresh openhabian 3 on an RPi and move everything over. Then I’ll do the backup and restore process on the old machine and have everything in place. That’s the plan. Will get back here if I’m stuck.
