What version of HE are you on? If it keeps being a problem you could open up the zip file and import each source file manually.
C7 with 2.3.7.145.
File (link) in this post worked: Shelly Device Handlers for Hubitat - #540 by dmitry.rozovik
However, there was no 'success of import' message of any kind. It just sat there for about 5 minutes until I hit cancel on the import... It then refreshed the screen to show a the drivers were imported as a bundle.
There is no loggin whatsoever in the log files so agree with @dmitry.rozovik that troubleshooting is hard.
YES.. this one worked!
Also see: Shelly Device Handlers for Hubitat - #542 by user3491
Thanks Dmitry!
hmmm, did some tests, I think the update delay is not working well.
Settings and device are saved after the new driver, "Update health status in (S) if link failed" is 60 seconds. Health status stays online
Thanks for the report! I will investigate the case.
Driver is updated:
- Added new component support 'pm1' for 'mini PM' devices
- Other internal maintenace changes without significant impact on general behavior (no need to update driver for this one)
Driver is updated:
- Fixed health status check (needs real world testing)
2 Likes
it looks fine, thx
2 Likes
@dmitry.rozovik Thanks for your efforts to support Shelly devices! I've been trying out different drivers for the Shelly Plus 2PM in cover mode and your driver is working well. Having the child devices is making the most sense and enabling the behaviour I'm looking for.
I have a question about HomeKit integration related to this device. Is there anything you're aware of that may be missing to enable the 'cover' to operate properly with HomeKit? What I'm experiencing is the window shade button doesn't represent the right state (open/closed) and although I can initiate the cover moving to a mid-point by tapping the button and then sliding in HomeKit, the button immediately jumps back to open even though the physical cover moves to the requested position. I'm not sure where the problem is, but I'm starting here to track it down. The state in HE is correct while this is occurring.
In this case the cover child device is exposed to HomeKit:
Window Shade
Dining Room Shutter Relay cover 1 (in Dining Room)
Export as: Normal (0 = closed, 100 = open)
Required capabilities: Window Shade
I have no info on HomeKit integration. But I'll try to check if there is anything in the Window Shade child device that needs to be additionally configured (like operating modes list for thermostats)
P.S.: One thing that come to my mind right away is a scale factor: Could it be that HomeKit expects [0..1] range while device provides [0..100]? In this case anything more than 0 could be threated as 'open' state
1 Like
One inconsistensy/error is present in the driver related to the window shade:
Driver sets windowShade attribute value directly from the device report. But device has state 'stopped' that should be mapped to 'partially open' as listed in the attribute enumeration.
Not sure if this one can be the cause. Will fix it shortly.
1 Like
I'm new to the forum. I have 4 x Shelly 1's that work well with the HE system driver.
I've just added a Shelly Plus 1 and I noticed that no child device (switch) is created. I've read this thread which is great and downloaded the Switch Relay Driver 3.0.10. I can see new attributes in the parent device when it is polled, but alas no child device.
Can someone steer me in the right direction please?
I found a clue in the Shelly Technical Documentation. By running /rpc/shelly.getdeviceinfo, I get a JSON returned that contains:
{
"name": null,
"id": "shellyplus1-441793d6xxxx",
"mac": "441793D6xxxx",
"slot": 0,
"model": "SNSW-001X16EU",
"gen": 2,
"fw_id": "20231219-133950/1.1.0-g34b5d4f",
"ver": "1.1.0",
"app": "Plus1",
"auth_en": false,
"auth_domain": null
}
I note that the Shelly Switch Relay driver code doesn't contain a code for this model? Does that mean that this driver doesn't support Shelly Plus 1 and if so, is there another driver or resource that might help me?
Tim
The one that has version 3.0.10 is the driver for Gen 1 devices. I can't say if it will work with your Gen 2 device. Some Gen 2 devices have a bit of backward compatibility.
The driver in the PLUS subfolder should be a better choice (version 1.0.2).
All those drivers have no 'child device' functionality and operate as an instance-per-component. I.e. if for example you have dual channel device you'll need to install 2 device instances specifying channel id for each of them. In your specific case you have a single channel device, So you need only a single instance of the driver.
The one with child devices is a different driver from different repository, and it's referenced in the thread later.
1 Like
Thanks for the detailed reply Dmitry - I'll take a look.
I have had success (simply turn on/off the relay) using the ShellyPlus Generic driver from Sebastian Yepes: https://raw.githubusercontent.com/syepes/Hubitat/master/Drivers/Shelly/ShellyPlus%20Generic.groovy
Thanks Bruno, I'll check it out.
I'm starting to use Hubitat Package Manager and realising that there are many contributors that aren't in the HPM list of repos.
1 Like
This is quite nice clean code driver.
It's is not as generic as the one that Bruno had referenced as it is specialized for 2-channel devices. And it is poll-based so if device changes it's state by some external event/condition it will not report immediately but only after poll interval.
The main drawback is that only a first channel for dual-channel devices is available to dashboard due to the use of on/off default value for the channel index - dashboard cannot provide channel index. And RM will require custom actions to do that.
This driver is Gen 2+ and has no channel limitations. Child devices spawn accordingly. (no addons support yet)
It has live event stream from device so it gets events instantly (like button/switch interactions).
There is unbound input support (including "Button Controller" application compatibility) and script interaction support.
With Shelly scripts you can do additonal dashboard tiles with custom information and virtual actions (scripts are presented as virtual switches with start/stop = on/off and few attributes for getting events back)
Allows to adjust voltage/amperage/etc thresholds per child device to avoid event spam and adjust to any specific case accordingly - Shellies with live event stream open can be quite chatty.
1 Like
Driver is updated:
Added 'em1' component experimental support (Shelly Pro EM and Shelly Pro EM3 in monophase profile mode; some 'mini' devices also fit here)
Fixed 'cover' component mapping for 'stopped'/'partially open' state.
1 Like
Thanks for updating this state mapping, I appreciate it!
I've looked further into the HomeKit issue and I don't see it relating to the driver implementation. With a virtual driver synthesising position and windowShade (state) attributes, I experience the same issue. I'll post elsewhere to try and investigate further.
