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.
MfG,
Ed
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.
