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.
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.
Put the SD in your Windows system and open the first (only) partition. Edit openhabian.conf and set clonebranch=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
2023-07-29 01:28:17.161 [WARN ] [s.internal.SingleValueTransformation] - couldn’t transform response because transformationService of type ‘JS’ is unavailable
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) ~[?:?]
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.
Rule doesn’t trigger and channel cannot be selected in the UI.
Mitigation
Upgrade to 4.0.3.
For previous versions:
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
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.
Textual configuration files like .things and .sitemaps are not reloading after changes.
Mitigation
These fixes went into 4.0.3:
But there are still issues reported even after these fixes. This pull request contains a fix ready for testing and review than can hopefully be included in 4.0.4:
Do you know how/when this was introduced? For example, if already running openHABian 1.8 and then upgrading to 4.0, will the suddenly trigger this? Or was it a package upgrade that caused this to happen some time ago when already running openHABian 1.8?
Maybe I wasn’t too clear above: It is NOT an openHAB issue it is Debian bug where someone introduced a wrong symlink behavior as far as I understand. It seems it was fixed in April but I also have the feeling that this is still the part of the openhaben bullseye version - at least I still have the problem.
See the details linked about it here
So, It isn’t an openHAB issue per se but rather part of the bullseye that comes with openhabian. Maybe someone has an idea how we can update bullseye to a point where we know this is not an issue anymore (I currently don’t have the time to do so and try it out as I am happy that my complex OH4 production setup finally runs almost everything like before).
Jacob, do we want to add it into your great list above? How about adding an index above that description that gives a quick overview on all topics like
Upgrade to 4.0 using openHABian doesn’t seem to work at all.
TransformationService of type ‘JS’ is unavailable
ScriptEngine for language ‘application/javascript’ not found
Blocky 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.
openJDK17 fails due top dependencies when you are still in Theo Buster Release of Debian or openHABian
Deconz Conbee II stick not detected on Debian bullseye
I had this issue with 4.0.0 M1 as soon as I upgraded way back in April first reported here
On several occasions I thought I had tracked it down but it is still a problem for me. (happen yesterday) currently running 4.0.0 snapshot 3460
Memory usage
The Java upgrade seems to be using quite some more memory than before and memory reserves are tight particularly if you are on on Raspberry. See corresponding question in the FAQ .
But I couldn’t find the corresponding question here…
BTW: I set
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.
I was reading the PR’s, but reading does not mean understanding - thats too complex for my simple mind
Is there a way to check those EventTrigger-Issue for simple “end-users”?
Im running OH with 442 things, 1839 items, 322 rules (all in DSL)… I’ll have a horrible night, thinking of maybe checking everything or maybe updating a massive portion of my configuration…
