There's debug and trace levels that can be enabled. Debug spits out a fair bit of stuff, and trace gives an absurd about, down to what http request was sent, what command via websocket, and everything coming in via 'parse' or websocket.
But yes, I will likely break out some messages at info level once I've got all of the Shelly devices supported and this driver package is 'mature'. Right now there's an option toggle for "Enable Logging", but unless you also select debug and/or trace then there's nothing logged, since almost every log is written at debug or trace level, aside from a few warning/error ones (which show up regardless of whether "Enable Logging" is toggled on or not.
Appears to be working well except for one scenario. If the cover is stopped partially open (via 'set position' or 'stop position change'), the windowShade
attribute reports opening
or closing
instead of partially open
. From what I can see, there needs to be handling of the following stopped
message, and inspection of the current_pos
value.
When you get to this, I suggest consolidating the logging options to a single 'log verbosity' option as done with the Ikea drivers.

did not work for me... the error message i have
when i try to update the Shelly Blu drivers, it gaves this error message:
Error Occurred During Installation
An error occurred while installing the package: Failed to upgrade driver https://raw.githubusercontent.com/ShellyUSA/Hubitat-Drivers/master/WebhookWebsocket/ShellyGas.groovy. Be sure the package is not in use with devices.
I am getting this too
@daniel.winks I have the Shelly Gas driver installed and tried updating the driver manually via Import and I get the following error:
1] @ line 1699 (library ShellyUSA.ShellyUSA_Driver_Library, line 1664), column 1. Repetitive method name/signature for method 'void open()' in class 'Script1'. @ line 30, column 1. Repetitive method name/signature for method 'void close()' in class 'Script1'. @ line 33, column 1. Repetitive method name/signature for method 'void open()' in class 'Script1'. @ line 1699 (library ShellyUSA.ShellyUSA_Driver_Library, line 1664), column 1. Repetitive method name/signature for method 'void close()' in class 'Script1'. @ line 1712 (library ShellyUSA.ShellyUSA_Driver_Library, line 1677), column 1.
This is is the cause of the error that @Pedro.Jesus and I are getting.
Thanks! I forgot to move those commands into the main library when I added some stuff for 'cover' open/close commands. Fixed with the latest version on HPM.
2 Likes
great. Now it works!
Upgrade done. i will let you know in the meantime about all the other things, how is the beaviour with this updates.
thank you very much for all you work.
Good morning, I have 2 PM plus running with these drivers, one as a blind and one as a cover.
When I installed them they worked fine, but after a couple of days the Websocket connection remains disconnected and does not connect anymore.
I am getting the position data via API on both devices, but the Websocket connection never opens.
The Window Shade data is not getting either.
I disabled all the power reports that I do not need to lower the number of reports and the use of the hubitat processor, I also changed the device name and device label names.
The logs and the records have stopped showing information, they only show some information on the children when a rule is executed.
What do you think could be happening?
This is from one of the parent devices
So if you don't have the Bluetooth Gateway enabled, and you have Power Monitoring off, there's technically no need for Websocket since the web hooks will do everything you need with less load on Hubitat... However, it looks like the driver isn't properly creating hooks for the cover.stopped
, cover.open
, and other cover related hooks. Give me a bit and I'll figure out why it's not populating those and I'll put out an update with a fix for them. Once that's working properly you won't need websocket connected for the shade data to stay updated.
Great, thank you very much. In my specific case, for its use as a blind and as a cover, I don't need the consumption data or Bluetooth. And I do need to lower the resource consumption that I had, so it's ideal to have it as I have it.
Thank you very much for your comment, and for working on the update, through API, right now they are very functional for me, I'm sure you will polish them with the reports that we send you.
Regards
Alright, put up an update on HPM with a few changes. If you click "Configure" it should create a few webhooks for the cover actions:
With these, as the name would imply, there's hooks called whenever the cover/shade is closed, closing, open, opening, or 'stopped' which should be 'partially open' in Hubitat terminology. None of the available actions on the Shelly provide a 'position', so right after the hook is called on Hubitat, Hubitat calls a Shelly.GetStatus
command on the Shelly, which reports back with all current status, including current_pos
if the device has been calibrated. I don't have an actual window shade connected to my Shelly 2PM, so I can't test that for sure, so let me know if there's anything else not quite working as you'd expect.
1 Like
Thanks! After the update the windowShade
attribute is updated correctly.
Based on your comment a few posts back, you mention cover mode shouldn't need Bluetooth. However, if I disable it and hit Configure, after that the position
attribute doesn't update. In the logs there is no response to the Shelly.GetStatus
call, whereas with Bluetooth enabled there is.
In general, what is the functionality that requires Bluetooth? The driver has it enabled by default.
It's used for relaying messages from Shelly Bluetooth devices, like the Motion Blu, Door/Window Blu, etc. If you don't have any of these devices, it isn't needed.
I'll have to check to see what I've missed here. It should update regardless, just using a webhook to know when the cover starts/stops moving, and as needed, a single status query to the Shelly device to get the current position after it stops moving. Give me a bit to figure out what I need to fix and I'll get it working both with and without Bluetooth enabled (which really is just 'with websocket vs without', since enabling bluetooth also enables websocket).
Websocket is good when needed, but if it's just something like a window shade that only moves a couple times a day and otherwise just sits idle, maintaining a websocket connection 24/7 just to process maybe 10 messages a day is a bit wasteful of resources.
Patch up on HPM that should hopefully fix it. Looks like I had it getting the current status when the cover stops moving, but didn't have a 'follow on callback' set on the async call so it wasn't being sent to parse the response and update the status on the Hubitat device.
Thanks, that's working now. I've moved a couple of devices across onto this driver and will try them out over the next few weeks.
Results have been positive using this driver with a couple of Plus 2PMs controlling shutters. Everything is working, no issues. 
Feedback from moving a few other Plus 2PMs across:
- When adding and searching virtual devices, nothing is found when searching 'plus 2pm'. I assume this is because it's listed as '...Plus 2 PM...'. I suggest using advertised product names.
- When setting up and entering IP address, no Bluetooth enabled option is present, When saving it then becomes visible and is enabled. As the Shelly had Bluetooth off, it then requires a reboot. When disabling the Bluetooth option (not needed for cover) it remains enabled on the Shelly.
- Also when setting up, power monitoring is enabled automatically (as above). This then causes the 'Shelly Cover PM Component' to be used.
On the last two points, do you have any thoughts about making the setup more opt-in so capabilities can be enabled if required? Using the 'Plus 2PM' in cover mode means I don't need power monitoring or Bluetooth.
It would be helpful to document the approach used in the driver to support Shelly features. This would help inform and put users in control. Things like, this is how you enable power monitoring, this is how the driver reacts, it adds these capabilities/attributes and requires these Shelly options to be enabled. I previously asked about the need for Bluetooth, and it's to help with questions like that. I can contribute to this if it would help.
1 Like