Delay reset?

TomD · May 2, 2019, 7:41pm

I get here but don’t see how to fill in the id or type in the Only after box.

What am I missing?

Thanks,
Tom

rigpapa · May 2, 2019, 7:59pm

You need to have more than one condition in the group. When you do, the other conditions will be listed there.

Also, what’s the connection between the subject and your question?

TomD · May 2, 2019, 9:21pm

Thanks for the quick response.

Delay reset is what I am trying to get working on some kitchen counter lights. They should come when motion is detected and then turn off 15 minutes after there is no motion.

Is there an example of what this configuration should look like?

Thanks

rigpapa · May 2, 2019, 9:32pm

Ok. So for starters, you are using the wrong option. So clear that out.

In 2.x, you will need two ReactorSensors–one to turn the light on, and one to turn it off. In 3.0 (coming in a few days) you’ll only need one.

For 2.x:

RS1
Group 1

Condition: motion sensor Tripped is TRUE
Tripped Activity: turn on light

RS2
Group 1

Condition: motion sensor Tripped is FALSE + option: sustained for at least 900 seconds (15 minutes)
Tripped activity: turn off light

TomD · May 4, 2019, 5:23pm

I’m still working on this. The lights turn on fine when someone is at the kitchen counter. I’d like the lights to stay on for 15 minutes after the last time motion was detected. If someone is working at the counter for 30 minutes and then walks away the lights will be on for 45 minutes. If someone works at the counter for 30 minites, leaves and then returns to the counter after 10 minutes the lights will stay on till 15 minutes after they leave again.

This is what I have now for the off ReactionSensor:

rigpapa · May 4, 2019, 5:39pm

If you look back at my recommended configuration for 2.5 (two sensors required):

RS1 turns on the lights when motion is sensed. This should be pretty straightforward.
RS2 turns off the lights when no motion has been sensed and that state has persisted for 15 minutes.

In 3.0, you can just use two groups rather than having two sensors, but the config is otherwise the same.

There is a less intuitive configuration for 2.5 that you can pull off in a single sensor:

Group 1 (the only group)

Counter Motion sensor Tripped IS FALSE + option “condition is sustained for 900”

Activities:

Tripped action: turn off light
Untripped action: turn on light

In this configuration, the ReactorSensor will be tripped when no motion has been detected for 15 minutes. So the trip action can go ahead and turn off the light. If there is motion, the RS is instantly untripped, so the untrip action turns on the light. So by turning the logic backwards, we can do it in one ReactorSensor. I haven’t recommended this in the past because people often have more conditions they later add, and this can paint them in a corner if they’re not used to thinking of their goal in reverse.

TomD · May 4, 2019, 7:19pm

First, thanks for all you help.

I think my question is more basic than your answers. I don’t know what or how to fill in the forms I posted an image of to get the results I described. I don’t see a “Delay reset” in any of the condition choices.

Thanks again.
Topm

rigpapa · May 4, 2019, 8:59pm

OK. So let’s go back to my previous instructions:

Here are the steps in detail:

Open your ReactorSensor and go to the Conditions tab.
Clear out anything and everything you have created there, so you start with a clean slate.
Add a new condition.
Select “Service/Variable” for that condition’s type.
Select your motion sensor as the device.
Select “Tripped” for the device state variable.
Select “is FALSE” for the condition operator.
Click the downward pointing chevron/arrow to the right of the operator to open the condition options.
Go to the line that starts “Condition is sustained for” and enter “900” in the seconds field to the right of the menu (which defaults to “at least” and should be left that way).
Click the “Save” button.

At this point, you have a single condition in the only group. When that condition is true (i.e. when no motion has been detected for 900 seconds, which is 15 minutes), the condition will go true, and so the entire ReactorSensor will go into Tripped state. If there is motion at any time, the condition goes false, and the ReactorSensor becomes untripped.

The “sustained for” option is used to provide the delay. When the motion sensor reports there is no motion, Reactor starts a timer and, if throughout the timing period, the motion sensor never reports motion again, then when the timer expires, the condition goes true. If motion is detected during the timing period, the condition remains false.

Now, for actions:

Go to the Activities tab.
In the “Tripped” activities, create a new action.
Select “Device Action” as its type.
Select your light switch.
Select “turn device on/off” (aka SetTarget in the SwitchPower1 service).
Set the “NewTargetValue” value to 0 (which turns the light off).
In the “Untripped” activities, repeat steps 2-6 above, but instead of setting “NewTargetValue” to 0, set it to 1. This turns the light on.
Hit “Save”.

Bob’s your uncle.

TomD · May 4, 2019, 11:32pm

Thank you very much. I think Bob may indeed be my uncle.

I ended up with:

and:

and it seems to be working. I tested with some shorter times and it looked to be working. The issue us if the lights turn off while we are working at the counter. This should end a major frustration I have had with our light control.

Thanks again for your help.

Tom

rigpapa · May 5, 2019, 1:46pm

Good news!

In future, it’s generally a bit easier, and actually much more useful to me, if you post a “Logic Summary”, for which you will find a link in the Troubleshooting section of the Tools page of your ReactorSensor. Especially when your rule lists start getting long, it will be a lot easier than doing multiple screen grabs, and it also gives me other information, incurring current states and recent transitions, that can help me work things out.

Give my best to Bob.

TomD · May 5, 2019, 7:45pm

I can see where the Logic Summary would be helpful to you in trying to figure out what is going on. I needed to see an example of the completed form to get me going in the right direction with the Delay Reset capability of Reactor.

I’ve been unhappy with the way these lights work for years and am pleased to have the issue resolved. I was right on the verge of replacing the switches with WiFi devices and using Google Home to verbally turn the lights on and off as we needed them. Automatic control with the motion sensors is much more convenient.

Thanks again for your help, especially while I know you are busy putting out a new version of Rector.

Tom

TomD · May 8, 2019, 7:17pm

The light went out while I was working at the counter today. I don’t know if I didn’t test enough or if something has changed.

Here is the Logic Summary:

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.0 config 301 cdata 19082 ui 19125 pluginDevice 41
    System: Vera version 1.7.4453 on Sercomm G450; loadtime 1557342555; systemReady 1557342573; Lua 5.1
Local time: 2019-05-08T12:09:47-0700; DST=1
House mode: plugin 1; system 1; tracking off
  Sun data: 
  Geofence: not running
     Power: ?, battery level ?
====================================================================================================================================
Counter Lts Control (#50) tripped
    Version 19082.1557176408 05/06/19 14:00:08
    Message/status: Tripped
    Condition group "grpcqara0u" (AND) TRUE as of 12:04:51 <root>
      &-T-service Counter Motion (7) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped isfalse 0 for ge 900s [1 => 0 at 11:49:51; T/T as of 11:49:51/12:04:51] <condcqara0v>
    Activity root.false
        Device 12 (Counter Lights) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
    Activity root.true
        Device 12 (Counter Lights) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )
    Events
        05/08/19 12:09:28 start:

rigpapa · May 9, 2019, 12:17am

That would indicate that there was not sufficient motion to trip the motion sensor. It’s not unlike coming into a room and sitting still in a chair reading–unless you move around enough to trip the sensor, you’re eventually going to be trying to read in the dark.

It looks like Luup reloaded right before you generated this Logic Summary, so there’s no history in the report. But if it happens again, go look at the “Events” section of the summary, and don’t reload before pulling the summary–you should see the progress of events, and I’ll bet the motion sensor signals untripped 15 minutes before lights-out.

TomD · May 9, 2019, 1:40am

I was standing at the counter fixing lunch so continuous motion. I doubled the watch for motion time from 900 to 1800 seconds to see if that helps.

I saw in a different thread you will be doing some videos to show us how to set Reactor up. I think that will help folks like me a lot.

Thanks again,
Tom

rigpapa · May 9, 2019, 2:07am

You might also watch the status display (if you can) while moving around the counter. Here from the Logic Summary:

&-T-service Counter Motion (7) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped isfalse 0 for ge 900s [1 => 0 at 11:49:51; T/T as of 11:49:51/12:04:51]

The relevant stuff, the most recent timing and state, is in square brackets at the end. Reading from left to right, the device Tripped variable transitioned from 1 to 0 at 11:49:51; it’s current condition state is true (the first T), and its evaluation state was also true (the second T), with the former coming at 11:49:51 (the same time the value went to 0), and the latter occurring at 12:04:51–15 minutes to the second later. So it looks like the logic was working as expected.

It is quite possible Vera missed one or more motion trip signals from the device. The fact that it looks like your Vera reloaded just a few seconds before you generated the report makes me a bit suspicious–if you didn’t cause the reload, and your Vera reloaded spontaneously, you should check the log and look in more detail. If your Vera is reloading a lot, you will certainly miss device events.

If you create a ReactorSensor that only has a Luup Reloaded condition in the root group, you’ll be able to easily see the timing of reloads on its Status tab. The RS also keeps a state variable (TripCount) with a count of trips (reloads, with this configuration), visible in the RS’s Advanced tab, Variables sub-tab.