Best way to keep scene fully active in reactor

What is the best way to ensure that a scene remains fully active during the entire time it is set to be that way?

Example, during a 3-hour period certain lights are meant be on and certain are meant to be off. will setting the pulse function ensure that all the lights remain in that state even if someone manually flipped a switch on or off?

What kind of timing do you suggest around that?

Pulsing repeatedly to command devices on that should be on, while potentially effective, is like polling. When you poll for data, you get an answer, but the answer could be as stale as a fraction of a second less than the length of your polling interval. Poll every 60 seconds? A light can easily be in a different state for 59 second before you find out about it. Pulsing is similar: someone turns off the light, but it stays off until the next pulse comes around to command it back on. It works, but it’s the “lazy” way to do it.

A better approach is to combine your time conditions with goal states. For example, let’s say you want to ensure that a light stays on between sunset and 11pm. The straight-line solution is to make a condition group that addresses the time range, and turns on the light when it becomes true, but as you note, if the light gets turned off manually during that time, it stays off. Adding goal states entails checking the state of the device in addition to the time range: “if it’s between sunset and 11pm and the light is off”. In this scenario, any time the light is not on during the time range, the condition is true, causing the light to turn on.

The catch, though, is that now the condition goes false immediately after turning on the light (because the light is no longer off). That means you need to add a separate condition to make sure the light is turned off at the right time. You can’t use the “is FALSE” activity of your prior “turn on” condition group to turn the light off. In fact, if you try to do that, you will turn the light off… and on… and off… a lot… as fast as Vera and ZWave can do it (unless you’ve disabled the throttling in the ReactorSensor, it will stop eventually).

If you go this route, I also recommend adding a “sustained for” delay of a few seconds, to avoid any “short cycling” behavior of the switch that could damage either the switch or the bulb/fixture. What I mean by this is, without any such delay, as soon as you reach for the switch to turn it off, the Vera will turn it immediately back on. For certain inductive loads (like CFLs or LEDs), this can cause some heartburn eventually and shorten the life of the switch, device, or both. If you leave a delay of 10 or so seconds before the automation corrects your inappropriate behavior, it’s likely that everything has settled enough.

Finally, don’t read too much into my use of the word “lazy” in the first paragraph. The pulse approach is perfectly acceptable if that’s what your sensibilities allow. It is probably the simplest solution to the problem, just not entirely elegant or consequence free. Everything is a trade-off though, and the complexity of additional conditions should always be weighed.

I understand the approach you are suggesting however it is very difficult when you are dealing with scenes that have 29 different lights that need to be kept in various States. Gets kind of cumbersome to keep writing for each of those scenarios.

I don’t really need to know the condition of the underlying lights, all I am saying is is there anyway to just have the scene rerun every five minutes let’s say just to keep everything up and running

Tiny aside: “LED loads are neither inductive nor resistive.”

I think that Pulse, while neither optimal nor recommended for this scenario, will prove to be the de facto quick-and-dirty method of doing what you want. Yes.

How would you set the pulse?

Probably something like this, pulsing for a couple of seconds (enough to trigger your IS TRUE activity group, that is) and repeat every five minutes ad infinitum:

along this same line of reasoning, i have a RGB light bulb that i want to keep a certain color during specific hours (for example between 9 p.m. and 5 a.m.) and another color during other hours. the issue i am seeing is that when/if someone turns off the light switch that controls the RGB bulb, vera keeps it’s last status (i.e. on), so if the bulb was color 1 at 8, then it was switched off and turned back on at 10, since the bulb appears to be always on, the condition does not re-evaluate. i think this is a good use case for a pulse, but welcome any other suggestions on how to solve the issue.

But if your conditions also monitor the color of the bulb, it will know and fix it.

yep, that’s what i thought too, but the “currentColor” variable holds a value like this:

0=0,1=0,2=255,3=197,4=80

and no matter what i try to do to match it it is always false. My guess is that it is some sort of an array and what i am trying to match is a string. this is what i see in the status…

Device State: RGB Bulb (#240) CurrentColor not equals “0=0,1=0,2=255,3=0,4=0”

0=0,1=0,2=255,3=0… (false) as of 13:30:44

Just out of curiosity, I set up two representations of a Hue Light’s currentColor variable - one using Reactor’s expression builder, yielding string result…

0=0,1=0,2=89,3=58,4=0

…and the other as the same result enclosed in double quotes…


…then tested for equality with itself using two [.eq.] conditions, as shown:

As you can see from the green status, both methods are returning TRUE without a problem on my Vera Plus. I’m using the current latest Reactor 3.6 stable release.

1 Like

Thanks, i tried with quotes and it did not like it at all. i just wrapped it in brackets to make it an array and now it seems to be working. chaged:

0=0,1=0,2=89,3=58,4=0

to:

[0=0,1=0,2=89,3=58,4=0]

thanks for the help!

on a side note, does anyone know what the 0 and 1 values represent in the color array?

1 Like

warm range color temperature and daylight range color temperature, respectively, for white

1 Like

welp, still having problems with this since when the power is turned back on the device, there is not really a change and hence reactor won’t trigger. i think i will try the brute force approach and do the pulse to force it to re-evaluate. thanks to both rigpapa and librasun for the help.

The change will come with an added condition that monitors the state of the light. If you’ve done that, but your activity “fixes” the state of the light when it’s not what you want, that transition will happen so quickly that the Vera UI cannot display it (Reactor’s status display can only refresh as fast as Vera’s UI gives it the data it needs). If you’re judging whether it’s working by what the status display is showing, it’s likely to be wrong in this case. In any case, do what works for you that you can understand; this is always the best answer. There’s no value in giving you a solution you cannot support yourself.

1 Like