[PRERELEASE FEEDBACK WANTED] Shelly Device Manager App + Drivers

⚙️ Custom Apps and Drivers Custom Drivers
, ,
1

I've been working on a new "Shelly Device Manager" app, with a full suite of drivers. It's an app that displays all the "discovered" Shelly devices on your network. If you have one or more Shelly Devices installed, and you've enabled the "Bluetooth Gateway" functionality of the app, it'll autodiscover Shelly BLU devices as well. It runs mDNS and a subnet scan for Shelly devices, and you can manually specify an IP address or dns name for it to probe manually, too, if needed.

It's just a single stand-alone app. No drivers to install. When it discovers a device it'll grab the latest driver from the ShellyUSA GitHub repository where this project is hosted, install it on the fly, and create a device in Hubitat using that driver. If you remove a device and it's the last one using a driver, it'll clean up the installed drivers. The app auto-updates at 3AM, so once installed there's no further management needed on your part.

Looking for some community feedback to drive the direction of this development before I wrap things up and put out an official release.

Anything anyone want from their Shelly devices that doesn't work on Hubitat? Any missing features? Any devices lacking proper support?

So far I've added device support for practically every Shelly device made, WiFi and Bluetooth. There's even drivers for the Shelly Sense and the Shelly BLU TRV. So far this is what I've got put together:

image
image3200×6012 1.56 MB

Edit: Still pre-release, but anyone wanting to test out specific devices they use/care about and willing to provide feedback/bug reports would be appreciated. To install, click on "Apps Code" on the left sidebar of Hubitat, click on "Add App" along the top of the screen, then click on the 3 dot menu in the upper right, and click on "import". Then paste this URL: https://raw.githubusercontent.com/ShellyUSA/Hubitat-Drivers/refs/heads/master/Apps/ShellyDeviceManager.groovy and click on "Import":

image
image1258×648 42.9 KB

Or just copy/paste the content from the URL into the new app editor. Click on "Save" in the upper right. The app has built-in updating, so there's no need for HPM. Once installed, all future updates are in-app. There's nothing else to install, the app handles all driver install/uninstall.

If testing, collect whatever logs or detailed circumstances of an issue you ran into and PM me. I'll be working through the devices, but it's time-consuming to physically test each device, there's over 80 of them to run through. Feel free to report missing preferences/settings (within reason, some things make sense to have in Hubitat others are uncommon enough to just stay something that can be edited on the device UI only).

10 Likes
2

Damn - that looks great! Thank you!

3 Likes
3

Kind of stuck at "Wow" and not sure where to go from there other than thank you! :smiley:

I'm pretty sure you're aware of the utility of Shelly plug LED controls and have included that. :slight_smile:

This sounds extremely cool.

1 Like
4

I’ve got some older (First Gen) Shelly Uni devices. Would they work with this app?

5

Thanks! I spent a fair bit of time getting this together.

I made a more or less complete suite of drivers, but there's a lot of "variants" for Shelly devices. You've got "Plug US", "Plug UK", "Plug EU" etc... they're all the same device, same driver. But when putting that on HPM do you just name the driver "Shelly Plug"? There'll always be folks going and looking for "Shelly Plug US" and being confused when they don't see the exact name available as one of the options. It gets muddier when dealing with the various "here's a Shelly with 2 inputs and 2 relays"... there's gen 2 and gen 3 versions of that, in normal, mini, Pro (DIN) formats. Internally they're the same, but they're very much different outside.

So even with putting 'no duplicates' on HPM, then install still presented the user with dozens of drivers to pick from. They'd have to go install the correct one, get the IP address of the Shelly, add that to the device preferences page and save it. They need to make DHCP reservations to keep that IP address stable.

This needs none of that. It finds the device. It figures out the correct driver, so you don't have to worry about picking the correct one. It doesn't need a separate "helper" app if you want a BLU device to work. Heck, you don't even need DHCP reservations. There's 2 different ways this app will auto-update the IP address of your Shelly if it ever changes. First, any time it's "discovered" again, if the IP address changed, it'll update it. Then almost every device sends packets to port 39501 when there's state changes, temp changed, scheduled 'check-in', etc. All of these will update the IP if it changes. DHCP reservations are still a good idea, but at the very least if your device changes IP it'll get fixed up in a relatively short time automagically.

If you have any BLE capable AC powered devices, there's an option to click on the UI to install the BLE Gateway script, which relays BLE packets back to Hubitat and sends them off to the BLU devices created on Hubitat. The BLU TRV even works, relayed through the Shelly BT USB gateway it's paired to.

The Shelly Wall Display has a driver, for the various sensors on board. The Shelly Sense also has a driver... admittedly I don't have one of these on hand since they're discontinued, but it should work, including issuing IR commands to devices, from Hubitat. So if anyone has one of these and wants to have a bit of back-and-forth to iron out any bugs in that driver, I'd be happy to.

All of the drivers are stand-alone in terms of their "parse()" not relying on the parent app, so all incoming state updates are rather low overhead. When sending commands, they all relay through the parent app, because the code needed to send commands to Shelly devices is rather complex, and I didn't want to duplicate it across the drivers, nor did I want to have a massive library that everything uses, since dealing with libraries on Hubitat is not very nice to do.

There's options to set power monitoring reporting interval, as well. I ended up crafting a Shelly Script that sends the power monitoring data to Hubitat at a user-specified interval with reasonable decimal precision and only sending changes when there's an actual change. That's much much less CPU load than using MQTT or Websocket, as neither of those have an option to set the reporting interval, and by default it's every 0.88 seconds.

3 Likes
6

Yes, I'm waiting on a Gen 4 to test out, but it'll have a driver with an optional child RGB device that should act like any other RGB in Hubitat, to control the LED. There was a bit of a shipping snafu so it'll be a couple more days before I have one in hand to test.

1 Like
7

Yes, every single Gen 1 device is covered. I've got the Uni Gen1 working on my other library, so it'll function much the same here. If there's anything in particular you need, let me know. I have one to test with, but I don't have a "use" for it presently, so I'm just testing basic functionality and not any particular use-case.

2 Likes
8

Ah, two question I forgot to ask...I'm new to Shelly devices so couple questions:

  1. For non-"BLU" devices, do the Shelly devices need to already be connected to the local network via Wi-Fi (or Matter over Wi-Fi) to be found & set up?
  2. If a Shelly device is already set up via Zigbee and it supports Wi-Fi/BLU, will discovery/setup via this manager find the device/proceed?
9

  1. For this app, yes. They need to be on the WiFi. This app doesn't do anything with Matter, and honestly, Matter is still half-baked. Quarter-baked, really. Maybe not even that. Maybe one day it'll be good, but for now it should be thought of as a last-resort option.

  2. Yes, if it's on WiFi, it'll set it up via WiFi. For some devices that have ZigBee, the ZigBee functionality is limited. For some things, it's fine and "good enough" and you have no real need to bother. If it's just a wall plug and all you ever want to do is just turn it on and off, then sure, no need to bother with anything else.

This app is focused on purely WiFi devices, and "BLU" ones. For the BLU devices to work, you need 1 or more Shelly devices that have BLE and Shelly Script components. This is most AC powered devices Gen 2+, so most likely already covered. But the BLU stuff works by installing and enabling a Shelly Script that relays the BLE packets from the Shelly WiFi device over to Hubitat. They arrive on port 39501 and get routed to the device matching the MAC address that sent it, ie, the Shelly WiFi device driver. That then forwards up the message to the app, which then reads it, matches the embedded BLE MAC address from inside the JSON body to a BLU device that has a driver on Hubitat and then that device gets updates from the Shelly Device Manager app. It doesn't use any of the new "C8 Pro Only" BT stuff, it purely relies on using a Shelly as a BT relay.

3 Likes
10

OK, count me in @ wow!

S.

1 Like
11

Thanks for the deep dive/details, appreciate it.

Ah, I was initially thinking the BT stuff was related to the new C8-Pro/BT capabilities, thanks for clarifying that it runs on C7 & earlier hubs.

Yay - I'll be able to turn off/turn down the Shelly plug power reporting which I would rarely use.

Looking foward to playing with this!

1 Like
12

You already can, with the color picker driver. :roll_eyes:

1 Like
13

Yup - using your excellent driver now, of course. :slight_smile: But there is the constant lure of new toys (devices, drivers, integrations, etc.) and I am going to take another look at Shelly devices in general based on my good experiences w/the plug. :wink:

14

@daniel.winks The app looks really good and can’t wait to give it a try. Thanks again for your work!

15

Just playing with this now.
I have a Shelly Plug Gen4 on a separate subnet, so I had to run the Manual Probe. After the second try, the plug appeared. I then ran a "Force update on all drivers" and got this log.

Recent log lines (most recent first):
2026-02-24 06:31:39 - DEBUG: Reusing existing cookie
2026-02-24 06:31:39 - INFO: Starting IP subnet scan on 192.168.0.0/24
2026-02-24 06:31:39 - DEBUG: startDiscovery: starting discovery for 60 seconds
2026-02-24 06:31:31 - DEBUG: Reusing existing cookie
2026-02-24 06:31:16 - DEBUG: Reusing existing cookie
2026-02-24 06:31:16 - DEBUG: Reusing existing cookie
2026-02-24 06:31:16 - ERROR: Failed to create shellyplugusg4-58e6c537b984: driver not installed
2026-02-24 06:31:16 - ERROR: Cannot create device 'shellyplugusg4-58e6c537b984': driver 'Shelly Autoconf Single Switch PM v1.0.35' is not installed on the hub
2026-02-24 06:31:16 - ERROR: Driver 'Shelly Autoconf Single Switch PM v1.0.35' still not found on hub after installation
2026-02-24 06:31:14 - INFO: Registered auto-generated driver: ShellyDeviceManager.Shelly Autoconf Single Switch PM v1.0.35 v1.0.35 with components: [illuminance:0, plugs_ui, switch:0]

I am still playing with it.

16

Looks like there was a compilation error on that particular driver. It should be fixed now, but keep in mind that this app and driver package is still in active development, so definitely don't rely on it for anything yet. I do appreciate any findings, feedback, etc.

17

As a another dev..... Glad to see you back contributing more (than me) again... :slight_smile:

1 Like
18

Wait - this was released? I missed that....

19

Nope, not released yet... but the pre-release code is on GitHub, in the ShellyUSA repo. It's just the "Shelly Device Manager" app there (you don't install the drivers, the app does it for you). So it's pretty easy to fiddle around with if you're so inclined. It's a lot of code lifted-and-shifted from the "Shelly Library" I wrote for the original webhook/websocket drivers, but the design of the drivers is radically different.

The other drivers are basically just the metadata and a library import, with the library doing everything. These are all stand-alone drivers (88 of them and counting). The Shelly Device Manager app queries the devices it discovers on the network, gathers a list of their capabilities (such as "1 switch 1 input"), runs that into a "driver name generator" function that matches it up to a driver. Some things get the same driver, such as all the various "Shelly Plug" models, as functionally there's no difference between "Shelly Plug US" and "Shelly Plug IT", other than the physical form factor of the plugs. They're both a "1 switch 0 input" driver.

Also changed is this uses ONLY webhooks and Shelly Script. No websocket connections. Previous I used websocket to handle things like getting power monitoring reports, but this time around that's handled through Shelly Scripts, as that allows for me to do things like have on-device measurement averaging and variable reporting intervals (to cut down on load on Hubitat).

So it's a lot of reused code, but I have thus far only tested things with a handful of physical devices. Once I make my way through all the various Shelly devices I have on hand for testing, I'll be able to get a proper release out. But since there are a large number of things changed, I'll want to do some actual testing with the devices before then.

I'll likely release it before manually testing every device with a release announcement that includes a list of "tested, known working" devices and a list of "not tested" devices, and mark them off as tested as I can. It's somewhat time-consuming to physically wire up and test each device, as a fair number of the devices I have for testing I don't have permanently installed somewhere in my home. Quite a few, yes. But something like the Shelly Pro 3 EM (400) just isn't something I could even wire up in my home here in Ohio since we run the typical 2-phase 120v/240v AC that all residential in North America does.

3 Likes
20

Ah, thanks for clarifying. I hadn't gone poking around in your GitHub, but I just might when I have some time later this week to play. :slight_smile:

Thanks for working on this (and it is a LOT of work, no doubt).

1 Like