Shelly Binding

This has been addressed in the 4.0.0.M1 Thread:

Cheers!

I finally found time to retry again and dependencies are fine. I think the problem was the order of removing the built-in bundle and replacing it with the new one was somewhat not fully correct.
I see the channels and tried this:

Group:Switch:AND(ON,OFF) gShelly3EM_reset "EVU ZĂ€hler zurĂŒcksetzen" (gShelly3EM) ["Switch"]
Switch shelly_reset_L1 "ZĂ€hler L1 zurĂŒcksetzen" (gShelly3EM_reset) { channel="shelly:shellyem3:ee412e8d00:meter1#resetTotals" }
Switch shelly_reset_L2 "ZĂ€hler L2 zurĂŒcksetzen" (gShelly3EM_reset) { channel="shelly:shellyem3:ee412e8d00:meter2#resetTotals" }
Switch shelly_reset_L3 "ZĂ€hler L3 zurĂŒcksetzen" (gShelly3EM_reset) { channel="shelly:shellyem3:ee412e8d00:meter3#resetTotals" }

But neither switching gShelly3EM_reset nor shelly_reset_L1 did something to the totals.

2023-03-14 18:10:17.814 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'shelly_reset_L1' received command ON
2023-03-14 18:10:17.821 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'shelly_reset_L1' predicted to become ON
2023-03-14 18:10:17.827 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shelly_reset_L1' changed from OFF to ON
2023-03-14 18:11:51.901 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'shelly_reset_L1' received command OFF
2023-03-14 18:11:51.907 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'shelly_reset_L1' predicted to become OFF
2023-03-14 18:11:51.912 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shelly_reset_L1' changed from ON to OFF

And counters did not change (neither totalKWH nor returnedKWH.

I guess I need some debugging turned on to see what is happening? What to do?

I added an additional check.

Nevertheless, from experience in the last I could say the Shelly need at least initially a timestamp (after each power cycle). Sometimes I saw strange effects when time was not set (at least with the Gen1 models).

turn on DEBUG mode

  • open OH console
  • “log:set DEBUG org.openhab.binding.shelly”

Works flawlessly with OH 3.4.2 and shelly plus plug s :+1:
Thanks!

One thing: The type of the thing is shellyplusplug, wouldn’t be shellyplusplugs be more fitting since the Device is called Shelly Plus Plug S?

I would be nice, if the binding supports the new color-features of the Shelly Plus Plug S
because then it will be useable as an optical status display

thank you.

I made this, because there is a Plug-S, Plug-IT, Plug-UK and Plug-US. It doesn’t make sense to do copy&paste for those device types if in fact it’s always the same definition.

1 Like

What are you looking specifically for? Usually you set those values once and then the LEDs follow the power/WiFi/switch operation. What do you want to achieve?

You can use the features for signaling different states in your home.
for example i use the color with following meanings:

  • red = Alarm system armed
  • green = Alarm system unarmed (for 10 Seconds)
  • blue = one or more open windows or doors
  • 


There are many possible usecases

I updated the DEV build

  • @atetzner First message for Shelly Button is processed after OH restart, in my test setup already the 1st click now triggers the event channel
  • @Wolfgang_Rosenauer Found a bug building the URL to reset the Toal consumption for 3EM
  • @SebastianB Additional check to prevent NPE when device’ time is not set
  • @goligo The binding tries to restore the channel value from cache on exception processing a channel command (e.g. set temp failed)
  • @Oliver2 An additional check to catch the “even thing handler is already disposed”, not sure if this works

3.4.3-DEV Gen1/Plus/Pro | 4.0.0-DEV Gen1/Plus/Pro | README | READMEbeta
Avdanced Users - Shelly Manager - Bugs/Features - API Doc | Firmware Index - Firmware Archive


Note: The DEV build is always newer than the version in the official Distro or Milestone builds

Who still has problems with “flipping roller position” (roller pos is incorrectly reported as 0 / 100) and could provide some logs (@aserraric?)
See also [shelly] Shelly 2.5 Roller Shutter Position Control randomly jumps to 0 / 100 · Issue #14189 · openhab/openhab-addons · GitHub

Where do I find the repository this is built from and the actual changes? I cannot test it as is, due to the other issue with the selectedProfile, but would need to cherry pick the change in order to test it.

3.4.3 build is here: https://github.com/markus7017/myfiles/blob/master/shelly/org.openhab.binding.shelly-3.4.3-SNAPSHOT.jar?raw=true

I thought my question was quite explicit, but I will try again: I cannot use your jar-File, as the selectedProfile is broken since the last release. However I want to test the changes you did for exception handling. Is there a repository, where the actual commit for these changes can be found, so I can have a look and cherry pick them?

While looking at it I am also wondering: Where do these jar-files come from? Isn’t it unusual to commit a a jar file itself to GitHub? Wouldn’t be the common approach to have the sources in Github and to have the jar file created by some automated CI or build tool?

I can’t get why you can’t run a test with the new build (just by temporary swapping the jars)
As I already commented I didn’t committed the change until you tested
Nevertheless, the code is here GitHub - markus7017/openhab-addons: Add-ons for openHAB 2.5.x

I just committed the change to my repo (#14127)

I updated the DEV build working on #14111: Thing can’t initialize with Shelly UNI and DHT22 attached


3.4.3-DEV Gen1/Plus/Pro | 4.0.0-DEV Gen1/Plus/Pro | README | READMEbeta
Avdanced Users - Shelly Manager - Bugs/Features - API Doc | Firmware Index - Firmware Archive


Note: The DEV build is always newer than the version in the official Distro or Milestone builds

And another update to fix #10847: [shelly] ix3 changing to ON and OFF every 10s without interaction

This bug could affect every installation
a really stupid vug can cause CoAP packets from device a updating status for device B if B’s IP address is included in A’s one (in this example A had 192.168.6.79 and B 192.168.6.7, so “192.168.6.7” is also included in “192.168.6.79”). Check the issue for details.

No, it is just an additional service by our contributors.

This is also done for PRs, but only for openHAB 4.x AFAIK.