Seeing many issues related to openHAB 4.0 migration, sometimes duplicated, I thought maybe it might help to create an overview of the different issues and their current status. Therefore I have compiled this initial FAQ based on observations.
Before upgrading, please read:
Index
- openHABian upgrade failing due to Java upgrade
- TransformationService of type ‘JS’ is unavailable
- ScriptEngine for language ‘application/javascript’ not found
- Blockly rules not working: PolyglotException: ReferenceError
- High CPU usage
- Channel types or config descriptions are missing in the respective registry
- Rule does not trigger on Astro event
- Shelly: Incompatible units
- EnOcean: Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed
- Deconz Conbee II stick not detected on Debian bullseye
- Repeated ItemStateUpdatedEvent in logs
- Restarts/sluggishness
- Massive amount of logs/restart loop
- You are running a too old version of your Operating System
- Textual configuration files are not reloading
Issues
openHABian upgrade failing due to Java upgrade
Symptom
Upgrade to 4.0 using openHABian doesn’t seem to work at all.
Debug level output will show complaints about unresolvable package dependencies on libc
and other packages.
Mitigation
See openHABian 1.8 release - #2 by mstormi
Reinstalling openHABian on Raspberry
Thanks to @mstormi for these instructions:
- Get a new SD card (preferrably an “Endurance” labelled one) and keep the old one as your fallback
- Run option 50 to create an OH config backup and copy it to some box of yours
- Download and flash openHABian 1.8
- Put the SD in your Windows system and open the first (only) partition. Edit
openhabian.conf
and setclonebranch=openHAB3
. That should result in (latest) OH3 being installed. - Also put your backup zip file there, name it
initial.zip
. That’ll auto-import the config during install. - Now put the SD in the Raspi and turn it on. Let openHABian do its install magic.
- When finally done, login and run
openhabian-config
menu option 03 to upgrade to OH4
References
TransformationService of type ‘JS’ is unavailable
Symptom
Warnings like these:
2023-07-29 01:28:17.161 [WARN ] [s.internal.SingleValueTransformation] - couldn’t transform response because transformationService of type ‘JS’ is unavailable
Mitigation
Install JavaScript Scripting add-on.
References
- [OH4 StartUp WARN] The transformation add-on 'javascript' does not exist - ignoring it
- Couldn't transform value in label / MAP - #13 by hermann59
ScriptEngine for language ‘application/javascript’ not found
Symptom
Error like this logged:
[ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language ‘application/javascript’ could not be found for identifier: 6ee73f65-d669-421f-ae82-a239f467555b
Mitigation
Install JavaScript Scripting add-on.
References
Blockly rules not working: PolyglotException: ReferenceError
Symptom
Blocky rules are not working and errors like this logged:
2023-07-25 00:36:06.420 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: ReferenceError: "itemRegistry" is not defined
at <js>.:program(<eval>:1) ~[?:?]
at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?]
at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?]
at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:426) ~[?:?]
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262) ~[java.scripting:?]
at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptConditionHandler.isSatisfied(ScriptConditionHandler.java:54) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.calculateConditions(RuleEngineImpl.java:1158) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:995) ~[?:?]
at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:87) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
Mitigation
See https://www.openhab.org/docs/configuration/blockly/#openhab-3-openhab-4-migration
References
High CPU usage
Symptom
High CPU usage after upgrading to 4.0.1, typically caused by one of these threads:
- upnp-main-queue
- safeCall-queue
Example
top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11216 openhab 20 0 1318172 472096 4528 S 256.2 47.4 4740:45 java
top -H -p 11216:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25409 openhab 20 0 1318172 471856 4528 R 99.7 47.4 93:36.83 upnp-main-queue
30546 openhab 20 0 1318172 471856 4528 R 99.7 47.4 15:19.09 safeCall-queue
Mitigation
Upgrade to 4.0.2
Background
This is a bug in openjdk 17. A bugfix has been made for the next openjdk 22 release:
It is yet unknown if this will be backported to jdk 17 - a request has been made:
but a contributor would need to provide such a backport.
Therefore a work-around has been made in openHA providing the Java 11 version of the class.
References
- Upgrade OH 4.0.0 -> 4.0.1 high cpu usage
- Consistent 100% CPU use of safeCall-queue thread - #27 by Andrew_Rowe
- https://bugs.openjdk.org/browse/JDK-8301341
Channel types or config descriptions are missing in the respective registry
Symptom
Warnings like these:
2023-07-29 10:19:24.234 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'smartmeter:meter:87e2db31cf' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
Mitigation
- Try to restart openHAB.
- If it still happens, try to recreate the thing.
- If it still happens, please create an issue in the openhab add-ons repository.
References
- Error for configuration after upgrade to OH4 (Failed to normalize)
- Shelly Binding - #3344 by Andy_Co
Rule does not trigger on Astro event
Symptom
Rule doesn’t trigger and channel cannot be selected in the UI.
Mitigation
This is a regression, and a fix is not available yet. It can be tracked here:
As a work-around, file-based rules can be used since they are not impacted.
Another work around is to link the equivalent State Channel to a DateTime
Item and use the Time is <Item>
trigger for the rule. That works in the UI as well as file based.
References
Shelly: Incompatible units
Symptom
Warnings logged: cannot convert from “W” to “kWh”
Mitigation
There’s a bug in binding, please wait for a fix. It can be tracked here:
References
EnOcean: Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed
Symptom
Binding doesn’t work, or at least doesn’t work reliably.
Logged:
2023-07-29 12:39:13.511 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-07-29 12:39:13.513 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-07-29 12:39:13.513 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyAMA0
2023-07-29 12:39:13.514 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
and/or:
2023-07-29 12:55:05.365 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2023-07-29 12:55:05.375 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be found
2023-07-29 12:56:05.380 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2023-07-29 12:56:05.388 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be found
2023-07-29 12:57:05.392 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2023-07-29 12:57:05.402 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be found
Mitigation
Upgrade to 4.0.2.
References
Deconz Conbee II stick not detected on Debian bullseye
Symptom
The conbee II isn’t detected in the Gateway.
As I (@stefan.hoehn) have a feeling that a lot of us are using the at Zigbee stick, there is actually a pitfall on the latest bullseye that breaks it finding the stick.
Mitigation
Patch like /usr/lib/udev/rules.d described here and change via
sudo nano /lib/systemd/system/deconz.service
the following line by adding your device at which the stick is connected to
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8070 --ws-port=8070 --dev=/dev/ttyACM0
Repeated ItemStateUpdatedEvent in logs
Symptom
Repeated logs of updated items without any value change:
2023-07-24 23:37:30.240 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:31.328 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:32.316 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:33.419 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:34.466 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:35.649 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
Mitigation
Upgrade to 4.0.2
See also After upgrade to Openhab 4: a lot of "Item updated to" in the log - #3 by MathiasVDA
Restarts/sluggishness
Symptom
From time to time openHAB becomes slow and then ultimately restarts.
Mitigation
openHAB 4.0 and/or Java 17 seems to be using quite some more memory, and long-term openHABian users should adjust parameters as explained here:
Massive amount of logs/restart loop
Symptom
A huge amount of errors are logged and the system may restart over and over.
Example:
2023-08-16 15:42:28.512 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-modbus, openhab-binding-evcc, openhab-binding-mail, openhab-misc-openhabcloud, openhab-binding-smaenergymeter, openhab-automation-jsscripting, openhab-binding-shelly, openhab-persistence-rrd4j, openhab-transformation-map, openhab-ui-basic, openhab-binding-ipcamera, openhab-binding-ntp, openhab-binding-openweathermap, openhab-binding-astro, openhab-binding-homematic': Error:
Error downloading mvn:org.jupnp/org.jupnp/2.7.0
Mitigation
Make sure that no bindings for previous versions of openHAB (3.x) are installed, i.e. .kar/.jar files placed in the addons folder or installed via the Marketplace.
See Endless loop during start of OH4.0.2 service after upgrade from OH4.0.1
You are running a too old version of your Operating System
Symptom
Message from openHABian: “You are running a too old version of your Operating System”.
Mitigation
See openHABian 1.8 release - #2 by mstormi
Textual configuration files are not reloading
Symptom
Textual configuration files like .things and .sitemaps are not reloading after changes.
Mitigation
There is currently no confirmed fix, but two related pull requests have so far been merged into main (4.1):
References
Forum reports:
- Changes in thing config files not populated in OH4
- Bug since OH4: Why are the default.sitemap and *.things files not loaded on startup? (empty sitemap list)
- 4.0.1: Cannot delete or modify things that are provisioned from file
- .things (textual config) sometimes not available after reboot (OH4.x)
GitHub issues: