This topic can be used to discuss problems/experiences/questions on the openHAB 3.4 release as announced in this topic.
Hi,
anything known about breaks with unifi, hue or lgwebos bindings? All three stopped working with communication error after updating. I use raspberry pi 4 with latest openhabian.
Best
After upgrade to Version 3.4 the ebus binding ist not installed and I can not
install the binding from the market place (Installation of add-on marketplace:88770 failed)
Hue uses https as standard config now (change when updating from 3.3 at least). Maybe you switch it back to http or make the changes to comply with https requests. I did another clean-cache before i could see the options of the Hue bridge thing. Maybe restarting oh is enough.
I had to reinstall fronttail, as no log was shown at …:8080/ after updating to 3.4
1 Like
cleaning cache and explicitly changing to https solved the hue issue. lgwebos is solved by turning TV on and off (no idea why this helps, but did the trick). Still unifi is not working, see also here.
after the upgrade, I get the following error:
==> /var/log/openhab/openhab.log <==
2022-12-19 17:12:43.210 [WARN ] [ssistant.internal.DiscoverComponents] - HomeAssistant discover error: thing update component type is unsupported: update
2022-12-19 17:12:43.214 [WARN ] [ssistant.internal.DiscoverComponents] - HomeAssistant discover error: thing power_on_behavior component type is unsupported: select
2022-12-19 17:12:45.318 [WARN ] [ssistant.internal.DiscoverComponents] - HomeAssistant discover error: thing update component type is unsupported: update
and all my ha discovered devices has a problem.
Not currently using any Shelly equipment (but I have some in stock to test, hence me stating this) but the users in the Shelly thread have been facing issues with the last couple updates (including just now with the latest one):
This is probably because the tv thing is offline too, when you turn off the tv regularly.
openHAB May have needed a dedicated status update from the device. 
Makes sense (somehow) 
Found a bug with the android binding and nvidia shield
08:59:17.585 [DEBUG] [dge.internal.AndroidDebugBridgeDevice] - 192.168.50.173 - shell:getprop ro.config.media_vol_steps && sleep 0.3
08:59:17.912 [WARN ] [ge.internal.AndroidDebugBridgeHandler] - Unable to refresh media volume: Unable to get device property 'ro.config.media_vol_steps'
08:59:17.913 [DEBUG] [dge.internal.AndroidDebugBridgeDevice] - 192.168.50.173 - shell:dumpsys window displays | grep mFocusedApp
08:59:17.941 [DEBUG] [ge.internal.AndroidDebugBridgeHandler] - media stream config not found for com.spotify.tv.android
08:59:17.942 [DEBUG] [dge.internal.AndroidDebugBridgeDevice] - 192.168.50.173 - shell:dumpsys media_session | grep -A 100 'Sessions Stack' | grep -A 50 com.spotify.tv.android
I tested on both an existing install and a new install.
The binding was updated to fix volume control on devices running android 11 or higher and part of that was adding a check for a build property ro.config.media_vol_steps and use that to set the max volume level . If the check for that prop comes back empty it is suppose to fallback to what is set as deviceMaxLevel in the binding config options but i re compiled the binding with some added logging and it never makes it to that point in the code
if (maxVolumeLevel == null) {
try {
maxVolumeLevel = Integer.parseInt(getDeviceProp("ro.config.media_vol_steps"));
this.maxVolumeLevel = maxVolumeLevel;
logger.info("2 MaxVolumeLevel is now", maxVolumeLevel);
} catch (NumberFormatException ignored) {
logger.info("Max volume level not available, using 'deviceMaxVolume' config");
maxVolumeLevel = deviceMaxVolume;
}
}
logger.info(" 3 MaxVolumeLevel is", maxVolumeLevel);
logger.info("set MaxVolumeLevel to ", deviceMaxVolume);
return new VolumeInfo(Integer.parseInt(volumeResp.replace("\n", "")), 0, maxVolumeLevel);from what I can tell it never makes it past this line
maxVolumeLevel = Integer.parseInt(getDeviceProp(“ro.config.media_vol_steps”))
I think the problem might be with the code for the
AndroidDebugBridgeDeviceReadException function. instead of knowing how to handle that exception it just bails
Let me know if you guys need more info,
1 Like
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!