Bug in ST "dimmer switch" device type

(Gary D) #1

@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

Next Developer Call will be on 3/11/2015
(Todd Whitehead) #2

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?



(Gary D) #3

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) #4

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.


(Geko) #5

This has already been reported.

(Gary D) #6

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

(Mike Maxwell) #7

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.

(Gary D) #8

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) #9

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…

(Gary D) #10

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