Do you mean that that parameter is set by that option in the driver?
I believe that to be the case.
This option selected makes the dimmer act similar to when I set Parameter 13 with the Basic Z-Wave tool.
Your assumption is correct. In the driver if none of the status LEDs are set in the set status LED call it reverts to normal mode. This is what the SmartThings device handler did so I did not change the functionality. This was either desired by the person that wrote the original device handler or they were following what the switch's firmware does. I haven't tested myself because I don't really care how it behaves in this case but the switch may actually go back into normal mode if you set LEDs without specifying which LEDs if that makes sense.
What I would do to make sense of this to see if there is flexibility of not setting it back to normal mode is try setting parameter 13 to 1. Check it to make sure it set. Then set some parameter 20 through 27 to a valid color like 1. Check parameter 13 to see that it is still set. Next set all parameters 20 to 27 to off (0). Then check parameter 13 to see its value. If it doesn't go back to 0 then it was just the way that the driver was written I guess.
If you can give me a good use case I would add a preference to my driver to leave parameter 13 alone so the switch/dimmer stays in status LED mode rather than revert to normal mode.
1 Like
Thanks for the reply.
If I were to suggest a change it would be to make the "Enable Status LEDs" option to be:
ON - AUTO - OFF
John
We have no way of knowing how the built-in driver is coded. They are not open-source.
My response was to codahg who has his own version of the driver. Not sure why the forum did not show the reply to indication.
Sorry I missed that, was thinking rather than reading 
Anyway I believe he was referring to his driver for the HS-WD200+ dimmer.
He was? I didn't even know that he had a driver for it because you said you were using the built in driver.
So, I'm not completely following why he would be talking about his driver or how anyone was supposed to know that. 
Codahg responded to my original post and stated his(?) driver acted the same way and the controlling code was copied from the Smartthings handler so he would not be surprised if the code internal to the Hubitat was similar.
I'm not sure why you would be surprised he had a driver for this device based on my comments or his. Anyway I don't know if you have a HD-WS200+ dimmer and if so you use this feature.
I'd like to explore this a little further....you're saying that the driver is changing a parameter on the device? What driver is this?
I am curious why you wish to explore this further since by your statement we cannot know what is in the internal driver.
1 Like
I simply have never seen an internal driver set a device parameter for a configurable option back to a default without that option being pulled out for the user. But since it doesn't seem you really want help, I won't bother. Best of luck!
Okay, I think what makes more sense here is just to have a setting "Let setStatusLed Manage LED Mode" or something like that. When this is on, setStatusLed will auto it off or auto it on. Otherwise, it will leave it to whatever was set via the setSwitchModeNormal and setSwitchModeStatus commands.
The reason for this is because it is not really a preference but a state. If I make the on/off states as part of the preference then I have to update the preference any time the switch mode commands or setStatusLed is called. If I just have the allow-to-be-managed component as a preference I don't have to do any updating and you get the same functionality.
So, I've been thinking about this more @JohnRob and now I need you to tell me why the parameter 13 needs to stay at 1 even when you turn the status LED lights off. Why does it matter? The very next time you set a status LED with setStatusLed it also sets parameter 13 back to 1 if it needs to.
And in the meantime if you don't let the driver manage parameter 13 then the setting to have the switch show the bottom status LED on when the load is off breaks because the parameter 3 only works when the switch is in normal mode.
So if I give you what you want it breaks the bottom LED on when load is off functionality.
Why does it need to stay on if the next time it is needed it is forced on anyway? Or does the OOB driver not do this? My driver acts like this:
if (state.statusled1 == 0 && state.statusled2 == 0 && state.statusled3 == 0 && state.statusled4 == 0 && state.statusled5 == 0 && state.statusled6 == 0 && state.statusled7 == 0) {
// no LEDS are set, put back to NORMAL mode
cmds << zwave.configurationV2.configurationSet(configurationValue: [0], parameterNumber: 13, size: 1).format()
}
else {
// at least one LED is set, put to status mode
cmds << zwave.configurationV2.configurationSet(configurationValue: [1], parameterNumber: 13, size: 1).format()
}
So, it when it needs to it sets parameter 13 back to 1 when necessary. The reason it turns it off when no LEDs are set is so that the bottom load LED can show when no LEDs are set. The bottom load LED (parameter 3) only works with the switch is in normal mode i.e. parameter 13 is 0.
Thanks so much for thinking of my situation
Here's what we want:
Status lights to be set on or off by RM4 Rules.
When the Status lights are all not set (i.e. all ths status lights are OFF) we DO NOT want the dim lights to illuminate.
Current Situation
When all status lights turn off, the Dim indicator goes on if either the dimmer is manually changed or Z-Wave changed.
Status Light ON:
Status Light OFF then dimmer turned off (even though it was already off)
The issue is at night at a distance its difficult for the wife to tell if a status light is on or the dimmer is on (even though there is a color difference)
Got it. So when the load is on you don't want it to show load ever. You never want to see the load indicated on the LEDs because for your use they are strictly for status (or you want them to be after the change) and you don't want somebody to confuse two or any number of load status lights with actual statuses. Fair enough.
So... you understand the problem, right? I'm going to make the change but if you see somebody with an issue because I gave this to you and the community I would like you to help me explain it. I'll post it but in the release thread but inevitably somebody will not read it and ask.
Here are the issues that this change can cause:
- Bottom load off LED can now possibly fail because switch mode status is pinnable or sticky or whatever we want to call it
- Set Status LED can now possibly fail because switch mode normal is pinnable or sticky or whatever we want to call it
By the way, I would set it up in the driver like this:
So they would have some explanation already.
I did not see your Preference screenshot before I posted this....
I see your point. And of course I will explain any posts I see retarding this (or any other question I'm able to answer).
However I don't yet understand why this should not be preferences. I'm only slightly familiar with device driver programming. And I thought
-
Selections in the Commands Section are able to be programmatically set by RM4 etc.
-
Settings in Preferences are what is selected until change and the configuration is actuated.
I may be blinded by my usage but I'm not sure why someone would want to change this parameter programmatically?
The internal Hubitat driver has the LED control in the preferences and offers two options:
-
Dim lights are enabled, Status LED's are not.
-
Dim lights are enabled, and Status LED are enable (however they will switch to Dim when all status LEDs are off. I call this the "automatic Mode"
Would it not be more intuitive for the uses if a third option like "Status Only" were available?
Again, I really appreciate your interest and effort.
John
It is programmatic because of the two reasons I mentioned.
First, if somebody tries to use setStatusLed and that method is not allowed to turn status LEDs on nothing happens. This is confusing to the user. It's also easier for the user so they don't have to set the switch mode first and then set the status LEDs.
Second, it is convenient if somebody tries to use the preference to show the bottom LED on when the load is off. If the switch mode doesn't change to normal when the status LEDs are set to off then the bottom LED never comes on either.
I think I might actually set it up like this:
Regarding the Status LEDs.....
I understand that the HomeSeer HS-WD200 and the ZWP dimmer are the same Dragontech OEM device. However, it doesn't appear to me that the status LEDs can be managed with the ZWP the way they can with the HomeSeer. Has anybody managed to use the status LEDs on the ZWP device? TIA....
I believe that HS has said that they have different firmware.
