Issue with Californium and Shelly binding using OH 5.2.0-SNAPSHOT #5369

1

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.

Any idea @markus7017 and @Nadahar ?

2

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.

3

Iā€™ve built a version of the official (non-dev) binding which a slight tweak here:

org.openhab.binding.shelly-5.2.0-SNAPSHOT.jar.txt (617.2 KB)

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).

4

Thanks for this, will test it early tomorrow morning and come back to you.

5

Couldnā€™t that be a problem for the tradfri binding as it uses californium too? I donā€™t use it but probably many users still have those IKEA devices.

6

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
7

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.

For me, everything looks good.

8

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):