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.
