Ah, yep. That was the problem. I switched them and it works as expected now. Thanks!
2 Likes
Has there been a change in the way the Disable Local Control is presented in the Hubitat driver?
Using a Red Series dimmer here that previously worked well with CoCoHue and Hue colour bulb. I did a driver update to a June version and only had time now to troubleshoot odd behaviour.
Now I see the disable local/remote control switches are gone, only the drop down option remains and there’s some sort of “smart bulb” option that I can’t find documented.
I think my previous setting of disabling the local relay was reset until I did the eight clicks of the configuration button. It still reverts if I configure from the Hubitat device page.
I don’t believe that it has changed in some time. It has been a drop down for as long as I remember. There is a child device option that is a true/false setting.
With the latest driver if you set local protection via the Hubitat interface or via the switch it doesn’t matter. Either way will work.
Thank you Eric, I was able to read up on the Smart Bulb Mode a little more in the 1.47 firmware post. I found the following screenshot that illustrated the duplicate menus. I’m glad it’s been cleaned up now!
1 Like
Is there a way to set up different ramp speeds for on vs off from the physical switch?
I like having on set to 0 - nice and quick, but would like off to be set to 1 or 2 - to give a nice little fade as you’re exiting the room.
Any quick and dirty ways to edit the DTH to make this happen?
IDEA: simply set the ramp speed for the zwave parameter (I think that’s parameter3) to 1, and then set the physical ramp speed parameter (I think that’s parameter4) to 0, and then add the appropriate code to use parameter3’s setting when issuing an off command (instead of parameter4’s setting) when using the physical paddle. I poked around in the code for a but, but it wasn’t obvious on how to accomplish that.
Suggestions welcome.
At least in Hubitat, when I go into the device I see the parameter’s title, e.g. “Dimming Speed”, but not it’s #, (for Dimming Speed that would be #1). When referring to the parameters to set, such as for Associations, the instructions inevitably refer to the parameters by their number without also giving their name. Thus the instructions for Associations are to set parameters 2 and 4. But when I go into the device’s settings, since there are no numbers, I had to assume they were in order and then count them out. For 2 and 4 it wasn’t hard, but harder than need be. Plus, without the name of the parameter in the instructions and no number at the device itself, one cannot be a 100% sure they adjusted the right setting. There is a situation where we are to adjust parameter 12 and for 3 ways, maybe 21 and 22. Counting those out can be a pain and adds needless uncertainty. So, please add the heading names to go along with the parameter numbers in your instructions and/or add the parameter number to the parameter heading inside the device where we actually set the parameter.
Thank you,
Stuart
That seems reasonable and maybe Inovelli (@EricM_Inovelli) might consider adding parameter numbers to the parameter names displayed on the device settings page? Maybe something like this:
parameter.parameter1name="Dimming Speed (parameter 1)"
Until Inovelli updates the descriptions in the driver files, here is a cheat-sheet you can use for the Inovelli Red Series LZW31-SN file. (parameter numbers will vary with other models)
parameter.parameter1name="Dimming Speed"
parameter.parameter2name="Dimming Speed (From Switch)"
parameter.parameter3name="Ramp Rate"
parameter.parameter4name="Ramp Rate (From Switch)"
parameter.parameter5name="Minimum Level"
parameter.parameter6name="Maximum Level"
parameter.parameter7name="Invert Switch"
parameter.parameter8name="Auto Off Timer"
parameter.parameter9name="Default Level (Local)"
parameter.parameter10name="Default Level (Z-Wave)"
parameter.parameter11name="State After Power Restored"
parameter.parameter12name="Association Behavior"
parameter.parameter13name="LED Strip Color"
parameter.parameter14name="LED Strip Intensity"
parameter.parameter15name="LED Strip Intensity (When OFF)"
parameter.parameter16name="LED Strip Effect"
parameter.parameter17name="LED Strip Timeout"
parameter.parameter18name="Active Power Reports"
parameter.parameter19name="Periodic Power & Energy Reports"
parameter.parameter20name="Energy Reports"
parameter.parameter21name="AC Power Type"
parameter.parameter22name="Switch Type"
parameter.parameter50name="Button Press Delay"
parameter.parameter51name="Disable Physical On/Off Delay"
parameter.parameter52name="Smart Bulb Mode"
1 Like
Thanks for the suggestion. I am adding the parameter numbers into the description section for each parameter. Starting with the LZW31-SN but I will add it to the rest as well.
4 Likes
THANKS for taking this to heart so quickly!!
Maybe because I’m so literal, and so new to all of this, but it took me a while to understand “Preferences” and “Parameters” were the same thing (and the fact that they weren’t numbered before just made me more unsure). Likewise, people talked about switching out the drivers, but inside the device’s setting it is called “Type”. I don’t know if this is just in Hubitat or if there is anything Inovelli can do about it, but maybe they could mention that someplace. Consistency in terminology is a big part of the UI experience. I know most of the people up here are very advanced and I am a complete noob, but I also think that most of us love Inovelli and would like them to succeed by reaching a vastly larger audience. To do so, that means talking to more noobs like me, so the easier, more obvious it is, the better.
1 Like
Yeah, no problem. A lot of the time what will happen is that we will write a document and then the platform that the document is about will change something. So at one time that screen may have said “Driver” instead of “Type”. We could definitely do better at keeping things up to date. We are hoping to push out a “wiki” type resource that our users can help keep up to date. Since we are a small company we don’t have that many resources to always be on top of things, but we are trying!
My experience with your products so far has been extremely positive. I can imagine how hard it is to expand rapidly having to deal with COVID and other supply issues and hiring. After a Black and Red Series maybe the next line can be an (M go) Blue series. 
1 Like
I think you’ll like what’s coming in the next few months
To be clear tho, I’m a MSU and University of Miami fan.
1 Like
Hum… let me guess… zigbee time?
Awwww yeah…
3 Likes
I cheer for Sparty except one game a year, and especially when you play the team named for a nut.
1 Like
Added 3 Innovelli Red LZW-31 SN Dimmer switches today.
All three were installed in a 3-way manner using dumb switches as the slave and using a neutral wire.
I was confused when I first installed them, that the dumb switch controlled the power to both switches, until I saw the insert that explained that you have to configure the switch for the power settings, 3-way, neutral wire, power on settings, and a dozen other options.
I still don’t understand the “child device” options, but they do everything I bought them for, and I didn’t have to buy an add-on switch for each.
All work great!
My setup was:
Main box
Line x2
Neutral bundle
Load (black load twisted with red traveler)
Bare ground
Slave box
Load (black load twisted with red traveler)
Neutral bundle
Bare ground
I was able to connect the LZW in the main box without touching the slave box.
Child device options allow you to expose certain settings of the switch so that they can be manipulated by 3rd party devices. Here is an example:
Disabling local control can be done via the switch’s settings in the hub. That is the setting that keeps the paddle from turning the wired load on and off. Sometimes that is used with smart bulbs where you just turn it on and leave it, but there are other uses where you might want to turn it on and off with some regularity.
Let’s say that you have a toddler that likes to play with the Inovelli dimmered overhead light switch at nap time. So you could go into the switch’s settings via the hub and turn on disable local control. But if you have to do that regularly, it’s unwieldy.
So you turn on the child device for disable local control. The creates a child object for your hub. It still looks like a switch, but turning it on enables local control and turning it off restores local control. These child objects also get exposed to linked services such as Amazon Alexa. So if you have the child object enabled for disable local control, you can keep the toddler from turning on the overhead light by saying “Alexa, turn on the whatever light disable local control”. To resume normal control, just tell Alexa to turn it off.
There are also child devices for LED color when on or off. That makes it easier for some to set the LED bar color for notification purposes.
1 Like
Is there the way to turn off “Smart bulb mode” manually from the device?
The issue I experience if inability to control lights at all when there is network or smarthings outage.
Smarthings hub is not able to send scene to smartbulbs and at this time I want to switch to manual mode.
But when I press config C button for 8 times, behavior doesn’t change. LED light confirming that “Disable local protection” setting is changed by signaling greed/red, but switch works in same manner, not cutting off power to the bulbs.
Is the only way to resolve this to turn off “smart bulb mode” and use “disable local control” option only?