I already have Mosquitto setup on my Synology NAS.
This isn't going to be easy... this is the payload I get
Topic: 0: {"event":"SS","event_cnt":12}
event string Input event, S = shortpush, SS = double shortpush, SSS = triple shortpush, L = longpush
So I have to map each of those to a button command. EG; button one and so on
1 Like
Apart from the latency due to the sleepy nature of the device, it is like other Smart Buttons on the market. I use other brands too for those (Osram/Sylvania 4 button zigbee devices, and also the Philips Smart Button (zigbee). The Philips is a really cool device, very easy to configure and very very fast reaction times, it's like having a physical button when turning on/off the lamps.
I guess also the drivers for those were tricky to develop, in order to manage all the buttons and combos (short/double/triple/long). This Shelly button is different just because it uses wifi and so it needs to sleep in order to save the battery. If connected to usb power, it doesn't sleep though.
Did you choose to do it via MQTT just because of the sleepy nature of the device? What if the device is connected to USB? In that case it would be good to treat it like all other smart buttons. Can you determine from the driver if the device is connected to USB power so you can bypass MQTT? Or maybe have it user selectable "MQTT option" and "Direct interface" option. Just brainstorming a little bit...
I'll just create 2 drivers for the button1 -- less headache.
My H&T does pretty well with event-based reports over HTTP even when on battery power. Since I haven't used MQTT before, I'm curious -- does MQTT offer a certain advantage with sleepy devices?
I wrote a driver for the i3 for fun. I don't actually have one of those devices. I used the URL callback methods in /settings and just configured the Shelly device to signal all events to this URL.
def hubURL = "http://${location.hub.localIP}:${location.hub.localSrvPortTCP}"
My event mapping looks like this. tripleTap() just made up to go with the custom attributes, similar to the built-in ones that Hubitat actually supports. In those handlers, I just sendEvent() always, but I figure Hubitat is probably smart enough to filter the ones that aren't needed. I suppose you could track the event counts if you wanted to make it smarter.
Maybe this is useful, assuming you agree with the event mappings.
for(input in status.inputs)
{
if("" != input.event && input.event)
{
// momentary events
switch(input.event)
{
case "S":
push(input.input.toInteger())
break
case "L":
hold(input.input.toInteger())
break
case "SS":
doubleTap(input.input.toInteger())
break
case "SSS":
tripleTap(input.input.toInteger())
break
case "SL":
// TODO: something for shortpush + longpush?
case "LS":
// TODO: something for longpush + shortpush?
default:
logDebug("unsupported event type: ${input.event} on button ${i}")
}
}
}
2 Likes
Let's see how it goes. I hope in the end you'll find it simpler to do it in one.
Can I see the whole driver? If it's that good for the i3 can I include it into our repo? I wouldn't have to write one for that device then.
It does... since I pull not just the status but the settings also and it will tell you if the device has a FW update... I prefer MQTT for that reason as I have rules that notify me of those updates then its just a click on the device page to update the device. No phone app required.
1 Like
Cool, that makes sense. I'd have to poll for the settings in a case like that. Does MQTT push a message when something like a firmware update shows up from the device's perspective?
My Shelly drivers are much more barebones than yours- for example, I didn't support firmware updates, which a lot of people really like about yours. I mainly did them as an exercise in working with Http on Hubitat and for the practice with JSON parsing.
I'm happy to share if they might give you a head start with the base functionality.
2 Likes
No -- What my code does is poll the status and settings when it receives a certain ack from MQTT.. something like this.
if (state.act_reasons == '["button"]') {
for (i = 0; i <1; i++) { // checks only once
getSettings()
getStatus()
state.act_reasons = "0" // Now we change the reason to stop getting stats
}
}
This way I can use the normal http requests as if the device was always awake. There is just enough time to pull this before it goes to sleep again.
I'd love to look at the driver. Maybe I can get some hints on how you manage the taps. I might even add some of my code to it just to make it work like my drivers and of course credit would always be given for your portion.
Sure thing, mind sending me a DM so that I can share the draft of the code plus some debug prints that I got from another user that was testing?
FYI, as I looked at it again I realized I got the button number mapping incorrect. So my code snippet above it bogus, though not too hard to fix. This is the danger of sharing code for a device that you don't actually have in your hands to test. 
Shelly Gas driver is ready for public use/testing. See this Facebook post for more info Facebook Groups
I am using an all lights off button. When I using the function in HE it takes significant longer to put all my lights off. The lights go off one by one, I geuss this is relateted to the HTTP API.
When I use the Shelly app all my lights go off in one shot in no time.
I am wondering, how does this work, is there any possibility to make this work with HE? Any ideas?
There probably is but that would depend on the cloud and that isn't the goal of local control. Mine is pretty fast here so it's probably a latency issue on your end. I know Shelly has a cloud API you can use but I have never explored that option.
18 seconds to put 15 lights off downstairs with HE, 1,5 seconds with the app, I just wondering how they do it....
No idea
I can put all my 30 Shelly lights off within 1sec with a quick script from my computer so there is most definitely no problem with the Shelly api. That leaves your network, how it’s done within HE or lastly the drivers. Cannot test the last one as I use my own lightweight drivers with action urls but I highly doubt that there is any problem with the drivers posted here.
Since I can turn off all my Shelly's via the app in 1 second to, I conclude my network is OK.
I understand you are sending from your PC messages to all your Shelly's using a script, May I concluded that has nothing to do with Hubitat?
Maybe a stupid question, in the Shelly documentation I see device API and REST API. Can that make the difference that one is faster than the other?
My drivers talk direct to each shelly device using the REST API... there is no cloud to API to shelly. So in theory my drivers should be instant compared to using the Shelly API cloud url.
And seeing that on my end I am not seeing this using my driver I can only assume it's your network.
Actually I had a thought that maybe your hub might be slow and thus taking longer to execute the off command.
I use 3 hubs here -- the 3rd controlling lights and switches and my 2nd hub dealing with any LAN devices which wifi is part of.
Yeah, they feel instant but not if I try to put +20 lights off. I takes les than 1 second to put 1 light off, let's say 1 sec. It looks the hub needs 1 second for each device 1+1+1+1+1...., the lights go off one by one, each second. I want to believe it is my network but I can switch all the +20 lights OFF in one second using the Shelly app, very confusing for me.
