[ANSWERED]Synchronizing Master Dimmer On/Off/Brightness

Testing Indigo under the Trial License and would like to know the most efficient method for my scenario. I read a similar thread by NicholFD (Frank) but his situation was slightly different and the answers did not address my need.

I have a Master Z-Wave Dimmer switch than operates the recessed LED lights, and two Remote Z-Wave Dimmers (Cooper Aspires, FWIW); these switches have a vertical column of tiny LEDs that animate to show when it's turning on, turning off, as well as it's current brightness level setting. Apparently, each maintains their own status of On/Off and Brightness independently so I need to "script" Indigo to synchronize the Master and Remotes, both at startup and during the course of device operations.

TRIGGERS appear to be the logical method of doing this but I noticed that TRIGGERS do not have an ACTION that allows me to "match" the On/Off status of the "triggering" device; only ON, OFF, or TOGGLE. And since there doesn't appear to be a method to set the CONDITIONS on a per device scenario, what happens is that without building individual triggers for each source/target switch PAIR there will be a lot of unnecessary traffic on the RF network to blindly blanket all "linked" switches to the setting of the source switch, which in turn will result in those devices' triggers being firing by Indigo. Thus it seems I would need to build multiple triggers to handle: 1) An "ON" event for each triggering switch and each individual remote to sync, 2) An "OFF" event for each triggering switch and each individual remote to sync, 3) A "BRIGHTNESS" event for each triggering switch that syncs all other switches. This results in the following synchronization triggers just for the Master Switch:

Master Switch ON then set Remote 1 ON only if OFF
Master Switch ON then set Remote 2 ON only if OFF
Master Switch OFF then set Remote 1 OFF only if ON
Master Switch OFF then set Remote 2 OFF only if on
Master Switch BRIGHTNESS then set all Remotes to Match Brightness

Again, I'm trying to not to flood the RF network with redundant transmissions. Since Indigo doesn't allow CONDITIONS to check if the brightness level is not the same as the source device or against a variable, it appears that each target switch will result in firing off it's own brightness trigger in Indigo.

Is there a better way than the approach I described above (if anyone can understand my logic)?

[jay (support)]

Actually, just trigger on Brightness Level Has Any Change (which will also cover on/off) and use the Match Brightness action under Light/Appliance Controls. And, unless you have a rather large number of devices (say, 100+) I don't think you're going to notice any significant network congestion.

You can, of course, write a script to do it as well in which case you could filter out any switch that already matches the brightness before setting it.

Well THAT was something I would never have guessed: BRIGHTNESS setting encompasses both On, Of, as well as the actual Brightness level...

But I'm curious, since these particular switches always show the brightness level setting via the aforementioned vertical column of blue LEDs, even when off, and you can even adjust the brightness level setting when the lights are off, does that mean Indigo can not distinguish between the two settings of ON/OFF and BRIGHTNESS as independent variables?

[jay (support)]

Well THAT was something I would never have guessed: BRIGHTNESS setting encompasses both On, Of, as well as the actual Brightness level...

Well, a brightness of 0 generally means OFF and anything else generally means ON.

But I'm curious, since these particular switches always show the brightness level setting via the aforementioned vertical column of blue LEDs, even when off, and you can even adjust the brightness level setting when the lights are off, does that mean Indigo can not distinguish between the two settings of ON/OFF and BRIGHTNESS as independent variables?

The setting of how bright a device will go to when turned ON is just that - a setting. The on/off and brightness states of a device represent the current value (or state) of the device (not a setting). The LEDs represent the state (as does Indigo's brightness state) rather than the setting. I don't believe there's a UI config setting for those switches to set the default ON brightness and I'm not sure if there's any way to set it manually at the switch (the documentation for the switch should say). If there's a config param for the device to set it then you can use theInterfaces->Z-Wave->Modify Configuration Parameter menu item to set it.

If we are in agreement of the terminology difference between a "setting" and a "state," then your assumption that the Cooper Aspire RF9540/42 switches LED's represent the "state" then you are somewhat incorrect. As I mentioned, the blue LEDs do three things: 1) When in a constant, non-animated condition, only one LED is lit and represents the "setting" of that particular switch (remember, the settings of remote and master switches are all independent of each other, hence my need to manually synchronize them to the master);2 ) Animated either going up or going down to represent a user response to an on/off, wherein if it's going up due to a ON command, the animation starts from the bottom LED, works upward one-by-one until it reaches the brightness "setting" saved within the switch; off is just the opposite animation, but then after the bottom one goes off, the LED representing the "setting" of the brightness level will activate and remain on until the next command; and 3) Brightness Adjustment, which of course, is animated either up or down depending on which "direction" the user/command indicates to adjust the brightness level.

I wish Cooper Wiring Devices offered some sort of programming/setting documentation so I can determine which "settings" and "states" are accessible through the Z-Wave API, but so far I have come up blank. My last e-mail to technical support has remained unanswered after two weeks, so I'm a little peeved at the lack of customer support on these product. I will keep trying...

[jay (support)]

That LED behavior sounds, um, unique, though I have no idea since I have none of those switches. Reflecting a setting on the LED seems like it would cause quite a bit of confusion on the part of the user but maybe that's just me...

Oops. what I really meant to say in a nutshell is that when a given switch is "on," the blue LEDs indicate its "state." When that switch is off, the blue LEDs indicate its "setting."

I'm not sure if it's unique: my brother-in-law uses Lutron dimmers and its LEDs exhibit similar behavior/operation. So this seems to be a "normal" design feature.

[jay (support)]

I was being polite using "unique". It's stupid behavior IMO. It's confusing because it's trying to communicate two different ideas using a single physical concept and it's not intuitive at all. Again, IMO.

I've been an Apple user since the Apple ][+ with lower-case mod, and currently part of the Apple Dev program, so I've seen the evolution of Apple's User Interface over the past 30 years, a lot of which I may disagree upon. No matter how vociferous I've been in expressing my "opinions" of the direction their UI has gone here and there, it has been all to no avail.

What I've learned is that it's just the way companies operate: to show "innovation" and "progress" by changing how something looks or operates, even if it's just for no other good reason other than making it different from previous versions even though it may make it less intuitive to use than before, at least for those who were used to the "old" interface method. You just have to accept "progress" and deal with it. Apple, Microsoft, Google, Ford, GMC, Chrysler, etc, they all partake in this "progress."

In the same vein, you nor I directly had any input in how some of the large residential/commercial electric device manufacturers decided upon a particular interface "standard" but we have to "deal" with what's in the market and cater our usage and development to these products.

To simply dismiss it as "stupid" is self-defeating and does nothing to "advance" your product to embrace the wide range of current and future products that bear on the market; instead, alienating not only those companies' products, but the consumers that use those products.

BTW, I forgot about the feature as I rarely look closely at the switch, but there is an amber LED at the bottom that actually indicates if the switch is in the "on" or "off" state. So in fact, Cooper Wiring Devices does distinguish the "two different ideas" of "state" and "setting." I don't know if my brother-in-laws' Lutrons also provide this visual cue but I will scrutinize them tomorrow when I head over there.

[jay (support)]

Pointing out unintuitive behavior has no bearing on whether or not our product advances. We support the Cooper devices no less than other devices and in fact we probably support more configuration parameters for them in the UI than we do with many other devices of similar type. It is also by no means meant to alienate customers using the product.

I believe this conversation has run its course. If you find any documentation on setting the default ON value through a configuration setting, send us the information (or post it on the Hardware Support forum) and we'll add it to the list of config parameters to add to various devices (it's a long list, so we can't guarantee if/when it'll be added to the UI).

Yet again we are in agreement: simply proffering a derogatory "opinion" of a method (which one should ponder their own interface methodologies and technologies first before casting the first stone (reference your iOS Indigo Touch app, which has not been updated in four years, and its rather clunky "Control Pages" that doesn't adjust its layout automatically to serve iPhones and iPads to their best capabilities nor even to adjust for screen orientation, as an example) when no such opinion was solicited, as a perfunctory dismissal of the issue without any constructive answers which obviated the need to respond as a potential customer should when deciding if the product is worth purchasing (which only then the final retort was to submit a feature request), just about sums up that this conversation has run it's course.

Thanks for the memories.

[matt (support)]

Jay was offering his opinion on the usability of trying to convey too much information via a single UI component (LED). It sounds like there was some confusion as to what the exact behavior is (in regards to how many LEDs there are and what states they show) – we don't have that Cooper module wired up so we have to go on what you described, which to me seems quite complex.

From what we can tell the Cooper module doesn't provide the abilities you need. That isn't an Indigo issue, and so I'm not sure what we are discussing at this point, besides you didn't like Jay's off-the-cuff remark of the usability of trying to convey too much information via a single LED.

As to Indigo Touch and the usability of our Control Pages we are the first to acknowledge the shortcoming in our products. I can promise you that no one is more annoyed by the state of Indigo Touch than us right, hence it is our top priority.

Since this discussion seems to have runs its course, I'm going to lock this thread.