Here you can see a Gen4 creation failure and a successful creation of a gen2
I'm not sure what's not working for that, but it seems like it's either an issue with your specific device or maybe your network. I ran a test on a Gen4 plug on my C8-Pro running SDM 1.0.99. I removed the device, added an auth password, then added it. I repeated it twice without an issues: https://imgur.com/a/FC0YrJU
Can you PM me a copy of the full logs, trace level, so I can check to see if there's something there that might point to an issue.
All, a factory reset of the device has solved the issue, thanks Daniel for the effort and the support!
What does the "powermonitoring_pm" script exact do that has saved in the device?
So Shelly devices have "rpc channels", which includes websocket and a few others. The only rpc channel that Hubitat can connect to is the websocket channel. All power monitoring reports emit an event each measurement to all rpc channels.
If Hubitat connects to a Shelly via websocket, so it can receive those events, then it gets them ALL. There's no configuration on this, no options, nothing. And it's VERY VERY chatty, like multiple messages per second levels of chatty. Which, Hubitat not having a ton of CPU power, even on a C8-Pro, means that if you have 10 or 20 Shelly devices all doing PM, then you'll pretty quickly eat up a significant amount of CPU time on Hubitat.
So what the powermonitoring_pm script does is it subscribes to the rpc channel internally, on the device. It has a series of 'accumulators' and configuration settings (like reporting interval, change delta to report, etc, set on the Hubitat device preferences page). Then the script runs, on device, accumulates measurements, does a time-sliding average or whatever other averaging/summation makes sense for the particular measurement, such as voltage, watts, amps, etc. Then the script sends that to Hubitat at the configured reporting interval.
On something like a Shelly Power Strip, this reduces the load on Hubitat by 95% or more for that device. Probably 99% reduction if you're not interested in frequent reports and set the interval to something low, like every 5 or 10 minutes.
A clever solution for this "chatty" problem, I’ve often wondered why I can’t disable these power readings on the Shelly. I’m curious about the impact on my network; after all, the data is still being transmitted across it. With your clever solution, Hubitat no longer listens to them, but I assume the packages are still there?
I also notice in your app that you display the Shelly’s online/offline status; is this status available via the healthStatus attribute?
Nope, it's not.
So with these drivers, we're not using Websocket at all. There's some webhooks set up, so if you turn the device on/off outside of Hubitat, the device sends an HTTP request to Hubitat to let it know. Then there's a scripts, which, based on their intervals, accumulator values, etc, also do HTTP get request to Hubitat. But since we're not subscribing to the Shelly RPC channel via Websocket, the power monitoring messages just exist on-device. They report every second internally, then that's averaged/accumulated, and then every minute, every 5 minutes, whatever you have configured, it transmits them to Hubitat. Until that happens, there's no network traffic.
Nope, it's just a pretty basic timer. If it's be X amount of seconds since the device emitted an mDNS message then it gets marked offline.
Hi @daniel.winks, thanks for your work on Shelly Device Manager.
I encountered a device-creation issue with Shelly 2.5 Gen1 units in roller mode on v1.0.100: the app selected and registered the cover driver, then reported “No driver available.”
With AI assistance, I traced this to the discovery record being overwritten after driver selection and prepared a small fix. I also made cover-status improvements and added optional Dimmer tile support to the Gen1 and Gen3 single-cover drivers, allowing the slider to show/control opening percentage while retaining native shade commands.
The modified app and both drivers are working on my hub with Shelly 2.5 Gen1 and Shelly 2PM Gen3 shades.
I’ve documented the findings and linked the code in GitHub issue #101. The bug fixes and optional dimmer enhancement are described separately.
Happy to help with further testing.
Amit