Shelly Device Handlers for Hubitat

Allterco Robotics is pleased to announce that we've been granted transfer of copyright for the popular Shelly device handlers for Hubitat Elevation authored by Scott Grayban:

This public repository hosts the latest editions of the device handlers, including several released here for the first time.

If you're using older copies of any of these, we recommend you update in order to maintain the version check feature's functionality.

These device handlers are freely available under the Apache 2.0 license - you're allowed to clone, fork, or create any and all derivative work based on the device handlers, as permitted under the terms of the license.

We'd like to take this opportunity to thank Scott for his contribution to the community. Moving forward, Scott will not provide support for these device handlers, but we hope to see an engaged and enthusiastic repository grow around this donation.

We also thank our friends at Hubitat for providing this fantastic platform our mutual customers enjoy and for the work you've put into native integration for the Shelly 1, 1PM, and 2.5 relay products.

Thank you!

11 Likes

Just tried the Shelly Duo drivers for a Shelly 2.5 and can't seem to get it working.

I've tried both changing my existing device as well as creating a new one. New device did not create child devices, haven't looked through the code yet, so I'm not sure if it's supposed to do that.

The shelly 2.5 is on a different VLAN than my Hubitat, but works fine with the built-in driver, except for the switch state reporting.

edit: found my problem, Shelly Duo is a bulb. Playing with the Shelly Switch driver now and seems to be working. Note to anyone else: this doesn't create child devices. You create a separate device for each channel and specify it in the device preferences

1 Like

This fixed the issue for me on different vlans...

Thanks for sharing your process with this.

Because of your experience, I've updated the README file to explain what products are used with each device handler. I should have done this before sharing the repository but I was very anxious to get it into your hands.

1 Like

No worries, I don't mind being the guinea pig.

[quote="hovee, post:3, topic:43756"]
This fixed the issue for me on different vlans...

Wow, wish I had seen that before today. New drivers seem to be working well though.

I'll add in a vlan option setting for this problem... not sure how HE will handle duplicate DNI though.

You talking to me ?

Yes, sorry, didn't reply to your post directly. You can't have duplicate IPs, for that source port needs to also be taken into account. That can be messy...

Hmm is there a work around you know of ?

That people who use VLAN has to map their IPs 1 to 1 and not many to 1. Or route without NAT. Either that or fix source port, which is not an option in most equipment.

EDIT: With the few that need this, it has never been an issue since commands need to be sent to the device on different IPs anyway. Then just set the ID to that same IP. Some have needed to change their network, but it is for the best anyway.

@Evilborg These drivers seem to work fine across VLANs. It's the Hubitat native shelly driver that has the issue.

I don't have a lot of variety in my VLANs - 192.168.1.XXX, 192.168.20.XXX, 192.168.40.XXX, 192.168.60.XXX, and 192.168.80.XXX - but I've got no problem with either my C4 or C5 controlling devices on other VLANs. I've had no problems with either these device handlers or with native integrations.

ok

Refreshing device state worked for you with the native driver? There were quite a few reports from people saying they were able to control it fine, but the switch state would not update.

I think Doug was referring to our drivers not the HE ones.

I'll take a deeper look next week.

Since I switched over to Unifi, my network has been a lot smoother and a lot more in line with my expectations. My VLANs never worked right with DD-WRT. i actually gave up trying a couple of years ago.

1 Like

Everyone that uses Hubitat Shelly drivers you need to re-import them from the new repo -- version checking had missing params throwing errors that i had to fix... no version bump.

1 Like

Hi Scott / @Evilborg

I've always used your drivers and integrated my shelly devices with Alexa through the "Amazon Echo Skill" official app, after the discovery process, Alexa always recognised the devices as switches, and that was good (I only have Shelly as relays for now).

Today I had to delete all discovered devices and restart the discovery process, it was months I didn't do this, and after it completed, I noticed that ALL the devices were being recognized as "Temperature Sensor", not as a switch, so I cannot use them anymore.

I don't know if this could be due to the Amazon Echo Skill app or the latest version of the driver I reimported some weeks ago after reading your post, so I thought to ask for your advice.

Thanks for any suggestion you might give me.

UPDATE: I tried switching one of the shelly devices to the official HE driver and after the discovery, Alexa correctly recognised it as a switch. So I'm sure there's some issue with the alternative driver. :frowning: