Shelly Button1 click reporting delay

  • 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.

    Edited once, last by mccreigh ().

  • 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.

  • Hello,

    I would like also to share my experience with shelly button and to compare with myStrom button.

    In general I am very happy with all the shelly products I have installed in my premises.

    Now comparing the shelly button with mystrom button:

    Shelly is easier to integrate as it supports connecting to specific mqtt server. Configuration is also much easier with the web interface.

    Mystrom does not support custom mqtt connection but http requests. Configuration is performed with http requests also which is much more complicated.

    However, mystrom is super fast in executing a command from deep sleep.

    It completes the request in ~1-2 sec.

    Shelly in my cause takes 7 seconds to connect to my wifi network.

    Then in ~1 sec it completes the rest steps (DHCP ip, mqtt connect + post).

    I am using a mikrotik, high performance, router which is very fast in accepting clients and assigning IPs. Shelly is using the latest firmware.

    I am sure mystrom has optimized the association to an AP somehow.

    Please try to improve this part in shelly button and the product will be really amazing.


  • I bought a lot a shelly devices and this button if the first device that seem quite useless :
    - when I click on the button, most of the time I have to do multiple tries befire it works (red light) !!!!
    - when it works at the first time it takes so long to transmit the order.
    I have static IP and all other devices works well with my wifi (very good signal).

    Shelly should stop selling this product or totally change it way of working. I just lost 40 euros. That is why I do not buy any shelly device that is not working with an external alimentation. My trust was lost. I fear wifi devices on batteries only can be reliable using all of wifi 6 new features.

  • Did anything change since the first message of this thread has been released? I just bought a Shelly Button 1 and I'm still experiencing the same problems as mentioned above: It takes ages until it connects to my Wi-Fi even though the IP is statically assigned.

    Shelly, are you planning on releasing a new further soon?

  • ...

    Shelly, are you planning on releasing a new further soon?

    This only knows Allterco.

    You have to ask them this question. ;)