Openhabian transition from 2.5.10 to 3.0.0 M5 : Experience & Comments

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.

Bob

1 Like

Actually, those logs were just suppressed in the default config in OH 2.5. It might not be a bad idea to file an issue to suppress those in OH 3 as well. The Language Server re-parses the rule every character you type. That’s why you can get those red underlines as you go before saving the file.

good point, I had stumbled across that as well and have just put that into openHABian.

1 Like

Thanks for that piece of info. The log filters I added kept the garbage out of the openhab.log, but the VSC still went crazy, so I also adjusted the JSON to turn the language server “false”. That seemed to solve the problem in VSC. I do like the idea of default suppression.

The error/message you get after halting and restarting is

E: dpkg was interrupted, you must manually run ‘sudo dpkg --configure -a’ to correct the problem.

I ran into the same problem today, I imaged my SD card before, I just wanted to play and see how things went. I’ll probably just revert my card back tho if I run into any oddness. Or spouse anger issues. :smiley:

They should be automatically archived when this PR is merged:

Great. That should save a lot of “posts” when OH3 production is released.

Bob

I had the same problem until I activated the loggings on install in the config file when I installed openhabian (manually). Then when I installed oh3 from openhabian it ask to copy some files wher you answer yes to everything and it continues to the end…
was a tip from

This sounds a lot like the solution based on the behavior I experienced. When I upgrade my other OH system I will do this and mark this answer as the solution Thanks for the tip
Bob

Did you add this line?

Enable debugmode=maximum in /etc/openhabian.conf and try again.

I tried installing OH3 on diff RPi with diff SD cards and I always get stuck on the installation line…

Hey all (and especially @bdv),

i faced the very same issue when installing OH3.0.0M5. The unattended installation took for hours, then i terminated it, raised the debugmode, restarted the installation and saw, that it was asking for handling of file conflicts (local vs repo). I answered them and then the installation went through (beside problems with ZRAM, which i pointed out at a different thread).

Hope this helps others as well

P.S.: Did you know, that you can edit the openhabian.conf file also on the SD card when freshly imaged? There you can enable debugmode as well prior to the installation of the card / OS / …

1 Like

@mstormi
please correct me if I am wrong, but the issue discussed above could be in interesting for you?

Could you please reproduce this, open a Github issue and provide the debugmode log ?

Already on it. Grabbed a fresh sealed SD card, openhabian v1.6.1, and it is currently installing openHAB2.5. Will then directly upgrade to OH3.0.0M5 and post the debugmode log in GitHub.

Edit: here it is: https://github.com/openhab/openhabian/issues/1299