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 use any sort of polling for state changes, everything is instant response.
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. The Shelly Plug US driver has its settings available in HE already. The Motion 2 will be added soon.
Current list of drivers I've added to HPM:
Shelly Plug US
Shelly Button 1
Shelly H&T (gen2 and gen3)
Shelly Motion 2
Shelly H&T (gen 1)
Shelly BLE Gateway
Shelly Gas (WIP, needs valve activator control added)
Shelly Motion Blu
Shelly Door/Window Blu
Shelly Button 1 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 driver for Shelly Plug US uses websocket to get instant updates on device state, such as when you manually turn it on/off via the button on the plug. It supports power monitoring reports, also over websocket, so updates are instant. These plugs are '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.
The driver for the Button 1, H&T, and Motion 2 all use webhook "Actions" to inform Hubitat of state changes.
On the H&T, since it's 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 the Motion 2 and Button 1, these are 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. 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.
