OK, here some answers:
yeah. I was close to send the SD back right away 
Hello!
I’m not sure I understood your post. I’ve done exactly what @Oliver2 suggested, and it works just as he said it should, i.e. no more warning messages in the log.
I have 3 Shelly devices, but I guess it doesn’t matter, since only the bulb is being used via binding. Other devices are connected via MQTT.
Edit: btw, this setting is not binding, but device setting (in bulb’s web interface).
Best regards,
Davor
Hi, just a question, i a support from the Shelly Plus Plug S planned in the near future? At the moment it’s shown as unknown device and therefore cannot control it via openhab, not using MQTT.
yes, I just started to work on Plug-S and Smoke
I updated the DEV builds and added Plus Plug-S and Plus Smoke. See this as primarily, I couldn’t do a lot of testing.
get the 3.4.3-SNAPSHOT or 4.0.0-SNAPSHOT from the myfiles repo
The build implements a new channel meter1…3#resetTotals. You need to delete the thing and re-discover, Switching the channel to ON should clear the totals. Channel should automatically switch back to OFF. Let me know if this works.
3.4.3 snapshot?
3.4.3 or 4.0.0
I sometimes get the error when upgrading etc. Only way I have found to clear the error is to restart the entire openHAB host system.
I only have 4 Shelly devices - checked and all are not using mcast for ColoT peer.
I guess there more than just thsi as causes.
Just upgraded to 3.4.2 and got the same till a restart
You could try the 3.4.3-SNAPSHOT from my myfiles repo, but I doubt this makes no difference.
General: In any case it’s preferable to use peer mode rather than multicast. You need mcast only if the packt should be processed by multiple OH instances. Otherwise, sending the packt directly to the OH host is more efficient. On the other hand all packets received by the binding are processed in the same way: By design their is only 1 packet handler for all things listening to the incoming UDP traffic and then needs to dispatch the packet to the corresponding thing. It checks the source IP agains all things, if this doesn’t work, it checks the device id from the CoAP header. This is the way to filter multicast packet for other hosts . If a thing can be identified it process packet, otherwise ignore it.
Question: Are one or multiple things suspended (UNINITIALIZED)? It’s possible that the framework blocks access to the thing handler when thing is UNINITIALIZED.
Please provide a TRACE log, maybe I could narrow it down to understand, which function causes the problem.
Could somebody please give advise: Are there any specific settings I need to do for Plus devices compared to 1st Gen where we activated CoIoT unicast?
I found the follwing settings:
RPC over UDP
Outbound websocket
I do not see unititislised etc.
I ha already cleared the issue so will have to do the trace logs next time for sure.
I am a little bit lost on installing dev version 3.4.3.
I am currently on OH 3.4.2 and shelly binding released version.
As far as I can see Shelly binding has the following dependencies:
239 │ Active │ 80 │ 0.3.0.v20220506-1020 │ EdDSA-Java
240 │ Active │ 80 │ 2.7.4 │ Californium (Cf) Core
241 │ Active │ 80 │ 2.7.4 │ Californium (Cf) Element Connector
242 │ Active │ 80 │ 2.7.4 │ Californium (Cf) OSGi
243 │ Active │ 80 │ 2.7.4 │ Scandium (Sc) Core
On Markus github site there is californium v2.7.3 available. I remember some problems related to version 2.7.4 and 2.7.5
What is the version which is recommended and how can I install it?
I can also remember a way to install californium from the regular distro but do not find the information anymore.
Thanks
No, you need
Ok, I found one bug. After an OH restart the Coop listener was not initialized when /settings is not initialized (which is the case when device is in sleep mode). This also impacts other Gen1 battery devices like Flood and DW/DW2.
Both builds have been updated, get them from the myfiles repo myfiles/shelly at master · markus7017/myfiles · GitHub
Just me where binding 3.4.3 is not running?
dependencies installed, jar copied, permission set, restarted.
but shelly binding does not appear in ohconsole (bundle:list)
Log set to trace, then copied the jar file:
no entry
Tried to install dev 3.4.2: not working either.
Probably the file watcher is not working correctly?
Does anybody know how I can force an installation?
Did you installed Californium on the OH console?
Weird history:
one the first attempt, transport-coap was installed and I could verify installation (I still see it in the console’s output)
After some restarts (oh and pi) californium disappeared.
Installed it again a minute ago, copied jar file but still NO shelly binding in bundle:list