let me try this out
Expressions
StateR = getstate( “Hue Hallway 1”, “urn:upnp-org:serviceId:Dimming1”, “LoadLevelStatus” )“22”
Group: Reactor Sensor 5
Device State: Hue Hallway 1 (#417) LoadLevelStatus changes (match case)(24) false as of 5:18:48 AM
Activities
When Reactor Sensor 5 is TRUE
Device Action : Hue Hallway 2 (#416) : Set dimming level : {StateR}
it works great
1 Like
Thank you! I didn’t have {getstate} entered as the dimming level.
Finally back on this. The next wrinkle is to get this to work with a multi-switch setup.
I can create a condition with switches 1 OR 2 OR 3.
Then an activity to have all of the lights and switches adjust level to {getstate}. The problem is that the getstate variable is watching just switch 1 so if I use switches 2 or 3 it doesn’t work. Is there a way to have it the switch that’s being changed, or some other answer here?
Just learned about copying switches through backup/restore so that’s cool. I have this set up with one reactor for each switch which works fine but would like a more elegant solution if possible. I have a bunch of these to do.
You’re probably going to run afoul of some loops if you don’t do this carefully. You could easily end up in a situation where dimmer 1 changes due to user finger action, so 2 and 3 update by Reactor actions, but then the logic for 2 and 3 think they are changing so their activities fire again to change 1 and 3 and then 1 and 2, and then they both think they’ve been changed, and on and on and on… Your ReactorSensors will simply throttle/stall when these updates get out of hand, so you need to make sure they only react if they need to.
Here’s what I would try (and I mean try–I haven’t done it or tried it myself)…
First, create an expression-less variable called “targetlevel”, and export it. This variable will store the target level for the mirror set.
Then, you’re going to make two groups for each dimmer.
In the first group, check if the dimmer’s LoadLevelStatus changes (that’s the name of an operator you can select), and check if the dimmer’s LoadLevelStatus is not equal to {targetlevel} (this is a variable reference–it takes the value of the variable for the comparison). The TRUE activity for this group should do a SetVariable action on the current ReactorSensor to set targetlevel to the value of the LoadLevelStatus of that dimmer (so you need a variable with a getstate() as well).
In the second group, check if “targetlevel” on “this ReactorSensor” changes, and test if this dimmer’s LoadLevelStatus is not equal to {targetlevel}. The TRUE activity for this group should do a SetLoadLevelTarget action on this dimmer to {targetlevel}.
Lather, rinse and repeat for each other dimmer in the set of dimmers to be mirrored.
Here’s the theory of operation: for each dimmer, the first group checks if its load level is being manipulated to something other than the current target level for the mirror set. If so, it modifies the target level. The second group checks to see if the mirror set’s target level changes and if that new level is different from the dimmer’s current level, and if it is, it sets the dimmer to that level.
This seems redundant, but what it does is make each dimmer responsible for itself–it doesn’t directly modify any other dimmer in the set.
That should prevent the dreaded loops and get you to a solution in one ReactorSensor for any number of dimmers in the mirror set.
Thanks for your response. I did think of the looping problem so put the switches that aren’t being manually controlled at the end of the activities list (after the lights), and put a 5 second delay before them. They only need to have the same setting when someone goes to change the lighting level later so any reasonable delay is fine.
Anyway, it sounds like there is no way to do this within one reactor switch which is what I was wanting ideally.
Actually, what I described is doable in one ReactorSensor. I even said that?
Ah, I thought this:
“Lather, rinse and repeat for each other dimmer in the set of dimmers to be mirrored.”
meant to create a new reactor for each dimmer. So this does sound like what I was thinking. That I needed a separate think for these switches to monitor. I was thinking of it as a virtual dimmer switch. So this looks interesting, how do I export the targetlevel variable? I’m not clear what that means.
When you create the variable, leave the expression field blank, and on the right side are four buttons–hover over them and the tooltip will show you which one is “export.” When it’s highlighted green, the variable is exported.
This makes sense and I have it all set up except for the getstate variable. I am getting the state of the targetlevel right? But how do I enter that? Previously I had this line in there, getting the loadlevelstatus of switch 151 like this:
getstate( 151, “urn:upnp-org:serviceId:Dimming1”, “LoadLevelStatus” )
No, you’re getting the state of each dimmer. So you need one getstate per group/dimmer.
Your getstate is correct, you just need to add more of them, so each activity can fetch its dimmer’s current load level. So obviously, you’ll need to give each its own variable name, and in each group TRUE activity, refer to the correct one for the group.
Submasters is a little different from what OP is asking. Submasters uses an additional virtual dimmer, the submaster or fader, to control a number of other dimmers. OP is trying to get a change at any of a set of dimmers to be mirrored across all dimmers. That has some common elements with Submasters, for sure, but is different enough from it that I don’t think that approach would address his needs, which is why I didn’t recommend it.
i tried something like that with reactor controlling my AVR because i had a number of ways to control its volume but it kept breaking reactor and looping causing the reactor to ultimately shut down
See this prior post here for an approach to preventing such a loop in your logic: Mirror Dimmer Setting to 2nd Device - #11 by rigpapa - Reactor - Ezlo Community
thanks but i gave that fight up a long time ago … no disrespect tho i still love reactor
None taken, it’s not Reactor’s fault–avoiding logic loops is common in many systems and programming languages. Reactor is no exception.
1 Like
Got this done yesterday and it appears to be working correctly (not actually at the house). Thanks very much for the help, rigpapa.
2 Likes