Reactor-Editor / Reactor-ui-Status Errors

[LibraSun]

My immediate reaction (if you'll pardon that pun!) is to notice that you have two competing Triggers:
Tripped == 1
and
Tripped (changes) (any) to (any)

Naturally, that pair will ONLY become true when Tripped == 1 immediately after == 0. Hence, you may as well not have the 2nd trigger.
There's more to say, but wanted to lead with that basic fact.

[PerH]

Yes, that's "by design", as i'm only using the "True" reaction in lack of a solution to the basic problem..
If I had some way to make itself false after being enabled for 30 seconds..

(good pun's are always welcome!)

[LibraSun]

My gut tells me you might want to put something in the isFALSE Activity of your Reactor, which will automatically terminate the isTRUE one. When your wife turns on a light, we know that makes the Trigger section become FALSE (because now NOT "All the lights are off"). In which case you don't want the remainder of your isTRUE section to execute.

Having one or more actions in the isFALSE should accomplish this.

[PerH]

hmm.. but if I have "turn off night lights" in the IsFALSE, and the light is manually turned on (in day mode - more light) after this condition is True and night light is on, it will turn them back off immediately..

A bit difficult to explain properly, but in essence i need a way to interrupt this automation on manual input..

[LibraSun]

No, don't put any of your "Turn off" actions in the isFALSE. Put something else (a Comment may even suffice?), anything that won't impact this workflow negatively. So long as isFALSE is non-empty, it will behave as I've described above... effectively truncating the isTRUE Activity the moment the Reactor's AND group goes false (e.g. when wife turns on any light).

[toggledbits]

Generally, using delays in activities isn't going to get you where you are going, I find.

Most people want the lights to go on when motion is sensed, but to remain on until motion has not been sensed for some period of time. That's a two-part problem that you can solve in one step in Reactor.

Let's ignore the time of day component and just focus on the motion for a moment. If you just have a condition to check if the motion sensor is tripped, it will be true when the sensor signals tripped, and reset to false when the motion sensor untrips. So it's pretty clear, you can use that true edge to turn on the lights. The way you get the delay for the off is by using a "delay reset" option on the condition. The delay reset option lets you hold the condition in true state for a period of time after the underlying test has gone false. If you set the reset delay to the amount of time you want the lights to be on in response to motion, and have the false activity turn the light off, then the light will go on when the motion sensor trips, and then at some point after the motion sensor untrips, the delay will kick in and leave the lights alone until the delay expires, and at that point, the condition goes false, the false activity runs (or reset reaction in MSR) and the light goes out. An additional effect of the delay reset option is that if there are several tripped-untripped transitions from the motion sensor during the delay period, indicating someone is still moving about in the sensor's path, the delay is extended, so it's a convenient way to make sure the lights don't just blindly go off after 30 seconds while someone is still standing in the room.

To get the time of day restriction, depends on whether you are doing it in Reactor for Luup (which seems to be what's in the screenshots), or MSR (this category).

• For Reactor for Luup: I would wrap the motion condition in a group, then add the date/time condition as a sibling to the group. Then open condition options for the group, and set the "Condition must occur after" to the date/time condition.
• For MSR: The motion sensor condition and option goes into Triggers, and the date/time condition goes into Constraints (no option needed).

Here's what that looks like in Reactor for Luup:

Note the above screen shot is showing the condition options for the group containing the motion sensor condition. The motion sensor condition itself is not shown because the options are open for display/edit.

[PerH]

Having good logic sometimes depend on wether what you want to do is smart.
This may be one where i save myself some hassle by just delaying from untrip, as suggested. Thanks.

Didn't know that an the False action would interfere with/stop the execution of True group, is that a fact in MSR as well?

I took the liberty to discuss the old reactor in this forum, as i'm suspended from the forum for that one. This thread is however for reactor logic in general, but i realise there may be different approaches in the two..

[toggledbits]

Yes, same in both. The reason is this: if you have the set reaction do something, often the reset reaction is used to undo it. Having both running at the same time, which could happen otherwise, may lead to undesirable effects.

On Reactor for Luup, you can add a separate group and check to see if your main logic group is false, and if so, run its activities. Since these actions are in a separate group, they are not pre-empted.

In MSR, you make a rule to see if the main rule is false, and have its reaction do what it needs to. Same effect.

[PerH]

Makes sense, by all means.

another thing, the "double trigger" I have in my example was something i got from a thread on the other forum, but the result would be the same with one "changes from 0 to 1" right? that would also just be true in one instance?

[toggledbits]

Yeah, that double-trigger probably stems from a misunderstanding of how Reactor works. Reactor acts on changes, not states. So if you have a trigger that checks temperature >= 50, and it goes 49... 50... 51... it will of course go true at 50, and that's when action happens, because the trigger state changes from false to true at that point, but when the temperature goes from 50 to 51, the result of the test is still as true at 51 as it was at 50, so that's no change in state, so no action.

[PerH]

I've now taken this one over to MSR, and one part of the problem is still not solved. The Constraints i have is not time of day, its wether someone turned the lights on in the room. This may happen when the motion trigger have been set, and that means that it will turn the lights off at reset, which at this point have been turned on to stay on..

I think i may have to go back to having the actions in the "set" category, with the delay, in order to be able to intervene the "reset" of the motion sensor state?

One other option is to have another rule for "night light Off", and evaluate Off separately..

[toggledbits]

I would choose opposing rules over delays. I think the topic of handling "manual on" is well-covered in the other forums. The gist is that you can do a little work with an expression variable to track whether the light is being turned on because the switch itself is changing state when there's no motion detection (manual mode), or if motion is detected when the switch is off (automatic mode).

It does have a caveat though: there's little chance of consistent success if the switch used to turn the lights on manually is in the detection area of the motion sensor, as this usually means the motion sensor sees you before you get to the switch, so the automatic on is already happening before you touch it.

[PerH]

It works well now with separate rules for on and off, where "OFF" has the same constraints as "ON", and "OFF" has "ON"-rule changes to false as trigger.

Now, the autolight (which turns on a very low dimming level) turn on, and if someone manually turns the light on at this point, the light goes to the dimming level chosen.
(In this case its not the switch connected to one light that is pressed, its a virtual switch that turns on multiple lights.)