Shelly Binding

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.

When I set the loglevel to DEBUG, it throws a lot of lines into the log, none of which look Shelly-related. I also don’t want to post a unredacted log either here or in Github, so can you tell me what I should filter for?

This is the log at INFO level, btw:

15:36:12.199 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_state' changed from stop to open     //pushing the up-button
15:36:12.204 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 0 W to 104.84 W
15:36:14.872 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 100 to 0      // this is the position from the Shelly binding
15:36:14.880 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 104.84 W to 104.49 W
15:36:27.218 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 0 to 100      // position from binding again
15:36:27.225 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 104.49 W to 106.29 W
15:36:27.790 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_ShutterActualPos' changed from 0 to 100   // this is the position from MQTT
15:36:28.008 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 100 to 0      // position from binding again
15:36:28.009 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_state' changed from open to stop
15:36:28.012 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 106.29 W to 0 W   // shutter has come to a stop
15:36:43.588 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_state' changed from stop to close            // pushing the down-button
15:36:43.594 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 0 W to 106.08 W
15:36:45.283 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 0 to 100              // position from binding
15:36:45.286 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 106.08 W to 106.06 W
15:36:48.360 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 106.06 W to 107.4 W
15:36:58.585 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 100 to 0              // position from binding again
15:36:58.590 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 107.4 W to 45.59 W
15:36:58.783 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_ShutterActualPos' changed from 100 to 0      // position from MQTT
15:36:59.149 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 0 to 100              // position from binding again
15:36:59.152 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_state' changed from close to stop
15:36:59.158 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 45.59 W to 0 W
15:37:00.409 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_totalenergy' changed from 0.035 kWh to 0.036 kWh

Are you using the latest DEV build?
you can send me a PM, but I need a detailed log

I’m running 4.0.0 M1. I’ve sent you the debug log in a PM.