Shelly Device Handlers for Hubitat

I have found the issue.
I am using Maker API to update the device in Hubitat when I hit the hardware switch by hand.
This does a refresh of the device in Hubitat
The reason for that is I always want the correct status on my dashbord (and for my rules) without using the "Device Refresh Rate" function
In the OFF and ON URL of the shelly's I have filled a link like this :

I think this is causing lots of traffic on the hub when it is trying to send the messages to turn off the devices...
When I turn all the devices off using the app, the hub is not doing citical stuff, it does only a refresh of the devices.

When I remove those links I can switch off all my +20 lights very fast (1-2 sec) , but in case of switching the hardware switch by hand the status does not update,
It looks I need to make some choices... :sob:

That’s the big difference in the drivers I wrote for myself, I use the action urls to report on/off status directly to the driver instead of polling via maker api. The same goes for temp and door/window so they can be used without mqtt.

To be fair this is a relatively new feature in Shelly firmware and was not available when the drivers in this thread was first released.

2 Likes

I dont understand why you need to update the status using makerapi.

If I have a rule or a dashboard tile and I switch on a device the status is automatically refreshed. My code is written just for this issue.

Now if you are mixing both the hub and shelly app to turn things on/off then that's not going to work well. Choose the app that's is going control lighting... HE should be the default for this not the shelly app. If you want to use the shelly app to control devices then my driver isnt for you... and I'm not going to rewrite them just for the mixed setup you want to use.

All the relay's are behind and connected to the original switches, My wife and 3 kids are walking in the house and using those old switches, they are not using apps (Hubitat nor Shelly) to switch the lights on/off, that's the reason why I do the refresh...
Don't worry, I don't expect or ask to rewrite your drivers :grinning:

2 Likes

ahhh I never thought about that... ok I really don't have a good solution for that. How many devices do you have ?

9 x shelly1
4 x shelly1PM
11 x shelly2.5 (1 is a rollershutter)
4 x shellyplugS
When I turn Device Refresh Rate ON, my rules has strange behavior, even there are no 50 devices...

What sort of behaviour? Does it happen even if you use the fresh rate on just 1?

I had 2 rules, (1 nothing to do with shelly) where the status of the device in the rule was sometimes not equal to the status of the device on the dashboard, the status on the dasboard was the correct status, very strange. The idea of my troubleshooting was, maybe the hub is under stress by refreshing al the stausses all day long (each 30 min). The moment I turned of the polling I did'd noticed the issue anymore.

Hmm I'm not seeing this on my end Bruno... Have you got any other info like the rule you are using for the shelly devices?

This rule, nothing to do with Shelly (+ a similar for the garage door)
The issue was the door was sometimes closed on the dashbord (real status) but the status in the rule was True on the moment when there was a (false) alarm

In this rule the status of a device (could be any device) was ON but not equal to the status of the device on the dashboard (real status). In that case the rule was not working as expected.
Refreshing the status of the device was not a solution, the only working action was switching the device to ON and OFF


Both problems occurred not all the times, but sometimes, I was not able to simulated the problem...

In the mean time I have changed both rules because I was thinking they put some stress on the hub to, My goal is keep everything small and simple to save the resources of the hub...

1 Like

So that device in that rule is the window/door sensor ?

Correct

@Evilborg, playing with the name functionality
Maybe you want to know, but maybe I see it all wrong:-)
Shelly 2.5
When you use, "Give your device a name" & "Label your relay control" everything is OK for channel 0
When you fill in the relay label in channel 1 it deletes the "device name" in the relay when you save the device. There is not a possibility to fill in a "device name" in channel 1 (I understand why) but I think It should not delete it or adopt it

ShellyPlugS
There is no possibility to fill in a relay name in the device but it exist in the ShellyPlugS.
Not a big deal because the relay name is not deleted when you save the device


I fixed this in the code -- version 3.0.6

Most likely will not add this.

1 Like

Shelly Relay v3.0.6 released.

  • Added VoltageMeasurement for the 4Pro input voltage
  • Fixed a issue where the ntp server and devicename would be deleted if the relay # was > than 0
2 Likes

Any driver support for either a Shelly 1 or Shelly 1pm with an add-on Shelly module which supports from 1 to 3 external temperature probes.. HUBITAT recognizes all of the Shelly features but apparently ignores the output created by the probes.. The tile for temperature displays "unknown" for both the 'device-name' and the 'device-name channel 1'.. Any help would be appreciated..

1 Like

You're kidding right ?

1 Like

Are you sure you are using the community driver and not the embedded official one?

Supported devices are:
1/1PM/2/2.5/EM/Plug/PlugS/4Pro/EM3/SHPLG-U1
Changes:
3.0.6 - Added VoltageMeasurement for the 4Pro input voltage

  • Fixed a issue where the ntp server and devicename would be deleted if the relay # was not 0
    3.0.5 - Added support for the Shelly Plug US
    3.0.4 - Added support for External Sensor Hat for the Shelly1 and 1PM
2 Likes

@Evilborg

I am getting a repeating error whenever i add a shelly switch (using your driver) to the Hubitat google home app. I havent tried the stock hubitat driver yet as yours works great otherwise.

I'm not seeing this in my logs. What shelly device is it?