Shelly RGBW2 doesn't respond to Hue commands

I have recently added an RGBGenie ZB-5028 RGB remote to my HE & Shelly RGBW2's setup.
While the ZB-5028 is fully supported & integrated into HE, the RGBW2 isn't, so I am using ScottGrayban's drivers (who is no longer a community member and doesn't offer support).
I am also using MirrorMe app to pair the 4 program buttons to 3 RGBW's and 1 Yeelight CT Bulb.

What works: switching & dimming on RGBW2 & Yeelight, color temp presets on Yeelight.

Problems are:

  1. I have to use Groups to find RGBW2's in MirrorMe
    MirrorMe doesn't show any RGBW2 in the slave device select list (which could be a problem, according to the developers at RGBGenie), so I found here this workaround of adding each RGBW to a Group as Bulb and then binding the respective Group as slave in MirrorMe
  2. color changing on RGBW2 doesn't work!
    This might be due to the fact that ZB-5028 sends the color as Hue value (%) and the Shelly driver only responds to RGB or HSL - later translated to RGB - values

    Though implemented in the driver, the Hue only button doesn't produce any changes in color. Nothing is logged either.

This incompability has nothing to do with the RGBgenie products.

The lack of hue command support in the shelly rgb driver is the main issue, secondarily there appears to be a standard capability missing from this device driver causing the lack of discovery issue in mirror me.

So glad we've got that out of the way! Now it looks more like game over for me...

I won't speak for Mike, or any of the other Hubitat team, but he talks about trying to get these added in a recent chat. (See below)

They may not work with the current Hubitat firmware, or community driver, but I bet it will soon.

1 Like

I don't know about that..I think he was refferring to the Shelly switches and dimmer that were integrated in the latest HE firmware. I didn't catch anything about willing to integrate the RGBW2

I'll look at the code again.

Which capability am I missing ?

Ok so I never coded this in because most people use the colour map option which I did support and does work. You are the first person to ever ask for hue and/or saturation be coded to work.

Is there a reason not to use the colour map?

As I said, RGBW2 color-map changes in HE do work under normal circumstances (changes coming directly from the driver or from a rule - altgough I still haven't figured out the correct custom RGB parameters formatting to include in an action).
However, in my latest scenario, I have an RGB Genie remote that can only send color changes in Hue format and through a Group.
Now, certain people here have been insisting on the idea that this would be a Shelly driver issue, so here I am..

In your case it is the driver limit -- I will code in the hue and sat over the next day or so.

Thank you!! do you also consider the Group binding workaround to be an issue? or should it be left so?!

I never used group binding when testing here since I dont use it.... and again you are the first person in almost a year of this driver being out that has asked about this.

I don't even know what to say about my singularity case....I'm sorry, I guess! :slight_smile:

No worries. I'll have it working by the weekend.

3 Likes

Any breakthrough with this matter?

I started on it but I don't have the time to work on those drivers anymore. They are now opensource and anyone can fork the code and modify it. If anyone wants to make a PR on github I will look at it and merge it if it works.

1 Like

:+1:t3:

I had a quick look at the ShellyUSA drivers.

It shouldn't be too hard to implement setHue and setSaturation based on the way they're structured.

The quick and dirty way: just use the cached values for saturation and level with the existing codepaths, like this:

def setHue(value)
{
    setColor([hue: value, device.saturation: currentValue("saturation").toInteger(), level: device.currentValue("huelevel").toInteger()])
}

The downside of the quick and dirty way is that the Hubitat driver will override the actual device settings with the cached settings in any case where the Hubitat driver is out of sync with the device. You'd be in this state, for example, if you adjusted the settings separately from Hubitat, such as via the Shelly web app, and the Hubitat driver hadn't hit its periodic refresh yet.

To get around this, if it's important to you, you could update PollShellyStatus() to calculate and update the hue, saturation, and "huelevel" attributes based on the RGB values polled from the device, then call it before setColor(), like this:

def setHue(value)
    {
        // updated version of PollShellyStatus() that calculates and updates HSV attributes
        PollShellyStatus()
        setColor([hue: value, device.saturation: currentValue("saturation").toInteger(), level: device.currentValue("huelevel").toInteger()])
    }

FYI, there's a minor typo in the Shelly-RGBW2.groovy driver at around line 632: h = hvsColors[0] should be h = hsvColors[0] in order for hue to be stored correctly, regardless.