This means CoAP is not working. Please try to downgrade to 1.7.x, this means CoAP 1
ok[quote=āEagle1887, post:1378, topic:56862ā]
Does anybody have a DUO GU10 running in his OH ? Or am I behind a compatible release ?. My OH is 2.5.4 with shelly Binding 2.5.4
[/quote]
yes, you are way behind. You should at least upgrade to the 2.5.7 Addon pack (I also recommen OH 2.5.5-2) or switch to the DEV build - this is the current development status with lot of improvements, support for new devices etc. I would first start with the latest firmware 1.7.x and if this works go to 1.8.
See links below for the DEV build and How-To install.
Latest DEV build - README - Installation - Firmware Index - Firmware Archive - API Doc
Downgradedā¦still the same behaviourā¦ 
I could only say
- it works in my setup
- I donāt see the Coap updates in your setup
Whatās about the network layer. Is your OH and ix3 on the same local subnet? Are you using VPN?
Iāve updated the DEV build
- Additional sensor IDs for Shelly EM/EM3 added
- Auto-Switching from CoIoT 1 to CoIoT 2, e.g. on a firmware upgrade while OH is running
- Thing goes to state UNKNOWN when device was restarted and a new initialization is triggered - make sure status is refreshed and synced with the device
- Donāt try to initialize Thing when in state DISABLED
I did some testing with the DEV build today and I do not see any problems with firmware 1.8. Everything looks alright. This includes Shelly 1, 1PM, Plug S and EM.
@markus7017
Had following situation with Shelly Button1 and Unifiy UniFi AP-AC-Pro Version 4.3.20.11298
- with Shelly FW < 1.7 and productive latest Shelly binding
- when powered via USB (a)
- when on battery (b)
- with Shelly FW 1.8.0 and 2.5.8 snapshot from 19.8.
- on bat and on USB close to same <3 second response time (a)
What is and was strange, that when powered via battery the message is always send twice by the button.
This was a problem and I fixed it 1-2 weeks ago.
I doubt we donāt have the latest DEV build active, make sure the Shelly binding is not listed jn PaperUI as installed nor in hundle:list listed twice. Maybe you need to clean the cache.
The 8s problem occurs only when in battery mode. How long does it take until the LED gets green with firmware 1.8? Which board revision. do you have (you see that under device details in the Unify Controller). The device has a sticker on the bottom, what is the production data (first 5 digits)?
Hi guys,
thanks for your great work on the shelly binding. I observed some warnings with the latest build from https://github.com/markus7017/myfiles/tree/master/shelly from 14h agoā¦
See here:
2020-08-20 09:53:01.910 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyplugs-dbf20f: CoIoT Message from /192.168.178.70:5683 (MID=52113): {"G":[[0,9103,1],[0,1101,1],[0,4101,43.26],[0,4103,22649],[0,6102,0],[0,6109,0.00],[0,3104,36.42],[0,3105,97.55],[0,6101,0]]}
2020-08-20 09:53:01.911 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyplugs-dbf20f: CoIoT Sensor data {"G":[[0,9103,1],[0,1101,1],[0,4101,43.26],[0,4103,22649],[0,6102,0],[0,6109,0.00],[0,3104,36.42],[0,3105,97.55],[0,6101,0]]}
2020-08-20 09:53:01.912 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyplugs-dbf20f: CoAP Request was canceled
2020-08-20 09:53:01.913 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyplugs-dbf20f: Device description not yet received, trigger auto-initialization
2020-08-20 09:53:01.926 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyplugs-dbf20f: CoIoT Message from /192.168.178.70:5683 (MID=31016): {"blk":[{"I":1,"D":"relay_0"},{"I":2,"D":"device"}],"sen":[{"I":9103,"T":"EVC","D":"cfgChanged","R":"U16","L":2},{"I":1101,"T":"S","D":"output","R":"0/1","L":1},{"I":4101,"T":"P","D":"power","U":"W","R":["0/2500","-1"],"L":1},{"I":4103,"T":"E","D":"energy","U":"Wmin","R":["U32","-1"],"L":1},{"I":6102,"T":"A","D":"overpower","R":["0/1","-1"],"L":1},{"I":6109,"T":"P","D":"overpowerValue","U":"W","R":["U32","-1"],"L":1},{"I":3104,"T":"T","D":"deviceTemp","U":"C","R":["-40/300","999"],"L":2},{"I":3105,"T":"T","D":"deviceTemp","U":"F","R":["-40/572","999"],"L":2},{"I":6101,"T":"A","D":"overtemp","R":["0/1","-1"],"L":2}]}
2020-08-20 09:53:01.927 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyplugs-dbf20f: CoIoT Device Description for SHPLG-S#DBF20F#2: {"blk":[{"I":1,"D":"relay_0"},{"I":2,"D":"device"}],"sen":[{"I":9103,"T":"EVC","D":"cfgChanged","R":"U16","L":2},{"I":1101,"T":"S","D":"output","R":"0/1","L":1},{"I":4101,"T":"P","D":"power","U":"W","R":["0/2500","-1"],"L":1},{"I":4103,"T":"E","D":"energy","U":"Wmin","R":["U32","-1"],"L":1},{"I":6102,"T":"A","D":"overpower","R":["0/1","-1"],"L":1},{"I":6109,"T":"P","D":"overpowerValue","U":"W","R":["U32","-1"],"L":1},{"I":3104,"T":"T","D":"deviceTemp","U":"C","R":["-40/300","999"],"L":2},{"I":3105,"T":"T","D":"deviceTemp","U":"F","R":["-40/572","999"],"L":2},{"I":6101,"T":"A","D":"overtemp","R":["0/1","-1"],"L":2}]}
2020-08-20 09:53:01.928 [WARN ] [.californium.core.network.UdpMatcher] - error receiving response ACK-2.05 MID=31016, Token=, OptionSet={"Unknown (3332)":0x5348504c472d53234442463230462332}, "{"blk":[{"I":1,"D":"rela".. 623 bytes for Exchange[L19884, complete]
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected a string but was BEGIN_ARRAY at line 1 column 205 path $.sen[2].R
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:224) ~[?:?]
at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41) ~[?:?]
at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:82) ~[?:?]
at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:61) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:888) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:853) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:802) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:774) ~[?:?]
at org.openhab.binding.shelly.internal.coap.ShellyCoapHandler.handleDeviceDescription(ShellyCoapHandler.java:252) ~[?:?]
at org.openhab.binding.shelly.internal.coap.ShellyCoapHandler.processResponse(ShellyCoapHandler.java:216) ~[?:?]
at org.openhab.binding.shelly.internal.coap.ShellyCoapHandler$1.onResponse(ShellyCoapHandler.java:884) ~[?:?]
at org.eclipse.californium.core.coap.Request.setResponse(Request.java:711) ~[bundleFile:?]
at org.eclipse.californium.core.network.EndpointManager$ClientMessageDeliverer.deliverResponse(EndpointManager.java:272) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.BaseCoapStack$StackTopAdapter.receiveResponse(BaseCoapStack.java:210) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:89) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.ExchangeCleanupLayer.receiveResponse(ExchangeCleanupLayer.java:93) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.ObserveLayer.receiveResponse(ObserveLayer.java:150) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.BlockwiseLayer.receiveResponse(BlockwiseLayer.java:676) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.ReliabilityLayer.receiveResponse(ReliabilityLayer.java:305) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:89) ~[bundleFile:?]
at org.eclipse.californium.core.network.stack.BaseCoapStack.receiveResponse(BaseCoapStack.java:139) ~[bundleFile:?]
at org.eclipse.californium.core.network.CoapEndpoint$1.receiveResponse(CoapEndpoint.java:277) ~[bundleFile:?]
at org.eclipse.californium.core.network.UdpMatcher$4.run(UdpMatcher.java:399) [bundleFile:?]
at org.eclipse.californium.elements.util.SerialExecutor$1.run(SerialExecutor.java:276) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_262]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_262]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_262]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_262]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_262]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_262]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_262]
Caused by: java.lang.IllegalStateException: Expected a string but was BEGIN_ARRAY at line 1 column 205 path $.sen[2].R
at com.google.gson.stream.JsonReader.nextString(JsonReader.java:825) ~[?:?]
at com.google.gson.internal.bind.TypeAdapters$16.read(TypeAdapters.java:401) ~[?:?]
at com.google.gson.internal.bind.TypeAdapters$16.read(TypeAdapters.java:389) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220) ~[?:?]
... 32 more
2020-08-20 09:53:02.670 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellyplugs-dbf20f: Channel device#uptime updated with 81905 s (type class org.eclipse.smarthome.core.library.types.QuantityType).
2020-08-20 09:53:02.672 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellyplugs-dbf20f: Channel device#wifiSignal updated with 4 (type class org.eclipse.smarthome.core.library.types.DecimalType).
2020-08-20 09:53:02.673 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellyplugs-dbf20f: Channel meter#currentWatts updated with 43.3 W (type class org.eclipse.smarthome.core.library.types.QuantityType).
Iām on openHAB 2.5.7-1 and have the following Shellyās included: 3x DW2, 1x Plug 2, 1x Flood, 1x Shelly1 with 3x Temp.
Iāve updated all Shelly to latest FW yesterday.
Du you have any idea whats going wrong?
Yes, OH and the shellies are on the same subnet, no VPN. Iāve tried to update again to the latest DEV build and updated the i3 again to 1.8, now Iāve also enabled the TRACE in the log, in the attached one Iāve filtered only the events from the i3ā¦when itās just added from the inbox there are messagges regarding CoAP, for example:
2020-08-20 10:44:46.304 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyix3-a4cf12f46da8: 10 CoAP sensor updates received
But after those I see only HTTP GET requestsā¦
Strange thing: Iāve tried to filter the openhab log for ācoapā and the only rows are the ones when the things are just added, for all the shellies, does this mean that also the other ones are not using CoAP?
i3.log (41.9 KB)
You need to upgrade to binding to the latest DEV build. Make sure to read the READMEbeta! e.g. you need to deinstall the binding in PaperUI before adding the jars to the addon folder.
Latest DEV build - README - Installation - Firmware Index - Firmware Archive - API Doc
Youāll always see HTTP GET / REST calls
- For reading settings
- Performing actions
- Health monitoring
- Fallback for status values not reported by CoAP
In parallel the binding uses CoIoT events. which in fact provides a better user experience, because itās near-realtime. That means
- you could run it without CoIoT
- but you canāt have CoIoT without REST
You could use the thing id as a filter for logfile processing: grep āshellyix3-a4cf12f46da8ā openhab.log
this brings up all device specific messages, āonly globalā, not thing specific get ālostā, e.g. general exceptions etc., but it makes device specific analysis much easier.
I look into your log, I see
- a successful thing initialization
- successful CoAP discovery
- 1 CoAP message and update processing
- but only once
- and they REST updates with S or SSS
Thatās wired. I check my setup again and it works.
I see CoAP updates with no updates in idle mode and
CoAP updates when I press the button
resulting in channel updates and trigger.
Iām running firmware 0200812-092428/v1.8.0@8acf41b0 on the device.
Hello Markus.
Iāve been using your dev build since I included my first Shelly some weeks ago - I never used the binding via Paper UI, it was always your jars.
The warning started with the latest build and I donāt have any idea where it comes from. The warning seem to appear on every update of the plug.
UPDATE; I missed to install the other two jars - seems to be fine now. Sorry and thank you for the support
Hi, is it foreseeable until when the develop status will flow back into the regular add-on and be generally available? For the Shelly Door Window 2 there is only firmware 1.8ā¦
Thanks for your great work!!!
The PR is opened, but progressing slow. I would expect to be merged in 2.5.9 (4-6 weeks from now)
Just got feedback from @igi, who ran a bigger QA test. Beside some translation issues everything looks good so far, incl support for 1.8. Test for ActionnURLs is open. Just one user us having problems with the i3 I canāt figure out.
1 Like
Hi
I use a button1 with the newest firmware (v1.8.0/20200812-091606(8acf41b0) with openHAB 2.5.8 Release Build and the org.openhab.binding.shelly-2.5.8-SNAPSHOT.jar (downloaded 23.08.2020).
When I click my button the event is send several times (normaly 3-4 times in the next seconds).
Is there a possibility that I receive the event once?
Thanks for your work. I love the shelly binding and it works very well.
We just opened a ticket with Alterco. The device should only send a CoAP message when something changes, in this case a button click, but we are seeing that at least the H&T and obviously the button are sending more the one message.
Plese provide a TRACE log (not just DEBUG) - maybe as PM to me. Iāll have a look, maybe itās a problem in the binding. Mine works fine with 1.8, but who knows.
Maybe a stupid question, but Iāve noticed in the things properties those two āfalseā under coiotAutoEnable and coiotAutoRrfesh, could they be related in some way with the issue?
In the thing configuration the Events are correctly enabled.
I updated the DEV build
- fix: Process relay events correctly when Action URLs are activated
- fix: trigger wakeup events only once (e.g. donāt send multiple BUTTON triggers)
- typo fixed
fyi: @igi completed the final QA test
- Firmware 1.7, 1.8 (focus on 1.8, some testing with 1.6)
- Almost all Devices
- Proper creation of dynamic channels (e.g. power meter, battery status, ext temp sensors etc.),
also for existing Devices (if they were not released and re-discovered) - Coap and Non-Coap
- Status updates via CoAP in general
- Auto-switch from CoAP 1 to 2 after firmware upgrade while OH is running
- Re-init of a device after firmware upgrade while OH is running
- Re-Init on detection of device restart
- Detection of battery devices after OH restart
- Proper function after a non-battery devices comes back (e.g. after network disconnect)
- new control functions (e.g. controlling the LED disabled setting)
- config refresh when config changed in the Shelly App (1.8 with CoAP only)
- verification of translations
- adding configured Device-Name on Discovery (1.8 only, see Shelly App)
- avoid Exception on Discovery when handler is called for a non-Shelly Device
- Log scan for exceptions, āunknown valuesā etc
Test went well, brought up only some missing translations and issues.
Update on delayed CoAP messages:
Alterco provided a beta release and what Iāve tested this looks very promising with delays < 1sec (mostly < 500ms, sometimes 40ms)
Hi Markus,
thanks for your efforts in the Shelly binding.
Which FW version did you test, lately?
I assume 1.8.2?
I tested the version from http://archive.shelly-faq.de/version/v1.8.2/SHSW-1.zip without resulting in acceptable delays / GUI reactions on toggling buttons.
openHAB core was on 2.5.9 snapshot with your latest Shelly Binding DEV build.
What is for the moment the best / fastest option for an production system?
Disabling CoIoT/CoAP and using Action Callback URLs instead?