This is not a real issue but only a warning that can be ignored or removed by setting log level to error. It does not harm, as all my 43 Shelly devices work as expected.
1 Like
Actually changing absolute color temperature with hue does not work any more:
Number HueBadDeckenlichtColorTemperatureAbs "Farbtemperatur" <light> (gBadezimmerDeckenlicht) ["Point","None"] {channel="hue:0220:xxx:bad_deckenlicht:color_temperature_abs", listWidget="oh-slider-item"[min=2200,max=6400,step=100, scale=true,scaleSteps=7, releaseOnly=true,label=true]}
Warning from log with no changes on the physical light itself:
2022-12-19 19:54:38.078 [WARN ] [hue.internal.handler.HueLightHandler] - Command sent to an unknown channel id: hue:0210:xxx:esszimmer_esstisch_unten:color_temperature_abs
First of all: Thanks to all involved in the 3.4 release! For now everything seems to work smoothly. 
Just two observations, not sure if I’m doing something wrong, but after upgrading from 3.3 to 3.4 (in a Docker enviroment), even after cleaning userdata/tmp/ and userdata/cache/ I temporarily got two types of errors, and had to reboot multiple times / had to clear the cache twice to get things running again.
- Things from all sorts of bindings remained offline with the error message
HANDLER_MISSING_ERROR. Probably related to the following log entry:
2022-12-19 19:44:14.610 [WARN ] [core.thing.internal.ThingManagerImpl] - Cannot unregister handler. No handler factory for thing 'mqtt:topic:7519737e0f:Vindriktning' found. - Rules which used to work great now producing errors in the log
2022-12-19 19:44:25.020 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule 'startup_enable_rules': Fail to execute action: 2
2022-12-19 19:44:29.372 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - Error while creating ScriptEngine
java.lang.IllegalStateException: Multi threaded access requested by thread Thread[OH-rule-startup_reconnect_CCU2-1,5,main] but is not allowed for language(s) js.
at com.oracle.truffle.polyglot.PolyglotEngineException.illegalState(PolyglotEngineException.java:129) ~[?:?]
at com.oracle.truffle.polyglot.PolyglotContextImpl.throwDeniedThreadAccess(PolyglotContextImpl.java:1034) ~[?:?]
at com.oracle.truffle.polyglot.PolyglotLanguageContext.checkThreadAccess(PolyglotLanguageContext.java:303) ~[?:?]
at com.oracle.truffle.polyglot.PolyglotLanguageContext.ensureCreated(PolyglotLanguageContext.java:581) ~[?:?]
at com.oracle.truffle.polyglot.PolyglotLanguageContext.ensureInitialized(PolyglotLanguageContext.java:670) ~[?:?]
at com.oracle.truffle.polyglot.PolyglotContextImpl.eval(PolyglotContextImpl.java:1294) ~[?:?]
at com.oracle.truffle.polyglot.PolyglotContextDispatch.eval(PolyglotContextDispatch.java:63) ~[?:?]
at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?]
at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.evalInternal(GraalJSScriptEngine.java:376) ~[?:?]
at com.oracle.truffle.js.scriptengine.GraalJSBindings.initGlobal(GraalJSBindings.java:96) ~[?:?]
at com.oracle.truffle.js.scriptengine.GraalJSBindings.initContext(GraalJSBindings.java:92) ~[?:?]
at com.oracle.truffle.js.scriptengine.GraalJSBindings.requireContext(GraalJSBindings.java:86) ~[?:?]
at com.oracle.truffle.js.scriptengine.GraalJSBindings.put(GraalJSBindings.java:129) ~[?:?]
at javax.script.SimpleScriptContext.setAttribute(SimpleScriptContext.java:246) ~[java.scripting:?]
at org.openhab.core.automation.module.script.internal.ScriptEngineManagerImpl.addAttributeToScriptContext(ScriptEngineManagerImpl.java:285) ~[bundleFile:?]
at org.openhab.core.automation.module.script.internal.ScriptEngineManagerImpl.createScriptEngine(ScriptEngineManagerImpl.java:156) [bundleFile:?]
at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.createScriptEngine(AbstractScriptModuleHandler.java:110) [bundleFile:?]
at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.getScriptEngine(AbstractScriptModuleHandler.java:106) [bundleFile:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:68) [bundleFile:?]
at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1180) [bundleFile:?]
at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:989) [bundleFile:?]
at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:89) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
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:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
or
2022-12-19 19:44:17.109 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while disposing handler of thing 'mqtt:topic:7519737e0f:schaltstecker_tv': null
java.lang.NullPointerException: null
at org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler.lambda$3(GenericMQTTThingHandler.java:101) ~[?:?]
at java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
at org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler.dispose(GenericMQTTThingHandler.java:101) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor104.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
As said, after multiple restarts, things are running smooth again. But not sure if the multiple restarts / cache cleanings should be necessary.
If I did something wrong, let me know.
Just the version before OH 3.3
Just another observation: I remember some great explanation by @rossko57 and @rlkoshak here and here that using start levels as triggers for rules is not the most reliable thing to do. However, they got the job done on OH 3.3.
After having upgraded to 3.4, everything above Start Level 70 (80 - Things Initialized and 100 - Startup complete) are not working for me anymore (rules just not getting fired).
Anyone else making the same observation? Or just related to my specific setup (have a hypothesis already which I have to test).
start levels in JSR223 rules definitely are not reliable. Tracking issue is at JSR223 scripts and start levels · Issue #3199 · openhab/openhab-core · GitHub
Good to know, so it’s not just my setup, and thanks for the tracking issue. If I can help (e.g. by testing), let me know.
This might be an indication that it is working as designed … version updates can break existing Things, where the binding has added/removed channels for example. Check logs carefully.
1 Like
Just upgraded from 3.3 and none of the bindings seem to get loaded. I initially had the ‘waiting for 15s to laod kar file’ error. and used openhabian-config to reset folder permissions. Now I see in the logs that none of the bindings are getting loaded. Where should I start troubleshooting?
Update: after many restarts, and clearing cache, I’m back up and running … phew!
Another issue I found is using icons.
I have a group icon using a custom png icon:
Group gSonosBad "Sonos" <sonos> (gBadezimmer) ["Speaker"]
This is shown successfully in the items editor in the main UI:
But in the model the icon is not shown:
I have also other items with custom png icons that show the icon successfully in the model as well.
Can you confirm that your system reaches Start Level 100?
If there are broken/uninitialized things it’s possible that it’s still stuck on 70.
You can check the status e.g. with the RestAPI
Sorry that I’m so late in contacting you about the Shellys, but I was sick.
https://community.openhab.org/t/openhab-3-4-milestone-discussion/138093/161?u=dikay1969
The Shellys work perfectly with OpenHab 3.4 and the items are updated cyclically and permanently.
In the 3.4 Milestone 6, “ECMA Script 2021 Edition 11” no longer worked for me at the same time, maybe that also had an effect on the Shellys. The developers will know. I didn’t try the RC1 again after that.
Hi,
I just upgraded my docker to OH 3.4.
I see issues with the addon “Bose SoundTouch Binding”.
There are no spontaneous events present in events.log.
Does anyone face same issues?
Thanks!
You were both correct: After going to 3.4, Gardena did not connect anymore (Error 403 Forbidden, {"Message":"User is not authorized to access this resource with an explicit deny"}), leading to uninitialized systems and this never reaching Start Level 100.
Interestingly I had to delete the entire application under https://developer.husqvarnagroup.cloud for the connection to the Gardena Smart System Account to work again.
With respect to the new default units:
dust and gas is measured in kg/m³? Is this serious, how can I fix my configuration again?
Kind regards
I am still in 3.3 stable and have the same issue - thank you the fix 
You need to include the unit you want in the item’s state description. If you’re using .items files, you do it like this:
Number:Dimensionless Bedroom_PM25 “Bedroom PM 2.5 [%d ppb]
If you use MainUI, it’s under the item’s metadata:
All my Hue lights are showing “Error:Bridge” . How do you change to https and how do you clean the cache. Thanks for any help.
