Hey there,
I’m considering the red series on/off dimmer switch for a Hue setup. Can the dimmer be set up to control the Hue lights dim setting, with the proper hub?
Thanks for your help.
Yes it’s compatible. Disable the local control then enable the scenes functionality. Since it’s a On/Off switch you would not be able to press and hold to increase or decrease the lights but you can do the following with scenes:
[1XUp = On // 1XDown = Off]
[2XUp = increase by 15% // 2XDown = decrease by 15%
[3XUp = 50% // etc
No dimming, even with the dimmer model?
With ST, you’d be able to do a “mirror” using Smart Lighting but expect a lag. Also, there might be issues with levels. Not sure about using Hubitat though.
You’ll need a (more) custom driver, but with Hubitat you can definitely hold the paddles to dim. The device sends Z-Wave events on holds and releases; Invoelli’s driver just only uses the release. I’m working on a modification that I’ll share when they get the apparent child-device issue sorted out. What you’ll do is map the hold (beginning) to a startLevelChange and the release (end, actual release—a button event Hubitat supports) to stopLevelChange. This is also possible on the switches and is what I’m doing.
EDIT: I should also add that I just put two LZW31-SN dimmers on different sets of Hue bulbs and disabled the relay (and left the dimmer at 100%, or 99 in Z-Wave speak). I’m concerned that they don’t “like” being on the dimmer–they seem to flicker a bit when I turn the Hue bulbs on (from Hue; the Inovelli remains on the entire time). Is a dimmer at 100% with the relay disabled really identical to a switch as far as the load is concerned, or is the electricity still being modified in some way like a real dimmer does, possibly in a way that some loads may not like? I also needed the neutral, which I was hoping wouldn’t be a concern with the relay disabled and a load <25 W (seems like that should only be an issue when off since the circuit should be completed via the load all the time then), but they didn’t like that either and kept flickering when on if I could even get the switch to stay on.
@EricM_Inovelli already gave the code to expose the hold events and I’ve been using it for some time. I use SmartThings though so the latency isn’t worth it. Like you said though, release is already button 6. In the code below, hold would be button 8.
From @EricM_Inovelli in another thread:
"So technically you could add this into the central scene method (case 2 & break shown for reference):
case 2:
createEvent(buttonEvent(8, (cmd.sceneNumber == 2? "pushed" : "held"), "physical"))
break
This would create a new button event (8). The mapping would look like this:
8 pushed -> top button held
6 pushed -> top button released
8 held -> bottom button held
6 held -> bottom button released
And also you would need to change this in initialize to register the extra button. I will probably include this in the next device handler release. Since SmartThings doesn’t have events based on “released” I’m just parsing the events as another push & held event.
sendEvent(name: "numberOfButtons", value: 8, displayed: true)"
1 Like
I posted my modifications for the switch on the Hubitat forum a while back—I prefer to use pushed and held (and released on Hubitat) events for their intended purpose and not a way to distinguish the different paddles, so I also made modifications for that; the tradeoff is that you need to do a bit of “button math” (e.g., taps up are odd numbers 1-9, taps down are even numbers 2-10, and the config button is button 11; this at least aligns nicely with non-scene switches from other manufacturers where up is usually button 1 pushed and down is usually button 2 pushed). This also frees up “held” to be used for its intended meaning, and on Hubitat you can also make use of “released” (like you, I also wouldn’t bother on SmartThings given the cloud latency on a good day, even though you certainly could by faking it with yet another different button event). Either way, of course works!
I posted a similar modification for the dimmer to my GitHub in case anyone is interested: https://github.com/RMoRobert/Hubitat/blob/master/drivers/inovelli-dimmer-red-series-lzw31-sn-releasable.groovy. Haven’t tested this one much to see if I messed up anything yet, though. 
1 Like
Not sure what you mean by the above quote. Care to explain?
Also, how did it using the on/off as a dimmer for zigbee (hue) bulbs work out for you?
To my knowledge, ST doesn’t have a button “released” event, but you could make it “button X pushed (or held)” or something, which is I think exactly what you were saying Eric said in post 6. But the other trick would be to get ST to do something with those events. Hubitat has a startLevelChange(up) and startLevelChange(down) command you can use, paired with a stopLevelChange command; typical use would be to call one of the first two on a hold up or down and the second on release. This simulates a “real” dimmer where holding the paddle dims the load while held (except it sends software commands to the bulbs to do that instead). I’m not sure if there are are similar commands on ST (or if you could fake it with webCoRE or similar), but again, with the cloud latency, I’m not sure how reliable it would be.
On Hubitat, I find it to work quite well with Hue bulbs. I don’t do it much—I mostly rely on automations and Hue scenes to get where I want—but it works about as I expect. I am a little worried, as I mentioned above, about using these bulbs with the dimmers, though. It seems like they’re acting a bit funny (flickering when turned on—all via commands to Hue, not the Inovelli dimmer which is always on with local control disabled). I would have used the switches but wanted the bigger LED notification bar, and I figured they’d act identical when the relay or local control was disabled. Still wondering if anyone else has that problem, and I might start a thread soon if a search doesn’t reveal anything.
I just got Hubitat and set this up. Works fine with the On/Off although there is a delay before it starts dimming and stops. However, that delay is with every action of the switch (turning on/off etc) so I’m pretty sure that it has more to do with the On/Off firmware delay. Hopefully, they reduce that at some point.
To be honest, I’m not really seeing faster speeds using Hubitat. I had expected to see decent differences in scenarios where scenes were sent to the Hub but it now seems the delay was more the bottleneck than SmartThings (maybe ST worked fine because I have 1Gb internet though). It’s interesting, I have my GE switch in a 3 way with one of the Inovellis and I use associationGroups to pair them. The speed in which the GE turns on the Inovelli is much faster than the other way around.