One dimmer to control 3 dimmers

Community Playground General Discussions
#1

He i need some advise, I have 3 lights in a zone meaning they all operate the same but they are 3 individual colour changing bulbs. I tried reactor but it isn’t reliable (For the first time) so I am trying another solution
so i need to use
this image

to control these

image
image395×610 18.1 KB

here is my reactor code

image
image1171×654 66.1 KB

image
image1158×852 66 KB

i could use PLEG but learning curve is what keeps me out

i could modify the device file to custom fit the 3 lights but i just want to know if there is a plugin i could use

#2

I have a master device for roller shutters and I can share it. It’s basically driving a group of device to be controlled as one. With minor modifications, you can use it to control dimmers as well (since roller shutters are basically dimmers in vera).

I know @rigpapa is working on a similar concept for dimmers.

#3

sure if u wann share it ill take it

#4

I’m traveling this week and be back on Sunday. I will post it to my github account and be back here with the url.

1 Like
#5

You didn’t say what unexpected result you are getting. Can you elaborate?

#6

it works some times im assuming reactor takes time to process the changes aond sometime it just doesnt do anything

#7

For starters, you are using the wrong state variables. It would be better to use LoadLevelStatus and Status rather than LoadLevelTarget and Target.

You also do not need the “updates” conditions. They are redundant here based on the way Reactor works, and it doesn’t work on these variables anyway, it’s only applicable to the variables that have names starting with sl_. You use of “changes” in the first condition (Zone Overhead) is correct, but you don’t need it or anything like it anywhere else.

You should change your group names so that the whole thing is more readable, especially the activity names. Click on the group name in the condition editor to change it.

The actions in “grpfxfc9zj is TRUE” should not use the variable reference, just put in 0.

Then, if you move your master dimmer and it doesn’t do what you want it do, go directly to the “Tools” tab and generate a Logic Summary and post it here. Screen shots don’t give enough data.

#8

Here’s my version. Not much different from yours. If you make the changes I suggested, some groups become unnecessary so you can flatten/simplify even more, which is always a good thing:

image
image1159×356 34.5 KB

image
image1156×190 14.2 KB

image
image1157×514 41.4 KB

It may be the case in your testing that you’ve had your ReactorSensor throttle–if you send too many changes per minute, Reactor attempts to protect the system by slowing things down. The default limits for this (30 changes per minute, 5 tripped state changes per minute) are quite conservative, but you can tune them and probably should for this application, as there is little risks of “loops” (one of the problems the throttling tries to catch). You can set the MaxUpdateRate and MaxChangeRate state variables on your ReactorSensor to a fairly high value (say 60 on both) for this application.

The last thing I noticed in my testing that if I change the levels too quickly, the default pulse time of the changes operator catches the second change and thinks it’s part of the first, so no second firing of the action happens. The default is 2 seconds, and sometimes that will be too long for this purpose. To shorten that hysteresis, change the ValueChangeHoldTime state variable to 1 on your ReactorSensor. If your RS is older, you may not have that variable, so then go to the Advanced tab, “New Service” subtab, and enter the following (copy-paste–it must be exact):

  • New Service: urn:toggledbits-com:serviceId:ReactorSensor
  • New Variable: ValueChangeHoldTime
  • New Value: 1

Since Reactor 3.4 has some additional controls for pulse timing of this type, this variable and its behavior will not be used in 3.4 and after.

#9

ok let me try it