[ANSWERED]Toggle "link" of 2 x dimmers, and match when ...

Hello,

I have 2 x pairs of lights on my outside wall, above my deck. One pair is connected to a plug-in Z-Wave dimmer. The other pair is controlled by a wall Decora Z-Wave dimmer switch (different brand).

I have touch screens on the wall near doors, to use with Indigo Touch. I want to add a "device" on the touch screen that toggles linking the state (on/off/brightness) of the 2 x pairs of outside wall lights. I want the option of having all 4 x lights come on & dim to the same level, if either module (plug-in or wall switch) is turned on/off/dimmed, and the option of "un-linking" the modules, to control each pair of lights separately.

I'm familiar with variable, triggers, etc. Is there a quick & simple way of doing this, or am I going to have to create all types of triggers/groups/etc. to catch any combination?

Also, I'm not clear on how to create/configure a virtual device to toggle the "Linked" status of these modules.

Thanks for any pointers or suggesting.

Frank

[jay (support)]

You're going to need to construct your own mechanism. It should be pretty straight-forward though: two triggers and a variable.

For each light, you have a device state changed trigger that watches for any change in brightness. When it sees the change, it uses the Match Brightness action to set the other light to match. This will keep the two in sync.

Now, add a variable ("shouldMatchBrightness"), set it to true, and add a condition to each trigger that looks to see if the value of that variable is true. Then, when you don't want them to match each other, just change the variable's value to false.

Thanks for the reply.

I was afraid of that... Won't I also have to create triggers to catch on/off status, or will just catching dimming changes get on/off, too? Does brightness=0, ALWAYS mean the module is off (Z-Wave)? I know with some of my old X10 modules, you could have a brightness=0, but the module was still "on".

How about the Virtual device for display on Indigo Touch, to toggle the state of the variable. I thought it should be pretty straight forward, from how ** I ** thought a virtual device might work. But, after I started trying to add a virtual device, it kept requiring some link to a group action, etc.

Thanks,
Frank

[jay (support)]

Thanks for the reply.

I was afraid of that... Won't I also have to create triggers to catch on/off status, or will just catching dimming changes get on/off, too? Does brightness=0, ALWAYS mean the module is off (Z-Wave)? I know with some of my old X10 modules, you could have a brightness=0, but the module was still "on".

AFAIK, brightness of 0 always means off so believe you should be good.

How about the Virtual device for display on Indigo Touch, to toggle the state of the variable. I thought it should be pretty straight forward, from how ** I ** thought a virtual device might work. But, after I started trying to add a virtual device, it kept requiring some link to a group action, etc.

We designed the Virtual Device to be very flexible by clearly separating the major functions. This includes turning a device on and off, and managing the state of the device. The action groups handle the on/off task - so when you tell a virtual device to turn on, the on action group gets executes. If you want the on state to be managed, then you specify a variable that represents the device state along with an action group that will get executed when a status request command is received by the group.

So, if you want a virtual device that does nothing more than maintain a binary state, then use a variable instead of a device since that's much easier. If you want that plus the ability to use built- in UI and actions, then set up a VD with a variable to hold state and a pair of action groups that modify the variable to on/off as necessary. This will cause the device state to update. Those action groups can of course do other things like communicate with an external device or service, etc.

Our virtual devices are much more than just a device that mimics an on/off device (though it can do that also) - they allow a simple way to actually make a virtual device that talks to something that indigo doesn't natively support.

Got it - Thanks.

I need the functionality of a VD because I want to display it on the tablet showing Indigo Touch, at my patio door. I want the link/unlink status of the deck wall lights to be able to be changed by turning a VD on/off in Indigo Touch.

What was throwing me off with the VD were all the options and being REQUIRED to link it an action group. Your explanation made it click for me and it's working great. I didn't think I should have to use the VD to control a variable. Is the VD not designed to just have a state (isON), and not tied to anything else? That is what I was thinking - KISS. I'm ok with using a variable, I just didn't think I would have to, and I could use the state of the VD, instead of the variable for conditionals, etc.

Thanks,
Frank

[jay (support)]

Is the VD not designed to just have a state (isON), and not tied to anything else?

Correct - because while that might make it simpler for your use-case, for many use cases where the user needed to directly control when on/off was changed based on some external feedback it wouldn't work well. There's a common principle that runs through Indigo concerning devices: actions on a device are independent of direct state manipulation. So issuing an ON command to a device would result (at some later time) on the device state changing to ON - but not as a direct consequence of issuing the command. Rather, the feedback from the device saying that it's now ON would cause the state to change. The same principle holds with Virtual On/Off Devices: executing an ON command doesn't set the state - but the thing that actually performs the ON should (thus, manipulating the variable).

The only time we do the automatic state update from the command is with X10 because there is no feedback from devices - and we all know how crappy X10 is so that model isn't really one we want to follow.

Thanks for the explanation & details regarding some of the internals of Indigo.

My history with Indigo originates in 2003, and all I had was the crappy X10 stuff. I'm the guy that wrote the AppleScript X10 Maxi Controller, that talked to Indigo, that's in your download area..

A lot of my expectations and history are from those old X10 days.

I think you can mark this as answered or closed. I have things working as I want.

Thanks for all the prompt replies.

Frank