Hey everyone! I've been working on some device drivers for Shelly devices that do not require running a server with an MQTT broker to function. They also do not rely on any sort of polling for state changes, everything is instant response. The notable deviation from this is the Uni Gen 1, which has (optional) polling child devices for the ADC, DS18B20, and DHT22.
You can find the drivers on HPM, just search for "shelly":
Or install them manually from the GitHub repo if you prefer.
These drivers do not (and will not) entirely replace the web UI for device administration. If you want to change some of the more obscure settings, you'll want to use the web UI for the device or the Shelly mobile app. Some of the more important settings will included in Hubitat, for things like setting motion sensitivity, auto-on/auto-off timers, etc.
Current list of drivers I've added to HPM:
Shelly 1
Shelly 1PM
Shelly 2.5 (gen 1)
Shelly 3EM
Shelly Blu Gateway
Shelly Bulb RGBW
Shelly Button 1
Shelly Dimmer 1&2
Shelly Duo WW/CW Bulb E27&GU10
Shelly EM
Shelly Flood
Shelly Gas
Shelly H&T (gen 1)
Shelly Motion 2
Shelly Plug US (should work with IT, S, and UK model too)
Shelly Plus 0-10v Dimmer
Shelly Plus 1
Shelly Plus 1PM
Shelly Plus 1PM Mini
Shelly Plus 2PM
Shelly Plus H&T (gen 2 and gen 3)
Shelly Plus I4
Shelly Plus RGBW PM
Shelly Plus Smoke
Shelly Plus Wall Dimmer
Shelly Plus PM Mini (gen 2 and gen 3)
Shelly Pro 1
Shelly Pro 1PM
Shelly Pro 2
Shelly Pro 2PM
Shelly Pro 3
Shelly Pro 3EM400
Shelly Pro 4PM
Shelly Pro Dual Cover PM
Shelly Pro Dimmer 1PM
Shelly Pro Dimmer 2PM
Shelly Pro EM
Shelly RGBW2 (gen 1) <- For RGBW mode
Shelly RGBW2 White (gen 1) <- For White x4 Mode
Shelly Uni (gen 1)
Shelly Uni (gen 2)
Shelly Vintage
Shelly Motion Blu
Shelly Door/Window Blu
Shelly Button 1 Blu
Shelly Button 4 Blu
Shelly Wallswitch Blu
Shelly H&T Blu
Yep, that's right, there's support for Shelly's line of Bluetooth devices. You need at least 1 device with Bluetooth Gateway capability. The Shelly BLE Gateway obviously has BLE support. As does the Plug US. There's an option in the config for BLE capable devices for "Enable Bluetooth Gateway for Hubitat" which will create a Shelly Script on the device that relays bluetooth events to Hubitat.
The second piece of this is installing the 'Shelly Bluetooth Helper App' included in HPM for these drivers. This app is mandatory for Bluetooth devices to work as it's what relays the events between the gateway(s) and the Blu device(s) in Hubitat. This app will write warning level messages in the log that includes the MAC address of the Bluetooth device when it "hears" one that doesn't have a corresponding device in HE. Alternatively, you can find the MAC address of your Blu devices on the Shelly mobile app.
The drivers use websocket when available to get instant updates on device state, such as when you manually turn it on/off via the button on the plug. For devices with power monitoring reports, they are also over websocket, so updates are instant. These can be pretty 'chatty' over websocket, sending around 10,000 events per day, but I've heavily optimized the driver. On a Hubitat C7 it used 0.028% of the total CPU to process just shy of 10,000 events in the last 24 hours I tested it. It's absurdly efficient, so it shouldn't cause any CPU issues even if you have bunch of them.
NOTE about Power Monitoring:
Summary
Power Monitoring uses different drivers for the child component devices. Hubitat does not allow for dynamically setting device capabilities, nor does it allow for a parent device to change the driver used by a child. So that leaves 2 options: 1) everything uses power monitoring driver and Hubitat thinks every child switch has power, current, energy, and voltage capabilities when they don't actually have it, and they show up in all the drop-downs in HE for "Power Meter" and whatnot, even tho they'll not actually have any power monitoring data, or 2) use separate drivers for child devices that have power monitoring and those that don't.
I opted for option 2. This means if power monitoring is not enabled when you configure the parent (ie, saving the IP address in the settings), and it creates all the child devices, it creates them with the non-power monitoring driver. If you want to change later to having power monitoring on, you have to enable the setting on the parent AND switch the child component driver to the power monitoring version or delete the child before clicking configure, at which point the parent creates a new child with the power monitoring driver. Deleting the child and recreating has the downside of breaking any Rules or anything else that might have been utilizing the child, whereas simply changing the driver being used manually will not.
By default Power Monitoring is enabled. So all children are created with the PM driver version. If you turn it off, it sets the children to all have "0" for their states and stops processing PM events from the Shelly device. You can safely use the PM driver versions with PM disabled, the only downside is 'polluting' your dropdown for "Power Meter" and such with devices that aren't presently performing any power monitoring. To clean that up just switch the children to the non PM driver version.
None of these options are perfect, so I just went with the one I figured would be the least trouble for the least people: defaulting to PM on and creating children with PM version drivers.
The driver for the Button 1, H&T, and Motion 2 all use webhook "Actions" to inform Hubitat of state changes, among some others. Gen 1 devices use web hook only (or polling, for the Uni, as mentioned above), and Gen2+ use both web hook and/or websocket.
On Gen 2+, the webhook actions created by the HE driver during configuration are "named". The device driver creates webhooks with unique names, so unless you happen to have a webhook named "hubitat.humidity.change" it won't conflict with anything you might have set up.
On Gen 1 devices, and they don't have "named" webhooks. Using these drivers will overwrite any webhook actions you may have set up. The driver creates webhooks at "index=0" for these devices and that will overwrite anything that might be set up. If you're not currently using custom actions, you have nothing to be concerned with here.
If you're using custom webhooks on these devices you have a few options. One, you can find an MQTT driver for them and run an MQTT server. I'm personally a fan of not running and maintaining an MQTT server, so I definitely wouldn't recommend that option. A second option, which I would suggest, is letting these device drivers overwrite whatever action you have set up, then using Rule Machine to perform the webhook action you previously had setup on the device. So if you had a webhook setup on your Motion 2 for " MOTION DETECTED", you'd instead set up a Rule in Rule Machine with "trigger: motion started" and an action of "Send HTTP GET". This way the Motion 2 can HTTP GET to Hubitat and inform it of "motion_on" and then you can have Hubitat relay that on via another HTTP GET using Rule Machine.
Setting the drivers up is pretty simple. You only need to provide the IP address of the device, and username/password if using authentication on gen 1 devices, or password on Gen 2 (they don't allow setting a username). Authentication is supported on all drivers. It does add overhead, so I'd suggest not using it if you can avoid it. For a "normal" setup, with everything on the LAN side of a typical home router, it's really not needed.
When clicking on "Save Preferences" after adding the IP Address (and auth information, if applicable) you need to ensure any battery powered devices are 'awake'. So in the case of the Motion 2, it's always awake. The Button 1 needs to be plugged in via micro USB. The H&T devices have a button in the battery compartment that needs pressed.
If the device is awake, "Save Preferences" should then connect to the device and set the required webhooks up to have it connected to Hubitat directly. No MQTT needed. You can verify things are setup on the device itself if you want. For example, on the Motion 2, you'll see your Hubitat IP address under some of the Actions like so:
I'll be adding many more drivers here in the next few weeks. None of them will use or need MQTT.
