Shelly Binding

Great to hear :wink:

I closed the case at Shelly, as my experience is the following (OH 4.1.1) :
I have 3 (5) Shelly plus 2 PM. One since “long time”, firmware 1.3.3, added with the Shelly binding from the store and works just fine.

For other reasons, I installed the Shelly beta binding (and reverting back - more the once).

Purchased two other Shelly Plus 2PM and upgraded to 1.4.2 before adding to OH :

  • not discovered
  • not working (Unexpected error: WebSocket connection closed abnormal)

Therefore, the obvious conclusion was that this problem is related tot the new firmware.

So, I purchased two other Shelly Plus 2PM, upgraded to 1.3.3, and also

  • not discovered
  • not working (Unexpected error: WebSocket connection closed abnormal)

In my humble opinion something goes wrong when the beta binding is installed. Or I am missing something ?

(all in cover mode - Shelly Plus 2PM works justs fine in switch mode).

Any help appreciated.

I assume you restarted the Shelly device in an attempt to trigger the autodiscovery?

Yes.

I have 3 shellyplus2pm in cover mode and fw 1.4.2 in place. All working perfectly and got added without any problems. Maybe there is a particular setting which conflicts with the binding?
changes I have done:

  • password protection is on
  • device name changed before adding to openhab
  • access point and bluetooth is deactivated
  • none of the connectivity options are enabled
  • sntp url set to local time server

For those who have the Shelly plus 2PM working, what version of OH and binding is used ?
(I installed a 4.1.1, did not work, upgraded to 4.2.1) works fine.

I have “only” Shelly plus 1PM working.
OH: 4.2.1-1 on RPI5, RPI4, and RPI3
Shelly Binding: 4.2.1
FW: 1.4.2

I upgraded to 4.2.1 and both Shelly plus 2 PM are discoverd.
(but now my panels are no longer working - which is solved by clearing the cache).

Today I upgrade a Shelly Plus 2PM to fw 1.4.2 in cover mode and it comes back online after the upgrade. I used OH snapshot build and latest merged PR.

What other symptoms help to narrow down the problem.
Is it just a problem with device discovery
or does the thing gets offline on initialization
or does it work for a while and then goes offline?

What I have seen :

  • only in cover mode
  • OH 4.1.1
  • firmware 1.3.3 or 1.4.2

Shelly Plus 2PM is not discovered. When added manually the device is not working : Unexpected error: WebSocket connection closed abnormal.

BUT : I had a Shelly Plus 2PM with firmware 1.3.3 on OH 4.1.1 working just fine under 4.1.1. Problem started after installing and/or removing the beta binding (found in the store) and adding other additional Shelly’s in cover mode. The first shelly kept working just fine all the time.

to be clear : OH 4.2.1 and shelly binding (beta or current - 4.2.1), the Shelly Plus 2PM in cover mode is working just fine.

(for my situation, all the shelly Plus 2PM work just fine now, but I am not the only one who sees these errors - I am looking forward for support for the shelly Pro dimmers an BT devices).

What is “cover mode”? I tried googling it, but I can’t figure it out… I also don’t see it among the options?

*It also supports cover control, which makes it perfect for automating curtains, roller shutters, garage doors, awnings, gates, and any other two-directional motor in your home. *

6e666b7103a76bfa7bcf689ac74d65416b2db4751

This Shelly can be operated in two modes:

  • switch mode: you can attach two separate devices (like light bulb)
  • cover mode: to control a motor for blindings (cover, …)

Difference: in cover mode you cannot switch on both circuits simultaneously which would destroy your motor

Aha, I understand! (I also was looking at the wrong device, no wonder I didn’t see it…)

So firmware 1.4.2 is supported?

I can confirm that

  • Shelly plus 1
  • Shelly plus 2PM (with a Blu Button)

are working flawlessly with 1.4.2.

Shelly Mini1PMG3 missing events on ‘Latest Event’ channel

Hi,

I’m noticing that consecutive events of the same value are not being registeted by openhab, or at least they’re not showing up in the ‘Latest Event’ channel. So, if I give the device a short press the latest event channel shows the event, but when I give the device a second short press the event channel doesn’t show it. This is also the case for all other event types like double and tripple short presses and a long press. When I alternate between types the event channel does show them. If I take a look at the device web interface and monitor the input status I see all the events are being registered. I find this behaviour a bit confusing and I’m wondering if this is by design or that maybe something else might be going on. Is anyone recognizing this behaviour?

I’m on openHab 4.2.1 with the corresponding Shelly binding, the Shelly device is running firmware version 1.4.2.

I hope someone can help me out here.

Best regards,
Jesse

you could use the event count channel, this should change every time

the binding caches channel values to avoid frequent updates to channels if nothing has changed

@markus7017 , Hello :slight_smile: Could it happend, that the current binding only show the state from the button on a Shelly Button1 events, when a “change” happend?

So normal the log file tells me, that the button has pressed, and tells which of the different presses was done.

2024-09-19 09:27:15.487 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_Betrieb' changed from OFF to ON
2024-09-19 09:27:18.229 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_LetzteAktivitat' changed from 2024-09-19T09:27:15.000+0200 to 2024-09-19T09:27:18.000+0200
2024-09-19 09:27:18.229 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_Laufzeit' changed from 350298 s to 350307 s
2024-09-19 09:27:30.600 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_LetzteAktivitat' changed from 2024-09-19T09:27:18.000+0200 to 2024-09-19T09:27:30.000+0200
2024-09-19 09:27:45.684 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_LetzteAktivitat' changed from 2024-09-19T09:27:30.000+0200 to 2024-09-19T09:27:45.000+0200
2024-09-19 09:27:55.390 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetzteAktivitat' changed from 2024-09-19T09:27:15.000+0200 to 2024-09-19T09:27:55.000+0200
2024-09-19 09:27:55.390 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetztesEreignis' changed from S to 
2024-09-19 09:27:55.390 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetzteAktualisierung' changed from 2024-09-19T09:27:15.000+0200 to 2024-09-19T09:27:55.000+0200
2024-09-19 09:27:56.040 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetzteAktivitat' changed from 2024-09-19T09:27:55.000+0200 to 2024-09-19T09:27:56.000+0200
2024-09-19 09:27:56.041 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetzteAktualisierung' changed from 2024-09-19T09:27:55.000+0200 to 2024-09-19T09:27:56.000+0200
2024-09-19 09:27:56.041 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_Ereigniszahler' changed from 54 to 55
2024-09-19 09:27:56.041 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetztesEreignis' changed from  to SS
2024-09-19 09:28:00.707 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_LetzteAktivitat' changed from 2024-09-19T09:27:45.000+0200 to 2024-09-19T09:28:00.000+0200
2024-09-19 09:28:05.575 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetzteAktivitat' changed from 2024-09-19T09:27:56.000+0200 to 2024-09-19T09:28:05.000+0200
2024-09-19 09:28:05.575 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetzteAktualisierung' changed from 2024-09-19T09:27:56.000+0200 to 2024-09-19T09:28:05.000+0200
2024-09-19 09:28:05.575 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_Ereigniszahler' changed from 55 to 56
2024-09-19 09:28:05.575 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetztesEreignis' changed from SS to S
2024-09-19 09:28:05.865 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_LetzteAktivitat' changed from 2024-09-19T09:28:00.000+0200 to 2024-09-19T09:28:05.000+0200
2024-09-19 09:28:05.865 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_Betrieb' changed from ON to OFF
2024-09-19 09:28:06.086 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobilierSteckdosenButtton_LetzteAktivitat' changed from 2024-09-19T09:28:05.000+0200 to 2024-09-19T09:28:06.000+0200
2024-09-19 09:28:06.257 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_LetzteAktivitat' changed from 2024-09-19T09:28:05.000+0200 to 2024-09-19T09:28:06.000+0200
2024-09-19 09:28:06.257 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MobileOutdoorSteckdose_Laufzeit' changed from 350307 s to 350355 s

Documentation for the different button1 type is this:

Button events
Various devices signal an event when the physical button is pressed. This could be a switch connected to the SW input of the relay or the Button 1 or 2.

The following trigger types are sent:

Event Type	Description
SHORT_PRESSED	The button was pressed once for a short time (lastEvent=S)
DOUBLE_PRESSED	The button was pressed twice with short delay (lastEvent=SS)
TRIPLE_PRESSED	The button was pressed three times with short delay (lastEvent=SSS)
LONG_PRESSED	The button was pressed for a longer time (lastEvent=L)
SHORT_LONG_PRESSED	A short followed by a long button push (lastEvent=SL)
LONG_SHORT_PRESSED	A long followed by a short button push (lastEvent=LS)

So I see in the logfile only the “S” or “SS” commands, when they change.
I DO NOT SEE the commands when a “S” command follows an “S” command.

Why I need this?

I start a rules based on a single press and from a douple press from the button:

e.g. when item Klimaanlage_Button_Letztes_Ereignis was updated to S then switch on klima
e.g. when item Klimaanlage_Button_Letztes_Ereignis was updated to SS then switch off klima

So when the short press was Not recordnized in this moment, why the WIFI was to bad, or etc, I need to douple press the button1 to give out an “SS” and then press again a single press to give out an “S” comand. The same happends, then I use a buttom from my OH MainUI to start the rule.

Is there a possiblity to give out the comands also if they NOT change between “S” and “SS”, also to “S” followed by and “S”

Thanks…

how does you rule look like?
try to use the event count channel as a trigger