Bug in ST "dimmer switch" device type

[garyd9 (Gary D)]

@Tyler, @Ben, @April : please direct this to whomever it concerns…

There’s a bug in the ST “dimmer switch” device type. Around line 146 is the start of the following definition:

This will never get called. The reason is that parse() is calling createEvent(…) and not zwaveEvent(). The above line should be changed to:

While at it, it probably wouldn’t hurt to clean up that function to not assume the configuration parameter being handled. After all, it might not be parameter 3 coming in… it might be something else entirely.

One last suggestion: indicatorWhenOn(), indicatorWhenOff(), indicatorNever() are all assuming their config sets are succeeding. Most other ST device type code sets a config param, and then gets it after a delay (which would trigger the above configuration report.)

If someone wants a “dimmer switch” device type with these changes already made, please let me know and I’ll throw one together.

Take care
Gary

[Todd_Whitehead]

The linear dimmer indicator settings are messed up. They are backward if you have them on, and if you want them always off, it doesn’t work.

Do other dinners have this problem?

Is this a hardware or software issue?

Thanks

Todd

[garyd9 (Gary D)]

@Todd_Whitehead

The linear dimmer indicator settings are messed up. They are backward if you have them on, and if you want them always off, it doesn’t work.

Yes, this is a difference between how different manufacturers have implemented param3. To be honest, I’m surprised that they all seem to use it for the indicator LED at least. It’s a s/w (device type) limitation. It could be corrected with an MSR check when interpreting the parameter values, or with a different device type. (Does the linear switch support all three indicator modes?)

[Todd_Whitehead]

On when on and on when off seem to be backward. Off all the time doesn’t seem to work. I think it works as on when off when I choose that. I’ll double-check when I get home.

Todd

[geko]

@garyd9

There’s a bug in the ST “dimmer switch” device type.

This has already been reported.

Bug in Z-Wave command parser found

Att: @duncan Another bug in the Dimmer Switch device handler: Line 146: def zwaveEvent(physicalgraph.zwave.commands.configurationv1.ConfigurationReport cmd) { should be: def createEvent(physicalgraph.zwave.commands.configurationv1.ConfigurationReport cmd) {

[garyd9 (Gary D)]

It needs the second parameter (type Map) or it won’t be called.

[Mike_Maxwell]

The aeon micros don’t even implement this function at all.
IMHO, options for setting the parameters of interest belong in the preferences panel, not the main tile.
There’s more room for one, and they make more sense.
See below for a working aeon device implemented in such a way.
There’s also the dimmer in the same repo
This includes the correct default settings for status reporting, the default device requires polling to update ST.

MikeMaxwell/smartthings/blob/master/aeonSwitch.groovy

[garyd9 (Gary D)]

@Mike_Maxwell

IMHO, options for setting the parameters of interest belong in the preferences panel, not the main tile.There’s more room for one, and they make more sense.

I can’t argue with that. On the other hand, I’ve been trying to make my stuff “fit” with what ST has already done. In some cases, the “tiles” can make a nicer UI than the preferences “list”, but “configuring” a device certainly seems like a “preferences” thing, and not a “main UI in your face” thing. (Really, how often does a person need to change when the indicator LED is displayed?!)

One advantage the titles have is live updating. If a configuration parameter is changed outside of the mobile app you are running, the tile can update it as soon as the attribute changes. Can the stuff on the preferences page do that?

[Mike_Maxwell]

@garyd9

I can’t argue with that. On the other hand, I’ve been trying to make my stuff “fit” with what ST has already done. In some cases, the “tiles” can make a nicer UI than the preferences “list”, but “configuring” a device certainly seems like a “preferences” thing, and not a “main UI in your face” thing. (Really, how often does a person need to change when the indicator LED is displayed?!)

One advantage the titles have is live updating. If a configuration parameter is changed outside of the mobile app you are running, the tile can update it as soon as the attribute changes. Can the stuff on the preferences page do that?

Don’t know haven’t tried that, I only put parameters in there that you wouldn’t need or care about feedback from, maybe shoulda been clearer…

[garyd9 (Gary D)]

I’ll play with it the next time I get some free time (whatever that is.)