History and some hints for Update from 2.5 to 4.1

Setup, Configuration and Use Migration
1

Hi!

I started my home automation using Pilight on a Raspberry 3B to control some 433MHz switches and shutters. As 433 MHz tends to be unreliable due to interference from neighbor devices, I migrated to Shelly devices using WLAN. They were regimentally included in Pilight by MQTT.

To have more possibilities, I then switched to openHAB 2.5. It was initially installed on an Ubuntu box to set up things, items, habpanel and rules and was then manually installed in the Raspberry on top of the Pilight installation, using Shelly and Pilight-bindings.

This was running relatively stable for some years, until I lost some Shelly Gen1 devices due to an overvoltage and had to replace them by Gen 2 devices. As those were not supported by the 2.5 Shelly-binding, I was forced to migrate.

I started again on the Ubuntu box with OH3. Unfortunately the Shelly Plus PlugS were not yet supported. I tried to use a beta Shelly-Binding but did not succeed.

By this time OH4 was released and I started a new test setup. As I’m more proficient on Windows, I used the Windows setup, which worked flawlessly. I developed a new test version from scratch, using the chance to clean up my naming’s, etc
 I used PaperUI for things and items, HABPanel for the UI und rules in DSL-based .rules files. Backup-files were regularly generated. When everything worked, I was ready to move to the Raspberry.

The transmitter/receiver for 433MHz was removed, as I had fully moved to Shelly. I prepared a new SD card using openHABian 1.8b 32Bit.

After flashing with Etcher the validation failed. I used another card, but to no avail. It seems to be a Windows related problem, because Windows tries to mount the new partitions and robs Etcher the access to the card. So I ignored the validation-error and had no Issues during install.

I moved my latest backup-zip to the root of the card and entered it in openhabian.conf. The install worked fine, but the backup was not restored. I then copied the backup-zip manually and tried to restore via openhabian-config. This showed the reason for the failure, the zip contained backslashes. This turned out to be a bug with the generic packing in WIN10. Although windows uses backslashes, it should write normal slashes into the zip directory. After unzipping and rezipping using WinZip the backslashes were gone and the restore could be done. This worked great, restoring bindings, things, items, rules, persistence, etc.

I could not access the shared samba directories with write permission from windows. Running openhabian-config menu 14 did fix the permissions.

As I want to access the log-files directly from windows, I removed zram using menu 38 of openhabian-config. Now the logs were written to files, but could not yet be accessed by Windows. I had to remove the comment signs in the [openHAB-logs] section of /etc/samba/smb.conf. To avoid stressing the SD card I changed the logging for events.log from INFO to WARN in openHAB-userdata/etc/log4j2.xml.

I hope this might help somebody, who is doing a similar migration

The new installation of OH4 runs very stable, I’m now happy I did migrate and did use openHABian to setup the SD card

Uli

2 Likes
2

Usually when we say “manually installed” we mean we followed these instructions. Is that what you did or do you mean you installed using apt?

Note that PaperUI does not exist in any version of OH outside of 2.x. OH 3 and OH 4’s user and admin UI is called MainUI.

I don’t understand this section. Even with zram enabled the files are logged to files. Those files are just located on a zram filesystem, not a file system on the SD card.

3

Hi!

Thanks for your response.

My first OH 2.5 install was using apt, as I already had the Pilight, Mail and MQTT installs on the Raspberry.

I used the name PaperUI as I was used to it by 2.5. I meant using the graphical UI for binding, things and items.

I want the logs to persist, even in a case of powerloss, so I choose to disable zram

Uli

4

Hi!

The mentioned 4.1.0 installation got very unstable, showing I/O-errors and kernel panics. I bought a new sd-card (samsung evo plus) and reinstalled with openhabian 1.9 getting openhab 4.1.1 and then restored from my backup.

By the way I mentioned in my previous post a validation problem with etcher under windows. I got this again with the new card. But then I first removerd all volumes and partitions form the card using windows “DatentrĂ€gerverwaltung”. Afterward the flashing and validation worked just fine.

Now everything is working with one exception. All cron-triggers execute one hour to late. As well all times in the log a one hour back. But in habPanel the sidebar shows the correct time.

I checked the following:
The timezone in openhab settings is correct (Berlin UTC+1)
The local time in the OS with date or datetimectrl is correct

I have not found anything on that issue in the forum. Any ideas ?

Uli

5

Is the local time zone on OS level correct, too?

6

Thanks for the reply. It is correct

image
image1139×316 15.6 KB

image

Uli

7

From what I found it might be connected to a different timezone in java. Any Idea where to check this

Uli

8

That’s not a good idea. Disabling zram is likely the reason why you have run into trouble now so you should re-enable that if you don’t want that to happen again.
Why would you want to persist logs at all? They’re not usually not useful and rotated when the file size limit is reached so older logs will be gone anyway.
If you insist on keeping them (again, why?), you can back them up using Amanda or set up SD mirroring.
Either way, setting up mirroring is always a good idea to have a ready-to-run fallback option.

I suggest reading the docs again and not use Etcher. Get an ‘Endurance’ SD card and use the Raspi imager instead, it offers to download and install latest openHABian right away (v1.9 as of now).

PS: Just use the openhabian-config menu to reenable zram and setup mirroring. No need to reinstall.

9

Just a thought here if Etcher is not the correct or actual recommended tool to burn your SD card then perhaps the main download page should not list it and provide a download link to it as the recommended tool. seems like instruction docs are in conflict.

10

Hi Markus!

I want the logs to be persistent in case I run into some problems and have to restart the raspi by pulling the power. I also use logging to store some values (e.g. the daily count of the gas-meter).

I’m aware of the limited write-cycles of the sd-card. Therefore I log events only in case of warnings, as this is the greatest number of writes. The openhab.log and my additional gas.csv are only a few hundred bytes per day. The new card is a special high endurance-card, as recommended.

The use of etcher resulted from the documentation at Download openHAB | openHAB

Uli

11

And if you pull the power while OH is writing those logs you risk corrupting your entire file system. Seems like it’s better to lose a few minutes or even hours of logs than it is to risk losing everything on that card. In addition to reducing wear on the SD card, zram reduces the likelihood that a write is taking place when/if power is lost, reducing the chance that the file system becomes corrupted.

It’s not the amount of the bytes written. It’s the total number of writes executed. Writing one byte every five minutes is the same as writing 1kB every five minutes when it comes to SD card wear.

12

The 1 hour-off problem with chron and log seems to be solved :grinning::

In /etc/default/openhab I added

-Duser.timezone=Europe/Berlin to EXTRA_JAVA_OPTS

After systemctl stop/start this is reflected by printenv and chron and logging are now in local time.

In my previous installation with openhabian 1.8b and openHAB 4.1.0 this was not necessary. Any idea why :question:, perhaps related to the new OS bookworm ??

Uli

13

I doubt that adding the settings to /etc/default/openhab has solved the problem because cron jobs do not make use of this file.
I guess it was solved by systemctl stop/start.
You can try by removing this setting and see what happens.

14

Hi Oliver2

I removed the -Duser.timezone from the file and stopped/startet openhab. printenv still shows the -Duser.timezone, but the logs are one hour off again. So I added it again, stopped/started and everything is fine

Uli

15

Hi Rich!

Ok, I enabled zram and give it a try

Uli

16

And openHAB logging is by far the smallest contributor here.
Putting /var/log (and swap !) on zram will also mitigate system logging effects.