what did you changed? There shouldn’t be parallel discoveries for a single Shelly
Does somebody have a Wireshark trace? I want to see what’s going on on the network level.
My understanding ist that the devices sends a mDNS anouncement, which is processed by the frameworks, which then calls the binding’s discovery handler.
When will support for version 1.5.0 come? There is a new slat control feature for 2PM gen2 devices. And the new datapoints have to be provided.
Thanks
I also just played with one of my BLU Buttons, giving a lot of commands after each other. That used to cause all kinds of mishaps before, but all works perfectly now!
Follow-up on Plus UNI:
I’ve setup a clean openhab-test docker now, not touch my productive environment.
There I added the DEV 4.3.5 snapshot build and started discovery.
I have two Plus UNIs running in my network to measure the water and gas meter, both running on FW 1.33.
Both were discovered and its things came online, so I added all available equipment.
From what I can tell so far, most items seem to be created as expected.
Only the temperature sensors seem to need some manual interaction or attention. (maybe that is how it worked with other shellies/addons in the past already, so just mentioning here)
Up to five are supported, so I attached five to the gas uni (IDs 100-104). While they are all properly discovered with unique channel names sensors#temperature1-5, the itemname needs to be manually corrected as they all get the name suffix …_Aussentemperatur" without any counter/index (which would cause one temperature item to be created with cumulative temperature of up to five linked channels)
But once fixed these do seem to work.
What I am actually missing completely is a working counter item for the counter, input2 of type “count”:
%plusuniaddress%/rpc/Input.GetConfig?id=2
id : 2
name : Gas
type : count
enable : True
count_rep_thr : 100
freq_window : 1
freq_rep_thr : 10
xcounts : @{expr=x*0.01; unit=qm}
xfreq : @{expr=; unit=}
The channel relay3#input (Switch) is not monitoring the counter either (just mentioning in case that is the plan for the input2 of type count).
As I use the input1 (id=0 on the Shelly) to debounce the reed relay before sending its output to the counter, I can also confirm that relay1#input and relay1#output seem to work correctly.
maybe related, maybe not:
while for the gas uni I at least find an item named …Event_Count_2 (even if it is not counting anything yet), I don’t find any eventcount channel for the water meter.
And one last feedback:
Although afaik the Plus Uni doesn’t have any power meters, the thing has channels for accumulatedWatts, accumulatedWTotal, totalKWH, accumulateReturned
Let me know, what else I can do to support you, or if it makes sense to post logs.
I have a question about thing status.
I think since around openhab 4.1 I see that the thing status is online even in config pending status.
I use some rules to detect for wifi disconnects and if my wife has unplugged a shelly plug. now the status always changes from offline to online while trying reconnecting.
So I don’t know if the device is really offline or just not in wifi.
is it possible to revert this change or is it openhab related?
Because trying to connect is not online 
Greets
@markus7017, I think the code needs another tweak. 
2025-01-27 18:41:14.841 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellyblumotion-b0c7de422d7a: BluEvent received: {"src":"shelly1mini-6055f9985660","params":{"ts":1.73799970728E9,"events":[{"id":1,"ts":1.73799970728E9,"component":"script:1","event":"oh-blu.data","data":{"addr":"b0:c7:de:42:2d:7a","encryption":false,"BTHome_version":2,"pid":255,"Battery":100,"Illuminance":0,"Motion":0,"rssi":-90}}]}}
2025-01-27 18:41:14.841 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellyblumotion-b0c7de422d7a: BLU event oh-blu.data received from address b0:c7:de:42:2d:7a, via gateway shelly1mini-6055f9985660, pid=255
2025-01-27 18:41:14.841 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellyblumotion-b0c7de422d7a: Duplicate packet for PID=255 received, ignore
[...]
2025-01-27 19:44:25.651 [TRACE] [helly.internal.api2.Shelly2RpcSocket] - shellyplus1pm-d4d4da7de204: Inbound Rpc message: {"src":"shellyplus1pm-d4d4da7de204","dst":"oh-shellyplus1pm-d4d4da7de204","method":"NotifyEvent","params":{"ts":1738003465.58,"events":[{"component":"script:1","id":1,"event":"oh-blu.data","data":{"encryption":false,"BTHome_version":2,"pid":0,"Battery":100,"Illuminance":0,"Motion":1,"addr":"b0:c7:de:42:2d:7a","rssi":-74},"ts":1738003465.58}]}}
2025-01-27 19:44:25.651 [TRACE] [ng.shelly.internal.api2.ShellyBluApi] - shellyblumotion-b0c7de422d7a: ShellyEvent received: {"src":"shellyplus1pm-d4d4da7de204","params":{"ts":1.73800346558E9,"events":[{"id":1,"ts":1.73800346558E9,"component":"script:1","event":"oh-blu.data","data":{"addr":"b0:c7:de:42:2d:7a","encryption":false,"BTHome_version":2,"pid":0,"Battery":100,"Illuminance":0,"Motion":1,"rssi":-74}}]}}
2025-01-27 19:44:25.651 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellyblumotion-b0c7de422d7a: Watchdog restarted (expires in 43260 sec)
2025-01-27 19:44:25.651 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellyblumotion-b0c7de422d7a: BluEvent received: {"src":"shellyplus1pm-d4d4da7de204","params":{"ts":1.73800346558E9,"events":[{"id":1,"ts":1.73800346558E9,"component":"script:1","event":"oh-blu.data","data":{"addr":"b0:c7:de:42:2d:7a","encryption":false,"BTHome_version":2,"pid":0,"Battery":100,"Illuminance":0,"Motion":1,"rssi":-74}}]}}
2025-01-27 19:44:25.651 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellyblumotion-b0c7de422d7a: BLU event oh-blu.data received from address b0:c7:de:42:2d:7a, via gateway shellyplus1pm-d4d4da7de204, pid=0
2025-01-27 19:44:25.652 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellyblumotion-b0c7de422d7a: Duplicate packet for PID=0 received, ignore
Since 0 < 255, the packet was ignored. The item indeed didn’t switch to ON.
So I think, after a packet has been fully processed, we need something like:
if (last_pid == 255) {
last_pid = -1
}
Or something similar?
(Any idea how I can reset the count in the binding? Because the current situation is that the motion isn’t detected, so the light in the room doesn’t turn on… :))
Edit:
Maybe (in order to account for packets that may be missed for whatever reason), it’s a better idea to put this right before any of the existing (relevant) code:
if (last_pid - pid > 50) {
last_pid = pid - 1
}
(Or another threshold than 50.)
Hi,
i rewrote the discovery for APIv2 from RPC to “classic” http request. Exactly how it described in https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Shelly#http-endpoint-shelly. As far i got from debugging, discovery alone via RPC runs smoothly. Thing handler alone runs smoothly. But, if the thing handler is already online, then the discovery will close already open RPC channel for this thing handler. And the thing is forced to reconnect. As far number of channels is limited to 6 (https://shelly-api-docs.shelly.cloud/gen2/General/RPCChannels), this causes a kind of “denial of service” attack on Shelly, which force Gen3 devices to reboot.
BTW: My “hacked” version runs now round about 1.5 weeks without any issues on my local environment:
Surprisingly, Gen2 devices have much more protocol messages, as Gen3 ones.
Greetings,
Alexander
Do you see when the pid wraps to 0 - at 255 or 65535?
In fact the processed pid must be > the last one
There is only one special case when pid wraps to 0, which in the current version breaks the logic. So if I know when it wraps (byte size vs. int size) I could to a special handling for pid 0 (if pid == 0 && lastPid == 255 → process)
My feeling is that this fixes the symptom, but doesn’t fixes. Pulling the device information by HTTP GET vs. POST is easy to implement, but the question is why so many mDNS discoveries are coming in.
I didn’t saw that. This means that every received background mdns discovery causes a Thing Offline?
I assume that ‘wrapping’ means something like ‘restarting from 0’? In any case, after PID 255 came PID 0, which didn’t seem unreasonable to me. (I took out a lot of the log, because it was irrelevant to the motion sensor I focused on.)
But then it occurred to me that it’s also possible that packets 255, 0 and 1 go missing (because of whatever reason), and then the new PID would be 2, and the most recently logged PID 254. Also in that case, packet 2 should be taken into account. Hence my second idea, with the threshold. Also, if the new PID is 50 or more lower than the last recorded, the chances are bigger that there has been a ‘wrap-up’, rather than this is an old packet, I would think.
I temporarily went back to the previous snapshot version, but now I get this during openHAB startup:
15:45:15.636 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.shelly-4.3.5-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [248]
Unresolved requirement: Import-Package: org.eclipse.californium.core; version="[2.7.0,3.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.4]
I then reinstalled the latest version (with the packet wrapping problem), that didn’t have that error. Any idea what the issue here is/was?
You need to install coap services
openhab> feature:list | grep -i coap
openhab-core-io-transport-coap │ 4.3.2 │ │ Started │ distro-4.3.2 │
openhab-transport-coap │ 4.3.2 │ │ Started │ distro-4.3.2 │ CoAP Transport
openhab.tp-coap │ 4.3.2 │ │ Started │ distro-4.3.2 │ Californium CoAP library
Also, I’ve got the add-on store TRÅDFRI Binding installed…
What is the output of
bundle:list | grep Californium
In worst case try installing coap services anyway. Either by console or by removing&reinstalling Tradri binding to make sure, all components are added.
Furthermore check permission rights of the shelly .jar file in the addons folder.
openhab> bundle:list | grep Californium
280 │ Active │ 80 │ 2.7.4 │ Californium (Cf) Core
281 │ Active │ 80 │ 2.7.4 │ Californium (Cf) Element Connector
282 │ Active │ 80 │ 2.7.4 │ Californium (Cf) OSGi
erik@MinipcLG2:/usr/share/openhab/addons$ ls -pal
totaal 768
drwxr-xr-x 2 openhab openhab 4096 jan 29 15:49 ./
drwxr-xr-x 4 openhab openhab 4096 jan 13 06:07 ../
-rw-r--r-- 1 root root 588349 jan 29 15:49 org.openhab.binding.shelly-4.3.5-SNAPSHOT-zonderoplossingBLU.jar
-rw-r--r-- 1 root root 182887 jan 25 12:43 org.openhab.binding.unifiprotect-4.0.0-latest.jar
-rw-r--r-- 1 openhab openhab 70 jan 12 22:13 README
Same permissions as always, and the binding does work. It just gave an error at startup…
Hi developers,
Is the Shelly Pro Dual Cover / Shutter PM in any way supported by the recent binding? I don’t seem to be able to find any reference to it in the documentation, so that makes me guessing the device is not supported. Is it gonna be supported in the future, are there any plans for that? Thanx.
Best regards,
Jesse
Hi, no it’s not, but on the list
1 Like
@markus7017, I’m not mistaken that the ‘wrap-up’ problem is not fixed in the latest jar, right? (To avoid waiting for something that’s there already :))
Ok, thanx Markus!
Looking foreward to that.
If you need any help testing by that time, I’ll gladly participate.
Not yet, I‘m thinking about a proper logic
1 Like