Am on OH 5.2.0-SNAPSHOT #5369. Use the integrated Shelly binding and gained now a flood of error messages:
[ERROR] [fornium.elements.util.SerialExecutor] - unexpected error occurred:
java.lang.NoSuchMethodError: 'java.lang.String org.eclipse.californium.core.coap.Option.getStringValue()'
at org.openhab.binding.shelly.internal.api1.Shelly1CoapHandler.processResponse(Shelly1CoapHandler.java:229)
at org.openhab.binding.shelly.internal.api1.Shelly1CoapServer.lambda$0(Shelly1CoapServer.java:110)
at java.base/java.util.concurrent.ConcurrentHashMap$KeySetView.forEach(ConcurrentHashMap.java:4709)
at org.openhab.binding.shelly.internal.api1.Shelly1CoapServer.processResponse(Shelly1CoapServer.java:110)
at org.openhab.binding.shelly.internal.api1.Shelly1CoapServer$ShellyStatusListener.handleRequest(Shelly1CoapServer.java:76)
at org.eclipse.californium.core.server.ServerMessageDeliverer.deliverRequest(ServerMessageDeliverer.java:121)
at org.eclipse.californium.core.network.stack.BaseCoapStack$StackTopAdapter.receiveRequest(BaseCoapStack.java:204)
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveRequest(AbstractLayer.java:80)
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveRequest(AbstractLayer.java:80)
at org.eclipse.californium.core.network.stack.BlockwiseLayer.receiveRequest(BlockwiseLayer.java:525)
at org.eclipse.californium.core.network.stack.ReliabilityLayer.receiveRequest(ReliabilityLayer.java:309)
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveRequest(AbstractLayer.java:80)
at org.eclipse.californium.core.network.stack.BaseCoapStack.receiveRequest(BaseCoapStack.java:126)
at org.eclipse.californium.core.network.CoapEndpoint$1.receiveRequest(CoapEndpoint.java:312)
at org.eclipse.californium.core.network.UdpMatcher$2.run(UdpMatcher.java:297)
at org.eclipse.californium.elements.util.SerialExecutor.run(SerialExecutor.java:323)
at org.eclipse.californium.elements.util.SerialExecutor.lambda$scheduleNextJob$0(SerialExecutor.java:300)
at org.eclipse.californium.core.network.CoapEndpoint$6.run(CoapEndpoint.java:1363)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Observed that the Californium version is now 4.0.0 M6. In my last setup with OH 5.2.0-SNAPSHOT #5309 it was Californium 4.0.0 M2. Assume that the Shelly binding didn’t change for both setups.
The updated Californium version deprecated some methods that the binding used, and some guesswork was involved when trying to find replacement ways to do those things.
Clearly, this didn’t work, and you can’t really verify/debug this without having devices that lets you test. Thus, as of now, those devices won’t work until the proper replacement methods have been found. I think @markus7017, which have devices to test, is our only hope to figure this out.
It would be helpful if anybody with such a device, running a recent snapshot, could see if this build works (remove .txt extension, it’s just there to get around forum limitations).
I did a very quick test - because I didn’t have a lot of time. I ran 5.2.0-SNAPSHOT - Build #5372.
It looked like I was able to set the brightness level of (the only channel that I use of) my Shelly RGBW 2, but the Snapshot openHAB instance didn’t read what I did with it via the Shelly app or my “real” openHAB instance.
I also tried a BLU Button, but it didn’t respond in the Snapshot. (But maybe there’s interference from my “real” openHAB?) After a restart, the BLU Button did work.
I was able to switch set and read the state of one of my Shelly Plug S Gen3’s.
In the (normal) logs, I only saw this “unusual” entry:
08:39:09.449 [WARN ] [ly.internal.handler.ShellyBaseHandler] - shellyrgbw2-48e729665a1c: CoIoT peer in device settings does not point this to this host
Have successfully tested your .jar with 5.2.0-SNAPSHOT #5369 (same as i used while detecting the issue). All my Shelly devices have been immediately “Online” and the Californium error message disappeared in the openHAB log.
Am not able to update OH to the latest SNAPSHOT today. Get a “missing status code” error message during download for unknown reason.
Edit: to be clear what Shelly devices i have w.r.t. the expression “Shelly V1 handler” (GitHub) and related testing.
Shelly Gen 1 devices: Shelly Plug, Shelly Plug S
Shelly Gen 3 devices: Shelly Plug S Gen 3, Shelly 1 Gen 3 (switch)
Shelly Pro devices: Shelly Pro 3EM (3-phase power meter)
For one specific type, e.g. the Shelly Plug, Shelly uses V1/V2/V3 to label product iterations. This can be a bit confusing. Thus, i hope that my tests are relevant for the issue. Used openHAB as well as the Shelly App cross-wise to switch and read parameters and states.
There has already been merged at fix for trådfri as well (I have no idea why a was chosen to substitute å, the convention is that aa should be used when å isn’t available):
