Shelly button triggers events twice

What kind of information do you need? Of course I will spend all infos which are neccessary to track down this problem for all times. But as you may have read, I’m still a newbie in this, so maybe you can assist me a little bit.

As to my system:

  • Platform: Raspbian GNU/Linux 10 (buster) on Raspberry Pi 4B, OpenHAB 2.5.8-1 (Release Build)
  • Shelly Binding 2.5.10.202010192018 with
  • Californium Core 2.0.0 and Element Connector 2.0.0
  • 3 Shelly Button1 with firmware 20200827-070047/v1.8.3@4a8bc427
  • 12 Shelly 2.5 (no problems)
  • 2 Shelly 1PM (just being installed in this moment)

My OpenHAB log is completely inconspicuous, just normal ItemStateChangedEvents. No Java errors, no JSON errors, things are always discovered automatically, a handful manual created rules exist to “connect” the things by events. Nothing special at all and everything I did actually works perfectly! I am really satisfied with OpenHAB so far! :slight_smile:

The only thing is this double event now. If I double press one of the buttons, the log shows the following:

2020-11-05 15:30:52.317 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellybutton1-483fda6fedf6: Event erzeugt: BUTTON
==> /var/log/openhab2/events.log <==
2020-11-05 15:30:52.315 [vent.ChannelTriggeredEvent] - shelly:shellybutton1:483fda6fedf6:status#button triggered DOUBLE_PRESSED
2020-11-05 15:30:52.325 [vent.ChannelTriggeredEvent] - shelly:shellybutton1:483fda6fedf6:device#alarm triggered BUTTON
2020-11-05 15:30:52.337 [vent.ItemStateChangedEvent] - shelly_shellybutton1_483fda6fedf6_status_eventCount changed from 0 to 1
2020-11-05 15:30:52.342 [vent.ItemStateChangedEvent] - shelly_shellybutton1_483fda6fedf6_status_lastEvent changed from to SS
==> /var/log/openhab2/openhab.log <==
2020-11-05 15:30:52.877 [INFO ] [clipse.smarthome.model.script.Button] - A double push was detected
2020-11-05 15:30:52.877 [INFO ] [clipse.smarthome.model.script.Button] - A double push was detected
==> /var/log/openhab2/events.log <==
2020-11-05 15:30:52.690 [vent.ItemStateChangedEvent] - shelly_shelly25_relay_40f52004586b_meter1_currentWatts changed from 0.0 W to 17.5 W
2020-11-05 15:30:52.695 [vent.ItemStateChangedEvent] - shelly_shelly25_relay_40f52004586b_relay1_output changed from OFF to ON
2020-11-05 15:30:52.835 [vent.ChannelTriggeredEvent] - shelly:shellybutton1:483fda6fedf6:status#button triggered DOUBLE_PRESSED

The INFO lines are printed from my fired rule. As you can see, they occur double as the shelly:shellybutton1:483fda6fedf6:status#button triggered DOUBLE_PRESSED event occurs twice. So the rule is correct - the double status#button event is the problem.

What else do you need?

Thanks for the information. I filed something quite similar to the shelly support.

I wanted to refer to the following post:

Just forgot to quote it correctly :wink:

Maybe markus7017 has some deeper knowledge of the problem, which might help the shelly support to solve it.

Ok, after having another problem with door/window 2 sensor, I talked a little bit to Markus and he resolved the issue (ok, it’s more a kind of workaround because originally it’s a firmware bug form Allterco).

Just download the correct binding 2.5.12 from here and follow the installation / update instruction from here. Everything should work now as expected. :metal:

1 Like

correct, we are still in discussion witg Allterco and tgey don’t want to get into this, because it‘s a quirk for their problem around cloud integration. I think we need to live with tge work around

Hi all, new to this forum but thought I share my observation on this one:

I also see events triggered twice, no matter which type (SHORT_PRESSED, DOUBLE_PRESSED,…). Interestingly, this only happens if the Shelly Button is on battery. As soon as I connect it to USB for charging it only fires the event once.

Obviously, this is no solution to the problem but might give a hint on where its coming from.

I’ll also try the 2.5.12 binding the next days.

1 Like

Thanks for the workaround. I want to move on to the 3.x branch of openHAB, so I will not try 2.5.12. Is the workaround available in the latest openHAB release, too?

In the meantime, I have received an update from the Shelly-Support:

Hi, from the data you sent us it looks like the two coap packets actually only report 1 click event:
in the first packet : [0,2102,“S”],[0,2103,1] -> shortpush, count 1
in the second packet: [0,2102,“S”],[0,2103,1] -> shortpush, count 1
As the counter hasn’t increased, this is actually just 1 event on the button.

This is relying to the output of the ShellyCoapHandler.

You could educate the support: When the button goes to sleep mode and comes back it always restarts with event count = 1 and serial=1. The problem has been verified by more than 1 project/developer and is acknowledged by Allterco, but we still have no solution beside the work around, which is part of the DEV builds 2.5.12 and 3.1.0

Latest DEV build: 2.5.13 - 3.1.0 - README - Installation - Bugs/Features - Firmware Index - Firmware Archive - API Doc
Note: The binding version included in the final OH 3.0 distro is significantly older than the DEV build. I can’t make it in-time. Make sure you deleted older versions of the binding when installing the 2.5.13-SNAPSHOT or 3.1.0-SNAPSHOT if you are already on OH 3.

Ok, something is wrong with the Shelly binding and the Shelly button.
I’m now on Shelly binding version 3.1.0 DEV, and it recognizes the button presses fine after restarting Openhab. But after some minutes the shelly binding suddenly stops working and my trigger rule is not triggered anymore. I can see in Wireshark that the button is still sending our mdns broadcasts. After restarting Openhab it’s working for a few minutes again…

from core.rules import rule
from core.triggers import when

@rule("gang_button")
@when("Channel 'shelly:shellybutton1:84cca8abec2e:status#button' triggered SHORT_PRESSED")
def gang_button(event):
    gang_button.log.info("Triggered. receivedCommand: {}".format(event.event))