Shelly Device Handlers for Hubitat

Hello All,

Recent entrant to home automation and a lot of shelly 2.5 lying around my house. I managed to add the shelly 2.5 using both the built in driver and the SHELLYUSA driver. The shelly USA driver provides a lot of information, however the on/off actions don't work. The native driver is a simple on/off that works.
Is there any reason why it wouldn't work?
clicking the on/off buttons in the device page doesn't do anything, but I switch it on from the shelly app and poll the device it reports "on" stage.

It works here just fine

Ok I Figured it out. It seems the "Prevent Accidental on/off" needed to be changed for it to work.

Thanks Borg, very thankful for the efforts you put in for this.

1 Like

You're welcome

It would be nice to have a confirmation by @mike.maxwell about the issue. I'm not quite sure if it's an Alexa limitation or an Amazon Echo Skill app limitation. In the latter case it could be fixed I guess.

Thanks for any advice Mike.

I am correct on this issue. If you have a contact switch that also reports temperature and add it to Alexa the default attribute used is temperature in Alexa and not open/close.

I tested this using a spare Iris contact sensor(3320-L) that also reports temperature and Alexa reports it as the default a temperature sensor instead of a contact sensor. Now even though Alexa defaults to this I can still make a rule for the contact sensor using Alexa.

I have to admit this is very odd behavior considering this never happened until recently. @mike.maxwell may not answer this and confirm this but I am very sure of my testing.

1 Like

I don't doubt your observations Scott, I just wanted to understand if the problem is the HE app that presents the devices to Alexa or it's Alexa that doesn't manage correctly devices with multiple capabilities. Since this odd behaviour never happened before, it could be some changes in Alexa APIs or the HE Echo skill implementation.

Seriously it's the SKILL not the API... in either case why it's happening is beside the point here. What it is doing is exactly what I have explained which makes it NOT a driver issue or a Shelly one.

This issue shouldn't even be in this thread and instead reported under the support threads.

I know it's not your driver because it worked before and the driver didn't change.

1 Like

Exactly... I think I even made a post about it.. I'll see if I did.

Edit: No I guess I didn't. You can make one if you wish.

I have a VERY VERY beta driver ready for the Window/Door2 device if anyone is interested in it. You need to have a MQTT broker for this to work.

What doesn't work correctly still is the vibration detection... that seems to be a hit-or-miss problem which may or maynot be because of the device or the Shelly FW. Everything else works as far as I can tell.

Actually I'm waiting for a beta driver of the Button1. :wink:

Scott, do I simply comment this line in the switch driver?

capability "TemperatureMeasurement"

yes then add to alexa and after you have done that uncomment that line again and save the driver.

Comment by adding // to the beginning of that line.

The driver will use MQTT so you will need a broker to use it then.

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...:slight_smile:

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