Help with Reactor automations

Plugins & Plugin Development Reactor
#1

I don’t know if I posted in the right section.
How do I determine in the Reactor who is the trigger and what are the conditions?
I can’t create simple automations.

Example:

  • trigger: the gate sensor is not triggered (when the gates are closed)
  • conditions: three lights off and one light on
  • action: the light on at “conditions” to go out.

The logic is the following, when leaving the house, three bulbs go out (in the hall) and the bulb in the yard lights up, then at the exit of the yard by car, after closing the doors the bulb in the yard does not light anymore.
If the three bulbs light up, it means someone stays home and stops the light bulb in the yard.

#2

I suggest you take a look at the tutorial videos here, first: Reactor: Tutorial and Cookbook Videos on YouTube - Reactor - Ezlo Community

If those don’t give you an “ah hah” moment of discovery, let me know and we’ll dig in a bit more.

1 Like
#3

Thanks for the quick response.
I looked … but I don’t understand, I can’t find the logic.
I also tried for some time without results.

#4

Start with something simple. Just one part. Let’s say, when the gate is closed, turn the light yard light off.

Under the “Conditions” tab, add a new condition (how? the videos show you). The condition would be set up like this:

image
image1157×223 12.7 KB

Each device in Vera has state variables, and using the right state variables will tell you everything Vera knows about the status of the device. A typical door sensor is a binary sensor device type, and binary sensors can be tripped or untripped. A smoke detector, for example, is also a binary sensor, and when it’s tripped, you know you’ve burned breakfast. Assuming you have a door sensor on your carpark gate, it would normally be tripped when it is open, and untripped when it is closed, so in this text, we are checking the state of the “Gate Sensor” device, variable “Tripped” to see if it is false (which means untripped).

Now, Reactor is driven by changes in state. Any time the state of the “Gate Sensor” changes, the above condition will be re-evaluated. If the state becomes false (the gate closes), as the condition configuration says, the condition state will change to false.

Notice that the condition we added is in a group–in my screen shot, the group is called “Reactor Sensor 9”. It happens to be the top group, which is the container for all other conditions and groups. That’s also referred to as the “root” group. Notice that the “AND” button is highlighted next to the group name. That means that for the group to be true, all conditions inside the group must be true. Since there’s only one condition (the one we added), the group will be in whatever state that condition is in (true or false).

We need to make Reactor respond to that and turn off the yard lights. In Reactor, every group can have Activities associated with them. If we go the “Activities” tab, it should look something like this (if your group name is different, it will of course have your group names listed, but otherwise about the same):

image
image1156×305 16.9 KB

At the moment, there are no actions in these activities. But notice there are two activities for our group, one for when it becomes true, and one for when it becomes false. Our condition is set up that it will become true when the gate is closed, so let’s add a Device Action to the “ReactorSensor 9 is TRUE” activity:

image
image1153×154 10.8 KB

Now, then the gate closes, the “is TRUE” activity will run, and its one action will turn off the yard lights.

Is this helping?

#5

Thanks!
I know how to make automations like this.
This is something that interests me:

> - AUTOMATION
>   trigger:
>   - platform: state
>     entity_id: GATE SENSOR
>     to: 'off'
>   condition:
>   - condition1: state
>     entity_id: HALL1 BULB
>     state: 'off'
>   - condition2: state
>     entity_id: HALL2 BULB
>     state: 'off'
>   - condition3: state
>     entity_id: HALL3 BULB
>     state: 'off'
>   - condition4: state
>     entity_id: YARD BULB
>     state: 'on'
>   action:
>   - service: switch.turn_off
>     entity_id: YARD BULB
#6

If I’m reading this right:

On the Conditions tab you’d pick device state > Gate Sensor > Untripped (or whatever the correct status is for that device)
Then on the activities:
Device Action > Hall1 > Turn on or off > Turn off
Repeat for Hall2 and Hall3
Then
Device Action > Yard Bulb > Turn on or off > Turn on.

Not sure about your last action or what you’re attempting to do.

Undoubtedly Patrick will fill in correcting my phrasing and possibly with screen shots ('cos he’s ace) but hopefully that should get you moving?

C

#7

It doesn’t work that way.
I need an automation that when closing the doors the light goes out only if all 4 conditions are true.
I am not interested in any action for the 4 devices listed under the conditions. If one of them is not correct the action is not executed, respectively the bulb does not stop…

The logic is the following: when leaving home in the dark by car, if no one stays home, 3 lights stop in the hall (hall1, hall2 and hall3) and the light bulb starts in the yard. After leaving the yard and the gates are closed the bulb in the yard should stop.

If someone stays home, when leaving a family member, they do not stop all the 3 bulbs in the hall (maybe one, two or all three to light up), the bulb starts in the yard and when the doors are closed at the departure the bulb in the yard does not stop . Who stays home stops the light bulbs in the hall and the yard.

#8

This automation has a friend who has another hub and that is exactly what I want.

#9

OK
I’m struggling a bit understanding your use case, but…

I don’t think you need a trigger. I’d try adding all the gate sensor and the hall bulb to a set of AND conditions.
I’m assuming that the Gate sensor makes some kind of change which will efffectively make it a trigger, but in actuality it’s just another thing that needs to be true.

Make any kind of sense?

C

#10

Not working. When the gate is closed and the bulbs in the hall become off, the bulb in the yard also become off.

#11

The only trigger must be the gate sensor. Operating the devices from the conditions must have no effect on the action.

#12

I’m lost then, sorry :frowning:
C

#13

That’s a sequence in Reactor parlance. You want to trigger actions only when the gate closes after the light conditions have first been met.

Something like this (working from your YAML):

  • Group “Light Control” (root group) - NUL operator
    • Group “Light State” - AND
      • Device State HALL1 BULB Status is FALSE
      • Device State HALL2 BULB Status is FALSE
      • Device State HALL3 BULB Status is FALSE
      • Device State YARD BULB Status is TRUE
    • Group “Gate Sense” - AND
      • Device State GATE SENSOR Tripped is FALSE - add option: Condition must occur after Group Light State

The condition options are opened by clicking the downward-pointing chevron (yellow and showing open in below image):

image
image1081×413 28.8 KB

The sequence restriction is the first line in the “Restrictions” section of the options.

Action to turn off the yard light should go on the “Gate Sense is TRUE” activity only.

#14

Thank you very much.
In the meantime, I’ve done other automations on this principle.
Something tells me I’m going to bother you …

2 Likes
#15

Is there a recommendation on the number of automations in a sensor?
Is it better to have more sensors or fewer? How does this affect functionality?

#16

I think you can have all your automations in one instance if you so desire. I understand it has a very low overhead.

Because I can’t document anything and struggle to understand my own logic at times, I’m trying to keep one reactor per room and have it trigger and triggered by things in that room.

I am failing at this but certainly have up to 10 sub groups in some of my reactors.

Performance of my network is great, apart from the ‘normal’ Alexa lags

C

#17

Have as many ReactorSensors as makes sense to you. They are very light weight. Arrange them in a way that you find manageable.

Also @Catman, remember that using the ReactorSensor’s overall tripped state is the “old school” way, from before Reactor had its own activities to replace or supplement scenes. The “new” way is to put your activities on the groups themselves. This avoids worrying about how all the groups affect that overall tripped state–you just ignore it. In most of my own RSs, my root group is NUL now.

Oh, and don’t forget you can put comments in both conditions and activities.

#18

Cheers @rigpapa I certainly do have activities on the reactor groups. Pretty sure I don’t have any activity on an overall reactor actually :slight_smile:
C

1 Like
#19