openHAB 5.0 Release Discussion

[mstormi (Markus Storm)]

@rlkoshak

A Pi 2 likely doesn’t have enough RAM to run OH now. It was marginal for OH 2 and the RAM requirements for OH has only increased over time

Well if you get it to work in 32bit, it should need just about as much mem as in OH4, and a RPi2 has 1 GB just like a RPi3 does, so it might work.

But as Rich and Florian already responded, too, that means to resort to an unsupported JVM and we will not help you with that any longer.
You really should not be sticking with hardware as outdated as that, replace your box with a RPi 4 or 5 with 2+ GB.

[rlkoshak (Rich Koshak)]

@mstormi

Well if you get it to work in 32bit, it should need just about as much mem as in OH4

It depends. I’ve seen some increase in memory usage in OH 5 which I attribute to the change in the MQTT Home Assistant binding switching to use GraalPy and the actual Python code from HA instead of reverse engineering the standard from their docs. There are other similar type changes which can significantly increase memory requirements. But as with all things YMMV.

[ra_dzik]

Thank you! Very gooood job OH contributors!

Once again - thank you!

[ErikDB (Erik)]

@rlkoshak

However, the reason I bring this up is that the regenerate only works for rules created from templates after upgrading to OH 5. So even if there are no changes to the template on the marketplace, it might be worth recreating all your rules so that when there are changes it will be easier. If you don’t remember what you set for the properties, you can open the code tab and see them in the “configuration” section.

Aha, that’s good to know!

[Udo_Hartmann]

since upgrade to 5.0.0 I can no longer use charts in BasicUI. I get the error message

2025-07-23 19:00:48.538 [WARN ] [org.eclipse.jetty.server.HttpChannel] - /chart
java.lang.UnsatisfiedLinkError: /usr/lib/jvm/jdk-21.0.7-oracle-x64/lib/libfontmanager.so: libfreetype.so.6: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden

At least /usr/lib/jvm/jdk-21.0.7-oracle-x64/lib/libfontmanager.so does exist.

[mstormi (Markus Storm)]

That rather sounds like a bad Java setup of yours?

[jackmule (Jackson)]

During my first attempt to install Java 21 (Temurin), the dpkg process froze. I had to kill it manually:
sudo kill <your_pid>

Then I cleaned up the lock files:
sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock

And repaired the configuration:
sudo dpkg --configure -a

On the second try, the Java upgrade worked fine. My system (openHABian on Bookworm) was previously on Java 17. When I initially ran sudo apt upgrade, it failed because the openHAB 5 pre-installation script correctly detected the wrong Java version, which caused the first dpkg error.

Preparing to unpack .../openhab_5.0.0-1_all.deb ...
[openHAB] WARNING: We were unable to detect Java 21 on your system. This is needed before openHAB is unpacked.
[openHAB] Java 21 may not be available on 32-bit platforms.
dpkg: error processing archive /var/cache/apt/archives/openhab_5.0.0-1_all.deb (--unpack):
the new 'openhab' package's pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
/var/cache/apt/archives/openhab_5.0.0-1_all.deb
Updating FireMotD available updates count ...
E: Sub-process /usr/bin/dpkg returned an error code (1)

After successfully upgrading to openHAB 5, my Enocean USB300 Dongle was “NOT YET READY”.

The final solution was to install a missing dependency via the openHAB console:
openhab-cli console
feature:install openhab-transport-serial

This brought all my EnOcean devices back online immediately.

Everything is running smoothly again! Does anyone know why feature:install openhab-transport-serial is often necessary again after updates?

Here’s a summary of the technical issue and the suggested feedback.

---

Technical Summary

The package upgrade process failed due to a two-stage problem. First, the openhab package pre-installation script correctly detected a missing dependency (Java 21) and aborted the unpacking phase. This, however, left the package in a “half-installed” state.

Subsequently, an automated attempt to fix this broken state by running dpkg --configure -a was initiated. This repair process encountered an unrelated file conflict (initramfs.conf) that required interactive user input. Since the script was running non-interactively, it could not answer the prompt and froze, locking the entire package management system and requiring manual intervention to kill the process and resolve the lock.

Suggested Feedback

This situation highlights a potential improvement for package management scripts, especially for unattended upgrades.

It would be beneficial if package managers or wrapper scripts (like openhabian-config) had a more robust mechanism to prevent such deadlocks. For instance, an upgrade process could run in a strict “non-interactive-only” mode. In this mode, if any step attempts to trigger a user prompt (like the dpkg configuration question), the process would immediately fail with a clear error message instead of freezing. This would prevent the system from entering a locked state and would inform the user that manual, interactive intervention is required before any processes need to be killed.

[rlkoshak (Rich Koshak)]

@jackmule

Everything is running smoothly again! Does anyone know why feature:install openhab-transport-serial is often necessary again after updates?

It’s usually only necessary when one has installed an add-on by dropping the jar file in the addons folder. That doesn’t look for and install the bundles it depends upon. However, if the add-on is installed normally using addons.cfg or through the UI it should install the dependencies automatically.

[jackmule (Jackson)]

@rlkoshak

However, if the add-on is installed normally using addons.cfg or through the UI it should install the dependencies automatically.

Hm, strange. I actually installed the EnOcean binding via the UI on my old openHABian (bullseye). I installed openHABian (bookworm) just two or three weeks ago and then imported the backup (openHAB 4 old/new respectively - openhab-cli backup). Can importing the backup trigger this as well?

[dsta]

Hello,

I’m trying to upgrade my openHAB setup to version 5 using Docker, and I’ve run into persistent issues with the upgrade tool failing due to a missing class: tech.units.indriya.AbstractSystemOfUnits.

• I’m running openHAB in a Docker container, based on the official openhab/openhab:latest image (trying to upgrade from 4.3.6)
• I made sure the addons folder is empty to avoid classpath issues.
• No volumes are mounted over internal directories like /openhab/runtime or /lib.
• JAVA_HOME was manually set in my docker-compose.yml (currently removed to avoid conflicts with the container’s own JDK).

This is my latest log:

Update tool failed, please check the openHAB website (www.openhab.org) for manual update instructions.
... 25 more
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
Caused by: java.lang.ClassNotFoundException: tech.units.indriya.AbstractSystemOfUnits
at org.openhab.core.tools.UpgradeTool.main(UpgradeTool.java:122)
at java.base/java.lang.Iterable.forEach(Unknown Source)
at org.openhab.core.tools.UpgradeTool.lambda$2(UpgradeTool.java:134)
at org.openhab.core.tools.internal.ItemUnitToMetadataUpgrader.execute(ItemUnitToMetadataUpgrader.java:104)
at java.base/java.util.concurrent.ConcurrentHashMap$KeySetView.forEach(Unknown Source)
at org.openhab.core.tools.internal.ItemUnitToMetadataUpgrader.lambda$0(ItemUnitToMetadataUpgrader.java:161)
at org.openhab.core.types.util.UnitUtils.<clinit>(UnitUtils.java:63)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown Source)
at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown Source)
at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
Exception in thread "main" java.lang.NoClassDefFoundError: tech/units/indriya/AbstractSystemOfUnits
[main] WARN org.openhab.core.tools.internal.ItemUnitToMetadataUpgrader - silvercrest_smart_plug_01_power: Could not determine if channel 'mqtt:topic:78b913f906:6d7747bef8:power' sets a state description. Check if you need to set unit metadata.
[main] INFO org.openhab.core.tools.internal.ItemUnitToMetadataUpgrader - Copying item unit from state description to metadata in database '/openhab/userdata/jsondb/org.openhab.core.items.Item.json'
[main] INFO org.openhab.core.tools.UpgradeTool - Executing itemCopyUnitToMetadata: Copy item unit from state description to metadata
[main] ERROR org.openhab.core.storage.json.internal.JsonStorage - Couldn't deserialize value 'org.openhab.core.storage.json.internal.StorageEntry@35fc6dc4'. Root cause is: org.openhab.core.tools.internal.Upgrader$UpgradeRecord

and this is my docker compose:

openhab:
    container_name: sh_openhab
    image: openhab/openhab:latest
    environment:
      CRYPTO_POLICY: limited
      EXTRA_JAVA_OPTS: -Duser.timezone=Europe/Berlin -Xms1000m -Xmx2000m
      GROUP_ID: 9001
      USER_ID: 9001
      KARAF_EXEC: exec
      LC_ALL: en_US.UTF-8
      LANG: en_US.UTF-8
      LANGUAGE: en_US.UTF-8
      OPENHAB_BACKUPS: /openhab/userdata/backup
      OPENHAB_CONF: /openhab/conf
      OPENHAB_HOME: /openhab
      OPENHAB_HTTP_PORT: 9508
      OPENHAB_HTTPS_PORT: 9608
      OPENHAB_LOGDIR: /openhab/userdata/logs
      OPENHAB_USERDATA: /openhab/userdata
    ports:
      - 9508:9508    
      - 9608:9608
      - 9124:9124
      - 5353:5353
    volumes:
      - ./openhab/conf:/openhab/conf
      - ./openhab/userdata:/openhab/userdata    
      - ./openhab/addons:/openhab/addons     

I’d appreciate any advice or insights from others who might have encountered a similar issue.

Thanks!
Dominik

[glen_m]

@rlkoshak

Clearing the cache at this point likely undoes much of the work you were patient for in the first step. Have you ever tried without the cache clearing?

Yup - Did that - Still seemed to be the same type of behaviour (lots of CPU, not all things up, bunch of errors)!!
TBH, after clearing the cache, OH came up next time fairly quickly & cleanly… Anyway running nicely now
Cheers

[jimtng]

@dsta

issues with the upgrade tool failing due to a missing class: tech.units.indriya.AbstractSystemOfUnits.

See above openHAB 5.0 Release Discussion - #22 by jimtng

[dsta]

Thanks, I must have missed that in the thread. I’ll patiently wait for 5.0.1

[ErikDB (Erik)]

I’m not sure I understand the error. Is it Docker related? Or more importantly to me: should I hold off my upgrade (Running on Linux Mint)?

[Nyarly (Jan)]

I just upgraded from 4.3.6 to 5.0.0. Almost everything worked right from the start, I just had to change the TTSVolume type in the Amazon echo control binding (from Number:Dimensionless to Dimmer), which I didn’t see in the changelog.

Right now, there’s only one issue that remains: I have a DSL rule that compares temperatures that’s not working anymore.

Item definition:

Number:Temperature TempMaxToday "Temp Max Today [%.1f %unit%]" <temperature> { channel="openweathermap:weather-and-forecast:api:home:forecastToday#max-temperature" }

Rule:

if (TempMaxToday.state >= 23.5|°C) { ... }

This works in 4.3.6, in 5.0.0 I get a constant stream of exceptions like the following:

2025-07-24 12:28:11.202 [ERROR] [xbase.resource.BatchLinkableResource] - resolution of uriFragment '|::0.2.0.2.0.0.0.6.7.6.6::0::/1' failed.
java.lang.UnsupportedOperationException: Missing type computation for expression type: QuantityLiteral / ExpressionTypeComputationState: ExpressionAwareStackedResolvedTypes: [
  parent: [
    expressionTypes:
      org.eclipse.xtext.xbase.impl.XCastedExpressionImpl@7ebbcbd1 ->
        TypeData [expectation=TypeExpectation [expectation=Comparable<? super Unbound[C]>], type=QuantityType<Number>, flags=[SUCCESS, SUBTYPE, CHECKED], returnType=false]
    featureLinking:
      <XCastedExpressionImpl> >= <QuantityLiteralImpl> ->  [>=:org.eclipse.xtext.xbase.lib.ComparableExtensions.operator_greaterEqualsThan(java.lang.Comparable,C) [key: operator_greaterEqualsThan(java.lang.Comparable,C)+]]
    unboundTypeParameters:
      java.lang.Object@5d4b4781 -> Unbound[C]
    typeParameterHints:
      java.lang.Object@5d4b4781 ->
        LightweightBoundTypeArgument [
  typeReference = QuantityType<Number>
  source = INFERRED
  origin = ? super Unbound[C]
  declaredVariance = IN
  actualVariance = INVARIANT
]
(...)

If I change the comparison to the following, the exception(s) disappear(s):

if ((TempMaxToday.state as QuantityType<Number>).floatValue >= 23.5) {...}

What changed between 4.3.6 and 5.0.0? What’s the correct way to compare QuantityTypes with UoM? Thanks!

[rlkoshak (Rich Koshak)]

@jackmule

Can importing the backup trigger this as well?

I doubt it. I’ve never heard of that happening at least.

[HenMus]

Is there anything added in version 5 what wil help to find where messages like this are coming from? Not sure if this is possible at all.
PS Thanks for this version but reading this treat I will wait for the next version assuming there is a docker related issue.

[INFO ] [see.internal.command.AbstractCommand] - Request failed: java.util.concurrent.TimeoutException: Total timeout 120000 ms elapsed

[rlkoshak (Rich Koshak)]

I can’t actually find this class as part of openHAB core, so I would guess it’s coming from an add-on, perhaps one whose name ends in “see”. Searching the repo reveals the Easee binding as the source.

It’s an INFO level log statement so it’s not necessarily an error. You can change the binding’s logger to WARN and it will suppress these log statements. You can do this from MainUI at Developer Tools → Log Viewer → cog icon in the lower right corner. The logger name will be “org.openhab.binding.easee” .

Someone who knows this binding will have to comment as to why the timeout is occuring and why it’s logged.

@HenMus

PS Thanks for this version but reading this treat I will wait for the next version assuming there is a docker related issue.

There is no Docker specific problem I’m aware of. I run in Docker without issue.

The problem @ErikDB is experiencing above is related to the upgradeTool which applies to all installations. That fix has been merged and will be backported to 5.0.1.

[ranielsen (Rob Nielsen)]

@HenMus

s there anything added in version 5 what wil help to find where messages like this are coming from? Not sure if this is possible at all.

modify userdata/etc/log4j2.xml and change all occurrences of [%-36.36c] to a larger number. Currently its only printing the last 36 characters.

[boris03 (Boris)]

I am running OH 4.3.5 in docker/portainer under Debian12.
As usual I just stopped the container and recreated using latest image.
Unfortunatelly I cannot reach OH anymore using localP:8080
Portainer shows the container on “green”.
Checking glances says openHab is restarting.
Something not correct I would assume, can you help me please?

Container log says in last line
/entrypoint: line 119: exec: gosu: not found

100
Actions
      
+ echo 'Starting with openhab user id: 998 and group id: 997'
+ id -u openhab
+ initialize_volume /openhab/conf /openhab/dist/conf
+ volume=/openhab/conf
+ source=/openhab/dist/conf
++ ls -A /openhab/conf
+ '[' -z 'automation

html
icons
items
persistence
rules
scripts
services
sitemaps
sounds
things
transform' ']'

+ initialize_volume /openhab/userdata /openhab/dist/userdata
+ volume=/openhab/userdata
+ source=/openhab/dist/userdata
++ ls -A /openhab/userdata
+ '[' -z 'backup
config
etc
jsondb
kar
logs
secrets
zigbee' ']'

++ cmp /openhab/userdata/etc/version.properties /openhab/dist/userdata/etc/version.properties

+ '[' '!' -z ']'

+ chown -R openhab:openhab /openhab

+ sync

+ '[' -d /etc/cont-init.d ']'

+ sync

+ '[' false == false ']'

++ IFS=' '

++ echo gosu openhab tini -s ./start.sh

+ '[' 'gosu openhab tini -s ./start.sh' == 'su-exec openhab tini -s ./start.sh' ']'

+ exec gosu openhab tini -s ./start.sh

/entrypoint: line 119: exec: gosu: not found

+ IFS='

	'

++ find /usr/lib/jvm -mindepth 1 -maxdepth 1 -type d

+ export JAVA_HOME=/usr/lib/jvm/temurin-21-jre-amd64

+ JAVA_HOME=/usr/lib/jvm/temurin-21-jre-amd64

Configuring Java unlimited strength cryptography policy...

+ '[' unlimited = unlimited ']'

+ echo 'Configuring Java unlimited strength cryptography policy...'

+ sed -i 's/^crypto.policy=limited/crypto.policy=unlimited/' /usr/lib/jvm/temurin-21-jre-amd64/conf/security/java.security

+ capsh --print

+ grep -E Current:.+,cap_net_admin,cap_net_raw,.+

+ rm -f '/var/lock/LCK..*'

+ rm -f /openhab/userdata/tmp/instances/instance.properties

Starting with openhab user id: 998 and group id: 997

+ NEW_USER_ID=998

+ NEW_GROUP_ID=997

+ echo 'Starting with openhab user id: 998 and group id: 997'

+ id -u openhab

+ initialize_volume /openhab/conf /openhab/dist/conf

+ volume=/openhab/conf

+ source=/openhab/dist/conf

++ ls -A /openhab/conf

+ '[' -z 'automation

html
icons
items
persistence
rules
scripts
services
sitemaps
sounds
things
transform' ']'

+ initialize_volume /openhab/userdata /openhab/dist/userdata

+ volume=/openhab/userdata

+ source=/openhab/dist/userdata

++ ls -A /openhab/userdata

+ '[' -z 'backup

config
etc
jsondb
kar
logs
secrets
zigbee' ']'

++ cmp /openhab/userdata/etc/version.properties /openhab/dist/userdata/etc/version.properties

+ '[' '!' -z ']'

+ chown -R openhab:openhab /openhab

+ sync

+ '[' -d /etc/cont-init.d ']'

+ sync

+ '[' false == false ']'

++ IFS=' '

++ echo gosu openhab tini -s ./start.sh

+ '[' 'gosu openhab tini -s ./start.sh' == 'su-exec openhab tini -s ./start.sh' ']'

+ exec gosu openhab tini -s ./start.sh

/entrypoint: line 119: exec: gosu: not found