Next Developer Call will be on 3/11/2015

[garyd9 (Gary D)]

Topic: Bug fix priorities:

When choosing bugs to fix, does ST give any priority to “low hanging fruit?” As a developer that contributes freely to ST, I get frustrated when I see bugs reported to ST that include potential fixes - that are trivial things to fix, but that never seem to get fixed. These are things that all a ST engineer would have to do would be cut/paste the suggested fix for (and are plainly obvious.)

I really start losing enthusiasm for the product when I see these types of things dragging on for months. What is someone like me supposed to think when ST apparently isn’t interested in fixing these tiny things? What does that say about the bugs that might require actual effort to fix?

For example:

Bug in ST "dimmer switch" device type

@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.…

(which was previously reported almost a month earlier):

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) {

(The irony is that this particular issue isn’t actually seen due to a larger bug that the device type never queries the configuration parameter and just assumes that the set cmds worked… Which, btw, would be nearly as trivial to fix.)

Edit: I hope ST doesn’t take offense to me calling these things out like this. However, as one of the great positives of ST is the community development contributions, I feel that those community developers have a right to ask these questions.