Possibly. I only have a Button 1 Blu to play with, so I'm not sure how this plays into things, for the 4 button devices:
Right now Hubitat just gets some JSON inbound like this:
{ "BTHome_version": 2, "address": "MACADDRESS", "battery": 47, "button": 0, "encryption": false, "pid": 225, "rssi": -65 }
I'd need to see how the 4 button ones report in to know what changes need made (if any) to accommodate a 4 button device.
I have a 4 button device, in front of me.
Tell me how to generate the output and I'll send you the results.
Thanks for clarifying the auth behaviour.
"Cover" has been added, also auto-configured as a child device, on any Shelly Gen 2+ device that supports a Cover profile. ... if anyone plans on utilizing this, please let me know so I can make sure it's working properly.
I use multiple 'Shelly Plus 2PM' devices in 'cover' mode using a different driver. I'm interested in moving them across to this driver and can assist with testing. When setting one of the devices up fresh, I see the child devices created, configuration appears successful.
When attempting a command on the 'Cover', nothing happens and I see this error logged.
When using on/off commands on either of the input switches, this is logged. Does it make sense to have these child devices if they can't be used? All commands can be performed from the 'Cover' child device.
Found the issue and put in a fix. Update from HPM and let me know if the "GoToPosition" works. I got your initial error of a null ID being pulled, fixed that. Now I get a message of "Precondition failed: Cover must be calibrated! which I can't do anything about since I don't actually have a cover to calibrate my Shelly 2PM with. But at least it gets the coverId properly so it should hopefully work now.
I don't know what folks will use their Shelly for. Let's say you have a Shelly 2PM controlling a cover, with the 2 inputs being an 'up' and 'down' physical button. You can't have Hubitat physically press the button, thus the "cannot change state of an input" message when attempting to use the Input child device that way, but you might to have a use for a virtual switch in Hubitat that changes its state when the physically device is interacted with. For example, it would be an easy to trigger a Rule for notifications. Or for a Rule like "if open button pressed and 'door open contact sensor' not triggered within 30 seconds -> send alert that door isn't working properly". Or any other thing someone might use it for.
The options for "inputs" on Shelly devices would be a child switch, child button, child momentary button, etc. Since the Shelly is sending "input_toggle" as what's being sent to Hubitat, the closest thing to that is a "switch". The driver should alternatively create input buttons if your shelly is set to "Switch" profile, and the input set to "Button", and you have the Shelly input set up as 'momentary', since that most closely matches a button on Hubitat.
The driver will create missing child devices every time you click 'configure', so while you can delete them if you don't want them, they'll pop back up if you configure the device in Hubitat for any reason. I could add an option to not create them, but that would add a lot of 'noise' to the settings, and the driver would still process the incoming events from the Shelly anyway, so it would only save the most marginal amount of processing on Hubitat anyway. Best to just ignore them if you have no use for them. If there's a lot of ask for a config option to have them not be created, I can add it, but my personal preference is to just ignore them if I'm not using them.
If you have a Shelly device setup with my driver, it should spit out stuff in the logs when you press a button. For example, here is what I see from my Shelly Plug US log, with it setup as a Bluetooth Gateway in the driver options:
Shelly Plug US: BTHome Event Data: { "BTHome_version": 2, "address": "MAC ADDRESS HERE", "battery": 33, "button": 1, "encryption": false, "pid": 61, "rssi": -65 }
Feel free to skip posting the MAC address... that's (very minorly) sensitive since it's 'sniffable' over the air and could technically reveal your location... tho anyone able to 'sniff' it would already be within 100 meters of you anyway... but still, best not to post.
Press all 4 buttons and post the logs you get with each press, and I can see what might need done to accommodate in this driver.
These are "trace" level messages, so you'll need to turn on the logging options for that too in order to see them. And if you're enabling the bluetooth gateway for the first time on the device, the Shelly needs a reboot before that actually works.
Found the issue and put in a fix.
Working now! Tested Open, Close, Set Position, Start Position Change, Stop Position Change - all working, no log warnings or errors.
I don't know what folks will use their Shelly for.
Thanks for discussing. I realise now the child switches represent the state of the electrically connected switch, so they certainly serve a purpose. The generalised approach makes sense, thanks.
State
I notice that there is no state exposed at present. Do you have a plan to implement that? For the WindowShade capability, position and windowShade are needed. I use position for conditional button operations and it's needed for the driver to work right with HomeKit as well.
Unintentional. Glossed over it... added in state for both Gen 1 and Gen 2+ cover devices. Gen 2 requires 'calibration' before reporting any sort of position, so I can't say for sure it's working, so let me know. The documentation on Shelly stuff is pretty solid, so it should be working.
Update on HPM with a new driver: Shelly 2.5. With this driver added, I've also expanded the library these drivers use to fully support gen 1 and 2 'cover' devices, so that means I'll be able to add any other 'cover' soon with minimal additional work.
Fixed a few power monitoring relating bugs I found as well, and added a power monitoring cover device for gen 2 devices that have power monitoring reports on covers. If you already have a gen 2 cover device that doesn't have power monitoring and would like to switch this option on, you'll need to manually swap the driver your cover child device is using to "Shelly Cover PM Component", then press configure on the parent device. Make sure power monitoring is enabled on the parent as well.
Added support for Shelly Dimmer 1 & 2 in version 2.2.0. Also added Shelly Vintage since it's also a Gen 1 "Dimmer".
Hub platform is 2.4.0.150
HPM is V1.9.3
Update via HPM consistently fails.
The solution is to use Repair instead of Update.
This works very well.
Interesting... I've ran into some trouble with HPM before. Do the logs give any indication what's wrong? Wondering if it's an issue with HPM or something in HPM packageManifest.json that might be causing it.
I think that's the issue where HPM gets stuck trying to upgrade a driver and can't, and if it's the one I'm thinking of, it clears up after a hub reboot. Or just using repair.
Nope. The reboot does not clear this condition. The Repair works but after the Repair id done the Update is not longer available. But most likely it will not work either because my attempt to update driver failed twice for two recent sequential updates. And second attempt was done after Repair of the first failed one. And sure, it was number of hub reboots in between.
UPDATE
Today's attempt to upgrade package to the latest version failed again after successful Repair yesterday and today's hub reboot. Repair worked as expected. Since for a long time I did not update anything via HPM (no updates are available) it is hard to say if this problem is a general HPM problem, introduced by recent platform updates or just related to this specific package.
Good morning, first of all, thank you very much for taking the time to do this.
On the other hand, I have installed your driver for a 1 gen Shelly dimmer, everything works as expected but I don't know where to see when a button is pressed, with the previous driver I could see it.
Is it correct that this driver did not create children and everything is on the same device?
Regards.
Good morning again, I also installed a device with a Selly Plus 2 PM and this one installs the child devices to control the presses of the switches. Did I do something wrong with the Shelly Dimmer 1 device?
Regards
Looks like I needed to put in a bit more code for handling inputs properly on gen 1 devices that are 'light', rather than 'relay'. Should be fixed with the latest version on HPM.
Ok, this fixed the problem.
I have installed the driver for a dimmer 1 and the driver for a shelly plus 2 PM for two light channels. I'm going to leave it for a few weeks to check its behavior, but at first I would say that they consume half the resources of the previous drivers.
I have a C5 with more than 70 devices and a lot of rules and I try to keep the resource consumption low.
Thank you very much for your work.
Regards.
New version on HPM with support for the Shelly TRV.
Now, I do not have a radiator... so I can't thoroughly test it. I do have a Shelly TRV on a radiator valve on my desk, and that gets me most of the way there for testing.
Since I can't actually put this driver in use in my house, I had to take a few guesses at what might be useful, but I'd definitely welcome feedback/requests to make it better.
The Shelly TRV has a TON of options, and as per the usual on the drivers here, I only added a few of what I thought would be the most useful ones on the device driver preferences page. There's a preference for temperature offset, automatic temperature mode, enabling/disabling the external temp sensor endpoint, display brightness, and temperature units.
For the commands and attributes, it's got the temperature from the TRV, battery, and valve position (0-100% open). There's a command to set the heating setpoint (which also puts it into automatic temperature mode), as well as valve position (which takes it out of automatic mode).
There's also a command for "Set External Temperature", which I added for use with Rule Machine. What the command allows is sending external temperature sensor readings to the TRV, like this:
Please let me know if there's anything buggy, anything needs added, or any other feedback.
THanks for the great work @daniel.winks, one little thing to assist debugging is that the drivers should send an info log when a action happens, by default normal logging shows no info from your driver, but it seems most others do.
Download the Hubitat app
