Shelly button1 drivers - do they exist?

I've done a few searches and I can't find any Shelly Button1 drivers for HE. Any tips?

I just watched a YouTube video on the Shelly Button1 and I agree this would be a cool button replacement for the Samsung buttons if there were drivers for them. The only downside is that they are Wifi based but if you have a good Wifi network it should be just as reliable as Zigbee.

And at $23 per button it's a deal:

I created a Button1 driver in the same style as my Shelly Uni driver. But I don't actually have the hardware.

Do you guys have Button1 devices to test with? I'd like to get some testing feedback before I merge the changes.

I was going to get one for testing if there was support in Hubitat. I'll let you know when it comes in.

1 Like

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.


Thanks for the detailed review @ronv42. It sounds like they are workable for my use case when powered externally. I will just have to explore whether I can still place the buttons where I want to without the power cables becoming obtrusive.

I noticed when reviewing the Shelly API documents that they are moving to a 2.0 version of the API. I haven't fully reviewed it, but it looked like a fairly big change that would likely render existing integrations obsolete. I'd that the firmware update that you were alluding to, or is it something more incremental in the meantime?

Yes it's their new firmware that includes their 2.0 API.

1 Like

FYI to anyone interested, I just added my Shelly Button1 drivers to the repo I described here: Vote for Shelly UNI - #16 by tomw

Thanks to @ronv42 for testing the Button1 integration and @Sebastien for verifying that I didn't break the existing Shelly Uni support. :slight_smile:

Just a simple thought it appears that the battery level is reported with these devices. Don't know if with @tomw driver if it's possible to get to the path that holds the sensor data where the battery level is maintained but this would be great to have for low battery warnings in hubitat.

Also I am now getting about a 1.5 second vs. 4 to 5 second delay with Wifi when on battery. But the issue with a new button press just a few moments right after the first press when on battery has the same issue of timing out and then going though making it about a 5 seconds to action being detected in the hubitat. I used the latest beta (RC2) version of the firmware for this reduction in the latency.

I did also notice if there is very little or no activity with the AP I am connected to, the delay for the button to make it's connect is a bit longer. When the AP is busy sending/receiving data the connection is almost instant. This must be due to the way AP beacons are attached to transmissions.

One other thing is that you don't want to use these things near a microwave oven. 2.5 GHz noise will drown out the button from making reliable connections when the oven is running. And no I didn't put it in the oven :grinning_face_with_smiling_eyes:


Thanks for the suggestion, @ronv42. I added the battery and powerSource capabilities and included them with version 0.0.21 in my listing. Please let me know if you have any other requests.