Shelly Button1 click reporting delay

Lass dich durch uns Informieren
Wir Informieren dich über neuigkeiten und Angebote von Allterco.
Melde dich beim Newsletter an !
Diesen findest du rechts in der Menueleiste ganz unten.
  • I've been experimenting with two portable WiFi home automation buttons, the Shelly Button1 and the myStrom Button. I'm ignoring cloud functionality and just using MQTT and REST API's. The Shellies are significantly less expensive, but the myStrom are shipped with multiple rubber rings of different colors so that if you own several, color-coding tells you which one you're holding. The configuration experience with the Shellies is smoother and more transparent than that of the myStroms.

    The myStroms only have a REST API (HTTP Get/Post); they ignore MQTT. I worked around that with a CGI script in my Apache server that converts REST Get/Posts into MQTT publications. At the moment I have to use the same trick with the Shellies. With their current 20200601-123213/v1.7.0@d7961837 firmware, MQTT reporting of button clicks doesn't yet work.

    A fascinating difference between the two buttons is how quickly they react to clicking. Both buttons use DHCP-assigned dynamic IPv4 addresses, and typically both buttons are in deep sleep when a click begins. The myStrom button reports a short click in under one second, while the Shelly button needs a full five seconds. (If the Shelly is already awake, for example when it's USB-powered, then it also reports in about a second.) I speculate that Shelly buttons do a full DHCP acquisition including address collision detection every time they are awakened from deep sleep by a click. I haven't yet analyzed what myStrom buttons do, but they're clearly taking shortcuts. My guess is that myStrom skips address collision detection, assuming that their IP addresses are pseudo-static (in the fixed address table of the DHCP server). To speed up click reporting it might make sense in a future Button1 firmware update to offer a similar pseudo-static check box option on the WIFI MODE - CLIENT configuration page. The button would use the shortcut option only when awakened by a beginning click.

    Another suggestion I have for the whole Shelly range of products is configuration backup/restore, for example to/from a JSON file stored on your computer or server. I've written a script to do that to/from a sqlite database, but with every new device and firmware release that script needs tweaking.

  • Hi mccreigh , welcome to the forum. :)

    Thank you for your interesting comparison. :thumbup:

    Your 5 seconds for the shelly, i can confirm. This is the time between pushing and the switching the actuator in Homematic, despite a fixed ip.

  • Hi Stefan --

    Today there's new Button1 firmware, 20200625-102446/v1.7.3@2aa0993a. The good news is that MQTT now works with input_event/0 message fields "event":"S", "event":"SS", "event":"SSS", and "event":"L". And, the idea of numbering events to allow suppression of duplicate event reports and detection of missing events is cool, even though it wasn't new in this firmware release.

    The bad news is that five seconds is still five seconds.



  • Thank you for your feedback. :thumbup:

  • Hello to everybody.

    I have configured the url action for short press. When the button1 is not in charge, the time elapsed from button pressed to effective action is about 9-10 seconds. My ip is not static and the url is setted using hostname of device, for example: http://shelly1pm/relay/0?turn=toggle. There are network settings or device settings that can improve the performance ?


  • Shure.

    Please set static-ip and set in the http-request the ip.

    This should work faster. ;)

  • Hello, I have many Shelly products and I am very happy with everything, but Button1 with that delay is inadmissible, buy 2 and they are not worth to activate lights, 5 seconds or more is too much.

    A greeting.