I want to thank @tomw for getting the driver fixed up for the Shelly Button1. Lets just say the button does work but if you are used to almost instantaneous response time from the button you may want to stick with ZigBee buttons for right now. I purchased the buttons to see if it was feasible to have a lines powered device comparable to the Samsung button without having to keep a supply of batteries on hand and also be inexpensive. My mom's house has lots of Samsung buttons and the battery swaps on heavily used buttons isn't fun.
What I found was a couple of things, first they are pretty easy to setup but the documentation on the web page settings leaves a lot to be desired. I was able to pull the mac addresses from the devices after they acquired a IP address from my router and setup a static address on the DHCP server for the devices. The driver was easy enough to install and configure the end device via the static IP address.
There are two ways this button works, If on a external power supply it stays connected to your WiFi network, If on battery it will disconnect from WiFi after the action, This disconnect is configurable from 0 to 5 seconds. I did a simple button controller automation for tap, double tap, and hold that would speak the action on my Echo. Each of these worked ok after a few back and forth debugging sessions on the driver.
Now the bad, on battery It can take up to 5 to seconds for a connect and send command to the Hubitat. Most of that time is the button getting connected to WiFi, grabbing an IP address and then sending the command. You can see the progress based on the color of the light ring on the button, White is connecting to AP, Green the command was sent, Red, connection to WiFi took longer that expected but usually is followed by Green. At first I thought this latency could be reduced by putting the static IP address on the button itself vs. the DHCP server but that didn't buy any shorted connection to the network.
Also say you do a tap to toggle lights and you tap to turn on lights it runs though fine, tap the button within 15 seconds that the next connection always seems to time out then followed with the Green light and the action runs. Running on the USB power being connected it seems to work fine with rapid presses of the button (not to rapid though).
One other thing I found is that it always lights up blue when the usb power is connection and flashes, Found out though experimentation that this is the indicator that shows button is connected to Wifi and it can be disabled in settings but it took a while to discover it.
My use case is to have these buttons mounted in a wall plate with a 5 v source connected to the USB port or a tabletop install in a 3d printed mount. Just a warning the bottom side of the button is convex and not flat it will spin like a top. Even on power the delay is longer that the Samsung button I would say by .25 to .5 seconds. I will say that my IoT network's SSID is hidden and didn't try any test on a non-hidden network. I would assume the results would be the same since the connect to the AP is based on beacons and not the visibility to the network name. Just a heads up you should change the 2 GHz network beacon period to as short as possible. The default on Unifi is 3 and I changed it to 1 based on a reddit post:
I am on the fence moving forward with this project. There is a new firmware coming out and I understand that Shelly has been working hard on their new network stack to work better with connects and disconnect but the are at the mercy of all the nuances of access points on the market that have to do the heavy lifting on the network.
Thanks again to @tomw on his working with me on this project.