Shelly button triggers events twice

UniXXer · October 7, 2020, 10:32pm

Hi,

i’ve successfully integrated my shelly button 1 today.
The problem is, that the device fires some events twice.

2020-10-08 00:22:45.608 [vent.ChannelTriggeredEvent] - shelly:shellybutton1:xxxxxxx:status#button triggered SHORT_PRESSED

[ ... ]

2020-10-08 00:22:45.794 [vent.ChannelTriggeredEvent] - shelly:shellybutton1: xxxxxxx:status#button triggered SHORT_PRESSED

Even the LONG_PRESSED event is reported two times in a row:

2020-10-08 00:26:23.727 [vent.ChannelTriggeredEvent] - shelly:shellybutton1: xxxxxxx:status#button triggered LONG_PRESSED

2020-10-08 00:26:24.034 [vent.ChannelTriggeredEvent] - shelly:shellybutton1: xxxxxxx:status#button triggered LONG_PRESSED

Is there a way to fix that?

I am using the latest openHAB docker-image (2.5.9) on a raspi. The firmware of my shelly devices is up to date.

Thanks for your help!

Cheers,
UniXXer

rossko57 · October 8, 2020, 10:47am

There was a recent thread where this kind of effect arose because channels had been duplicated. I don’t think that’s the case here, it would show up as different channel UIDs. You’ve hidden those, but I presume they are all the same.

The significant time gap between events suggests there really were two messages. Can you inspect the shelly log to see how many it thinks it sent?

UniXXer · October 8, 2020, 2:04pm

The binding receives two different events (identified by the MIDs?):

13:09:25.452 [DEBUG] [helly.internal.coap.ShellyCoapHandler] - shellybutton1-xxxxxxx: CoIoT Message from /192.168.xx.yy:5683 (MID=28714): {"G":[[0,9103,0],[0,2102,"S"],[0,2103,1],[0,3115,0],[0,3112,0],[0,3111,54],[0,9102,["button"]]]}
13:09:25.463 [DEBUG] [helly.internal.coap.ShellyCoapHandler] - shellybutton1-xxxxxxx: CoIoT Sensor data {"G":[[0,9103,0],[0,2102,"S"],[0,2103,1],[0,3115,0],[0,3112,0],[0,3111,54],[0,9102,["button"]]]} (serial=256)
13:09:25.478 [DEBUG] [helly.internal.coap.ShellyCoapHandler] - shellybutton1-xxxxxxx: 7 CoAP sensor updates received
13:09:25.493 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-xxxxxxx: Update button state with S/SHORT_PRESSED
13:09:25.511 [INFO ] [smarthome.event.ChannelTriggeredEvent] - shelly:shellybutton1:xxxxxxx:status#button triggered SHORT_PRESSED
13:09:25.536 [INFO ] [jsr223.javascript                    ] - |input {41dc4015-1591-4674-99b7-58a59900932b-shelly-js.event=shelly:shellybutton1:xxxxxxx:status#button triggered SHORT_PRESSED, event=shelly:shellybutton1:xxxxxxx:status#button triggered SHORT_PRESSED, module=41dc4015-1591-4674-99b7-58a59900932b-shelly-js}| 
13:09:25.545 [INFO ] [jsr223.javascript                    ] - |input.event shelly:shellybutton1:xxxxxxx:status#button triggered SHORT_PRESSED| 
13:09:25.558 [INFO ] [jsr223.javascript                    ] - |input.event.channel shelly:shellybutton1:xxxxxxx:status#button| 
13:09:25.662 [DEBUG] [helly.internal.coap.ShellyCoapHandler] - shellybutton1-xxxxxxx: CoIoT Message from /192.168.xx.yy:5683 (MID=28715): {"G":[[0,9103,0],[0,2102,"S"],[0,2103,1],[0,3115,0],[0,3112,0],[0,3111,54],[0,9102,["button"]]]}
13:09:25.665 [DEBUG] [helly.internal.coap.ShellyCoapHandler] - shellybutton1-xxxxxxx: CoIoT Sensor data {"G":[[0,9103,0],[0,2102,"S"],[0,2103,1],[0,3115,0],[0,3112,0],[0,3111,54],[0,9102,["button"]]]} (serial=512)
13:09:25.670 [DEBUG] [helly.internal.coap.ShellyCoapHandler] - shellybutton1-xxxxxxx: 7 CoAP sensor updates received
13:09:25.673 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-xxxxxxx: Update button state with S/SHORT_PRESSED
13:09:25.679 [INFO ] [smarthome.event.ChannelTriggeredEvent] - shelly:shellybutton1:xxxxxxx:status#button triggered SHORT_PRESSED
13:09:26.086 [INFO ] [jsr223.javascript                    ] - |input {41dc4015-1591-4674-99b7-58a59900932b-shelly-js.event=shelly:shellybutton1:xxxxxxx:status#button triggered SHORT_PRESSED, event=shelly:shellybutton1:xxxxxxx:status#button triggered SHORT_PRESSED, module=41dc4015-1591-4674-99b7-58a59900932b-shelly-js}| 
13:09:26.091 [INFO ] [jsr223.javascript                    ] - |input.event shelly:shellybutton1:xxxxxxx:status#button triggered SHORT_PRESSED| 
13:09:26.099 [INFO ] [jsr223.javascript                    ] - |input.event.channel shelly:shellybutton1:xxxxxxx:status#button|

(‘xxxxxxx’ is the id of the shelly device. It is identical in every message.)
The JavaScript-Log is the output of my custom rule, which is triggered by the button-event.

I have already tried to reset the button to the factory defaults via the web-interface. The behaviour does not change.

rossko57 · October 8, 2020, 2:35pm

Okay, so the Shelley sends twice with 200mS interval. You’ve got a wonky button, I would say. Most switch debouncing techniques only screen out shorter niggles than that.

UniXXer · October 12, 2020, 9:55pm

I am not quite sure. Maybe there is something in my network, that does some funny stuff with those multicast packages.
I’ve tried to set an action url for the short_push event. This URL is just triggered once by the button. So it is not wonky when speaking of pushing the button and triggering an url.

After that, I have tried to use the button in the “non CoIoT mode”, in which the button does not work properly. I guess, that the binding itself has a bug while initializing the device in the “non CoIoT mode”:

github.com

openhab/openhab-addons/blob/6df6783b60e1651399585c575da7ed1a18783454/bundles/org.openhab.binding.shelly/src/main/java/org/openhab/binding/shelly/internal/api/ShellyHttpApi.java#L402


                SHELLY_EVENT_ROLLER_STOP);
    } else if (profile.isDimmer) {
        // 2 set of URLs
        setEventUrl(EVENT_TYPE_LIGHT, index, config.eventsButton, SHELLY_EVENT_BTN1_ON, SHELLY_EVENT_BTN1_OFF,
                SHELLY_EVENT_BTN2_ON, SHELLY_EVENT_BTN2_OFF);
        setEventUrl(EVENT_TYPE_LIGHT, index, config.eventsPush, SHELLY_EVENT_SHORTPUSH1, SHELLY_EVENT_LONGPUSH1,
                SHELLY_EVENT_SHORTPUSH2, SHELLY_EVENT_LONGPUSH2);

        // Relay output
        setEventUrl(EVENT_TYPE_LIGHT, index, config.eventsSwitch, SHELLY_EVENT_OUT_ON, SHELLY_EVENT_OUT_OFF);
    } else if (profile.hasRelays) {
        // Standard relays: btn_xxx, out_xxx, short/longpush URLs
        setEventUrl(EVENT_TYPE_RELAY, index, config.eventsButton, SHELLY_EVENT_BTN_ON, SHELLY_EVENT_BTN_OFF);
        setEventUrl(EVENT_TYPE_RELAY, index, config.eventsPush, SHELLY_EVENT_SHORTPUSH, SHELLY_EVENT_LONGPUSH);
        setEventUrl(EVENT_TYPE_RELAY, index, config.eventsSwitch, SHELLY_EVENT_OUT_ON, SHELLY_EVENT_OUT_OFF);
    } else if (profile.isLight) {
        // Duo, Bulb
        setEventUrl(EVENT_TYPE_LIGHT, index, config.eventsSwitch, SHELLY_EVENT_OUT_ON, SHELLY_EVENT_OUT_OFF);
    }
}

In line 402, the EventURL are registered, if the device “hasRelays”, but the button does not have any of those:

2020-10-12 23:43:15.020 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellybutton1-xxxxxxxx: Device hasRelays:false (numRelays=0),isRoller:false (numRoller=0),isDimmer:false,numMeter=0,isEMeter:false),isSensor:true,isDS:false,hasBattery:true (low battery threshold=20%),isSense:false,isLight:false,isBulb:false,isDuo:false,isRGBW2:false,inColor:false,updatePeriod:43800sec

Even if this is not related to the problem, it might indicate that there is still a bug in the button support which leads to duplicated events.

However, I can’t say anything specific without debugging. It still might be something wrong with my networking…

BGrosse · November 4, 2020, 8:49pm

Hi!

I also came across this and can confirm the double triggered events!

Is there any solution to this? How can one handle this?

rossko57 · November 4, 2020, 9:10pm

If that’s what it does, that’s what it does. It is I suppose analogous to TV remotes that send the same thing several times.

Depends what you are trying to do with it.

If you’re turning a light on, it probably does not matter if you do it twice or three times.

If you’re ramping up a dimmer, you could go slightly smaller steps per message.

If you’re toggling something on/off, you probably want to block and discard repeated changes for a short period,

BGrosse · November 4, 2020, 9:16pm

Thanks rossko for your fast reply!

The toggling would be my use case - I wanna switch a wall plug of another brand, not a shelly socket. So I tried to catch the button press I want (let’s say DOUBLE_PRESSED) and I got it, but nearly all times twice with a time delay of around half a second (at least in the log). I did not tested yet what the wall socket will do when toggled twice within this short period of time, but finally - and to be safe - I may have to use a kind of debouncing with a timer within openHAB.

Just wanted to check whether or not there is an other (better) way around this.

rossko57 · November 4, 2020, 9:45pm

I think that would be very wise.
For short duration stuff, it doesn’t need to be complicated.

var multiflag = false  // global blocker

rule "my rule"
when
   some button event happens
then
   if (!multiflag) {
      multiflag = true
      createTimer(now.plusSeconds(1), | [
         multiflag = false
      ] )
      do your stuff
   }
end

UniXXer · November 4, 2020, 10:11pm

Thats my solution, too - or let’s say workaround. For me the behaviour of the button is still a bug.

I am using JSR223 / JavaScript rules:

    var LocalDateTime = Java.type("java.time.LocalDateTime");
    var lastExecution = null;

    JSRule({
        name: "Lights",
        description: "Turn on/off",
        triggers: [
            ChannelEventTrigger('shelly:shellybutton1:*******:status#button', 'SHORT_PRESSED')
        ],
        execute: function( module, input) {
            var now = LocalDateTime.now();

            if(lastExecution == null) {
                lastExecution = now.minusSeconds(2);
            }

            if(now.minusSeconds(1).isAfter(lastExecution)) {

                // .. Execute your rule  

                lastExecution = now;
            }        
        }
    });

markus7017 · November 5, 2020, 6:39am

The button should NOT trigger twice, tgis was a problem, which should be fixed un between.

Please make sure to

have firmware 1.8.2 or newer on the device
use the latest DEV build of the binding

Please continue this discussion in the main thread “Shelly binding” so everyone could participate and might help.

—

Latest DEV build: 2.5.10 - 3.0.0 - README - Installation - Firmware Index - Firmware Archive - API Doc

BGrosse · November 5, 2020, 7:25am

Thank you rosko and UNIXxer for your confirmation and code examples. I will test that of course.

Markus: thanks for the hint - the buttons are new for me (as the whole openHAB topic), but I have performed a firmware update for all new shellys I got in the last weeks. So I guess, I have the actual (official) firmware.
As to the dev build of the shelly binding, I have running a 2.5.9 snapshot which I downloaded around 1 month before now. Maybe that is outdated and I will test the 2.5.10 today.

Thanks for that hint!

BGrosse · November 5, 2020, 7:34am

Markus, please update your Latest DEV build documentation site for the correct link:

If you want to use the* latest DEV version* download the jar from my myfiles repo in GitHub.

That links to a folder “blob/master” which no longer exists.
I think it should be https://github.com/markus7017/myfiles/tree/master/shelly

markus7017 · November 5, 2020, 7:47am

This link https://github.com/markus7017/myfiles/blob/master/shelly/org.openhab.binding.shelly-2.5.10-SNAPSHOT.jar?raw=true downloads the lastest stable build. There is also 2.5.1…-SNAPSHOT, but first try 2.5.10, it also runs on OH 2.5.6+. Here your find the info how to install (you need to copy 2 more jar files): https://github.com/markus7017/myfiles/blob/master/shelly/READMEbeta.md

BGrosse · November 5, 2020, 7:55am

Thanks!

The other two files I have already running as I needed them for the 2.5.9 snapshot. Or have they been updated also? I have 2.0.0 for both actually. I think that should be ok and I don’t need to renew them…?

BGrosse · November 5, 2020, 9:46am

Ok, tested binding 2.5.10.202010192018 with complete removal of all things and the old 2.5.9 binding, rediscovered everything again successfully, BUT: status#button is still double triggered.

So no progress here. Firmware of the button is reported as 20200827-070047/v1.8.3@4a8bc427, so this should be also OK.

markus7017 · November 5, 2020, 1:22pm

I had a look into that several time. From my point of view this is a firmware bug. However, it’s not easy to create awareness.

BGrosse · November 5, 2020, 1:53pm

Yes, I get you I think. I read a lot in the Shelly Binding thread and there seem to be a lot of unsolved problems… woow!

What do you think, should I debounce it in openHAB or may one go to Allterco? Are they serious about the problems users have? What would be the best to resolve this?

rossko57 · November 5, 2020, 1:58pm

Debouncing at the OH end is transparent i.e. won’t matter if remote transmissions are multiple or not.
If you want it working today, there seems to be no choice anyway.

UniXXer · November 5, 2020, 2:05pm

I have already contacted the customer support, to help me with the duplicated events.
An answer is overdue…

Do you have some details on this particular problem? I would extend my question with that information.