I have two OH instances. My primary system on an Rpi3 (SD card) with z-wave devices and a secondary system on an Rpi4 - 2GB with the IP-camera binding and an USB attached SSD for storing video. I also use the MQTT event bus as some of the video is triggered by Z-wave motion events.
Last Friday (12/4) I thought I would try to upgrade the Rpi4 from 2.5.10 to OH3 M4. Both systems use openhabian. I ran the openhabian 1.6.1 master (on 12/4/2020) Option 42-Beta for the conversion.
Spoiler Alert: This story has a happy ending.
The installation hung. I hesitate to report this since I have little troubleshooting information to help anyone. This could have just been me. I did have a full backup, but did not have maximum logs turned on. At the point of failure, using a file explorer, I did find all the openhab directories had been created alongside of the openhab2. Using htop it openhabian appeared to be stuck on:
Apt-get install –allow-downgrades –yes openhab=3.0.0~M4-1 openhab-addons=3.0.0~M4-1
I let it run until the next morning, in case it was just slow. I then rebooted the RPi4 and tried to manually type in the above command. I got some message that a package was interrupted and to type something (that I no longer recall). It finished and said to start openhab, which I did and everything seemed to be ok. I did an apt update/upgrade, and ending up with M5.
In the UI all my previous bindings (Ipcamera, FTPupload and Mqtt) were successfully installed. Also my textual items were there. The textual camera things did not appear. However, I was able to recreate them with search, so I was pretty much up and running and trying to understand how to navigate OH3.
I did have two issues that took longer. 1) There is a new IP camera process for the animatedGif, but Matt pointed me to the 3.0 documentation, so I got that working and 2) the MapDB issue reported by others.
My only suggestion for the Openhabian migration script is to erase the mapdb files in
/var/lib/openhab/persistence/mapdb. According to community posts Mapdb will not work until they are gone. That worked for me after some searching for the relevant info.
Yesterday I moved the DSL rules (a few at a time) from OH2.5.10 over to the OH3 RPi4. With the event bus it doesn’t matter which system has them and I wanted to fix any issues before converting the Rpi3 (down the road). The only issue I noticed while fixing a rule problem using VSC, it seems that OH3 keeps trying to run the rule as I’m editing and fills the openhab.log exponentially. Under 2.5.x OH ignored work-in-progress until you hit save. This may not be what is happening behind the scenes, but it what appears to me on the surface. I thought about stopping OH3 while editing the rules, finding a flag in VSC to work offline or suppress the logs.
Logger level=“OFF” name=“org.eclipse.xtext.ide.server.concurrent.ReadRequest”/>
Logger level=“OFF” name=“org.eclipse.xtext.ide.server.concurrent.WriteRequest”/>
Logger level=“OFF” name=“org.eclipse.xtext.ide.server.WorkspaceManager”/>
I haven’t tested these log entries, but these are the ones acting up.