Had a few wonky things happen all at once here so not sure if it’s directly related to the update or not. So last night my openhab server was unresponsive so I ssh into it and rebooted it. Went to it this morning and I could access it but all the configured things were offline(unfortunately I can’t remember the error) so I rebooted again with the same result. In the logs it was giving framework errors. I then decided to update openhab and the entire system to see if that would fix it, that does seem to have gotten everything going again with the exception of two dsl rules, they give the following error when trying to run. This is the EMC Corn Rule, the Soybean EMC Calculation is the same except it has different constants in the equation. The rules are set to trigger every minute. I didn’t see anything in the breaking changes for 5.2 that I thought could cause this but I could be wrong, this could also be part of last nights problems.
RROR org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler Script execution of rule with UID 'EMCCorn' failed: / by zero
exclamationmark_octagon_fill 08:55:00.577 ERROR org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler Script execution of rule with UID 'SoybeanEMCCalculation' failed: / by zero
your code goes he
var Number tempf = BigChief_SHT3XTemperature.state as Number
var Number tempc = (tempf - 32)/1.8
var Number hum1 = BigChief_SHT3XHumidity.state as Number
var Number hum2 = hum1/100
var Number numeratora = -0.076819*tempc
var Number numeratorb = 13.9005+numeratora
var Number denominatora = 1/hum2
var Number denominatorb = denominatora-1
var Number denominatorc = Math.pow(denominatorb.floatValue,0.33756071873)
EMCCornDrying.postUpdate(numeratorb/denominatorc)re
The error is divide by zero, which of course is mathematically impossible.
So hum2, or denominatorc is being calcualted as 0.
Check the states of your Items, log them out in the rule and perhaps test to make sure you don’t have zeros in the denominators of calculations.
As an aside, UoM and the Weather Calculations [4.2.0;4.2.99) addons could probably replace this rule. Though it doesn’t appear to have been updated for OH 5 so the add-on may not work.
What is “new” is that we have exposed some of the errors that might not have been visible before. Division by zero has never been “possible”, and never will be, so my guess is that the rule has always failed when BigChief_SHT3XHumidity is zero/null/undef, but it hasn’t been logged before.
The humidity was 100% this morning, I completely forgot about that. It has always spazzed out when it hits 100%, with everything else that had happened I didn’t think to look for that. I think I may still have a problem with my install though. It takes close to 5 minutes before I everything is initialized now. When I ssh in it says there are 179 updates so I try to update and it comes up with several errors.
openhabian@openhabian:~ $ sudo apt-get update
[sudo] password for openhabian:
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian-security bookworm-security InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Get:4 http://davesteele.github.io/comitup/repo comitup InRelease [4,659 B]
Hit:5 https://deb.nodesource.com/node_22.x nodistro InRelease
Get:6 https://pkgs.tailscale.com/stable/debian bookworm InRelease
Hit:7 http://archive.raspberrypi.com/debian bookworm InRelease
Get:8 https://packages.adoptium.net/artifactory/deb bookworm InRelease [7,507 B]
Hit:9 https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable InRelease
Err:4 http://davesteele.github.io/comitup/repo comitup InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B5E293D64E192FDE
Fetched 18.8 kB in 3s (5,853 B/s)
Reading package lists... Error!
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://davesteele.github.io/comitup/repo comitup InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B5E293D64E192FDE
W: Failed to fetch http://davesteele.github.io/comitup/repo/dists/comitup/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B5E293D64E192FDE
W: Some index files failed to download. They have been ignored, or old ones used instead.
E: Unable to parse package file /var/lib/apt/lists/deb.debian.org_debian_dists_bookworm_main_binary-armhf_Packages (1)
W: You may want to run apt-get update to correct these problems
E: The package cache file is corrupted
When I run sudo openhabian-config it does open but this is the output in the terminal…
openhabian@openhabian:~ $ sudo openhabian-config
2026-07-09_20:46:08_CDT [openHABian] Checking for root privileges... OK
2026-07-09_20:46:08_CDT [openHABian] Making sure router advertisements are available...
$ sysctl --system
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /etc/sysctl.d/98-rpi.conf ...
* Applying /usr/lib/sysctl.d/99-protect-links.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.pid_max = 4194304
kernel.printk = 3 4 1 3
vm.min_free_kbytes = 16384
net.ipv4.ping_group_range = 0 2147483647
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.accept_ra_rt_info_max_plen = 64
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.accept_ra_rt_info_max_plen = 64
OK
2026-07-09_20:46:08_CDT [openHABian] Loading configuration file '/etc/openhabian.conf'... OK
fatal: unterminated line in .git/packed-refs: ���������������������������������������������������������������������������...
fatal: unterminated line in .git/packed-refs: ���������������������������������������������������������������������������...
fatal: unterminated line in .git/packed-refs: ���������������������������������������������������������������������������...
2026-07-09_20:46:08_CDT [openHABian] openHABian configuration tool version: []{}()
2026-07-09_20:46:08_CDT [openHABian] Checking for changes in origin branch openHAB... fatal: unterminated line in .git/packed-refs: ���������������������������������������������������������������������������...
FAILED (fetch origin)
2026-07-09_20:46:08_CDT [openHABian] Checking for updates of openhab_rules_tools for JS Scripting... No update available.
fatal: unterminated line in .git/packed-refs: ���������������������������������������������������������������������������...
fatal: unterminated line in .git/packed-refs: ���������������������������������������������������������������������������...
fatal: unterminated line in .git/packed-refs: ���������������������������������������������������������������������������...
2026-07-09_20:46:14_CDT [openHABian] Checking for default openHABian username:password combination... OK
2026-07-09_20:46:14_CDT [openHABian] We hope you got what you came for! See you again soon ;)
Is there any course of action to resolve those and get it all to update and behave or did something get corrupted and need to start with a clean install and restore my config? Maybe with a new sd card?
Create a backup of OH and move it off the SD card somehow.
Have you installed and configured anything besides openHAB through openHABian? If so you need to identify what and see if there is anything you need to backup from there too (e.g. InfluxDB, Mosquitto, Node Red, etc.). Back those up too and move them off the SD card. Specific instructions will depend on the service.
On a new SD card burn the latest raspberry pi OS version. Put the openhab.zip backup file in the boot partition and edit openhabian.conf as needed. One of the options in that conf file will cause openHABian to restore your OH config as part of setting everything up.
If there is room, you can put your other backup files ont he boot partition too so they are avaialble to manually restore when the machine comes back online.
This all is easier because you are moving from same version of OH to same version of OH so none of the usual gotchas will apply.
If you have a spare RPi to do this on, you don’t necessarily need to take down the original until the new one is ready to take over. If not, don’t mess with the original SD card and if you run into trouble you can just swap back to this broken one until you have time to deal with what’s wrong.