"Poke" a Reactor Sensor

[JJ10]

Thanks again Rigpapa, this will work (I will try in a few days).

But does this mean that you suggest first to use DLT’s before Reactors when you can use both (and before PLEG)?

I also want to turn off the light in the garage when it’s on for say 30 min. Should I do this with DLT, reactor or … (What is beter for the Vera)?

[rigpapa]

[quote=“JJ10, post:21, topic:199808”]Thanks again Rigpapa, this will work (I will try in a few days).

But does this mean that you suggest first to use DLT’s before Reactors when you can use both (and before PLEG)?

I also want to turn off the light in the garage when it’s on for say 30 min. Should I do this with DLT, reactor or … (What is beter for the Vera)?[/quote]

I’ve made an effort to be very careful with both–they are designed to be as light on the system as possible in normal operation. DelayLight’s configuration UI is simpler, so there’s less JavaScript to implement it (about half) and therefore its footprint on disk is a bit smaller than that of Reactor, but they have about equal RAM footprints when running. Additional DelayLightTimers or ReactorSensors add very little, because they are “thin” children–they pretty much just store data specific to that child, but the parent code is re-entrant and handles all of the children (i.e. no matter how many sensors or timers, there’s only one copy of the code in memory). And although I do a lot of development on openLuup, my benchmark Vera is a 3, so if it doesn’t perform well on that, it’s not meeting my objectives.

Your “light off in the garage” example can be done either way, because it’s within the narrow boundaries of the problem DelayLight was written to solve, but also can be handled by the much wider net cast by Reactor. For this particular example, assuming no other conditions other than perhaps a motion sensor, DelayLight will be easier for you, because it can do all of the work without scenes (your prior example only needed a scene because of the time-based brightness modification). Reactor is only a triggering device (currently), so you still need scenes or Lua to make it do work (I’m adding built-in scene support to it, but that’s not ready for release yet).

If you want a rule of thumb, I’d say this: if the core of the problem you are trying to solve is timing, start with DelayLight; if it’s coordinating events and states, start with Reactor. If along the way you find DelayLight doesn’t have adequate triggering abilities, you can add a ReactorSensor to do that work, or even move the entire job to Reactor.

[rigpapa]

Version 1.3 is now available in the AltAppStore, and should be approved in the Vera Plugin Marketplace tomorrow. It offers the following:

• Repeats over time. It is now possible to create a condition matching a number of repeats of a state over time, for example, a sensor that trips 3 or more times within a 5 minute period. This is configured in the condition options for service/variable conditions.
• Implement variables and expression parsing. Users may configure variables whose value is the result of a complex expression. This uses LuaXP (like SiteSensor), with some added functions for locating devices and retrieving state variable values. Additional functions to be added as need becomes evident. These variables are stored in state on the ReactorSensor, and so are available systemwide, as well as within the ReactorDevice for condition matching.
• Implement “Luup Reloaded” condition, which is true the first time it is evaluated after a Luup restart.
• Implement “TripCount” variable to complement “Runtime”; counts the number of times the ReactorSensor has tripped; reset by ResetRuntime action.
• Move housemode check to master tick on parent device; ReactorSensors no longer poll for house mode changes (the parent notifies them via watch callback);
• Fixed a typo in the conditions UI that causes an erroneous condition expression to be generated for “not equals” service values (issue #4). This fix was released to “stable” on 2018-07-09.
• Fix the name of the “Trip” button in the ALTUI dashboard card.
• Initialize (if needed) SecuritySensor1’s AutoUntrip variable (default 0). When non-zero, Luup automatically untrips the sensor after the configured number of seconds (this is a somewhat-hidden Luup feature being exposed).

[rotbard]

Thanks for the plugin

I didn’t understand how to use Sunrise/Sunset
I tried to set a trigger that works 1/2 Hr after Sunset
Where is the sunset time comes from?

I want to turn garden light on when its Night and the roller Shutter is open
But Night status switch into night when there is still light outside

[rigpapa]

[quote=“rotbard, post:24, topic:199808”]I didn’t understand how to use Sunrise/Sunset
I tried to set a trigger that works 1/2 Hr after Sunset
Where is the sunset time comes from?[/quote]

Reactor uses Luup’s calculated sunrise/sunset times. So first, you need to make sure that your Vera is configured with both the correct location (city, region, country, latitude and longitude), and time zone.

I want to turn garden light on when its Night and the roller Shutter is open But Night status switch into night when there is still light outside

You seem to be on the right track based on the screen shot, except for the first line. Looking at both the “Day or Night” plugin and sunset is redundant. Remove that first line.

Your second line tests what I assume is your roller shade, for load level > 50. I don’t have or use Z-wave shades, so I’m not sure how they integrate, but if they use LoadLevelStatus as your rule suggests, this looks like it will be true when your shades are open more than half way (50/100). Your screen shot also shows that at the moment you took it, the shades were open 100%, so that condition is true (showing “true” and highlighted green).

The third line is the sunset test, which seems OK. The resolution/scale of the screen shot combined with my poor vision, I can’t tell if it reads “sunset+30” or “sunset-30”, but it should be “+30” based on what you are describing and I’ll assume that’s what it is. Since this is an “after” condition, it will be met (true) from 30 minutes after sunset until midnight; after midnight, this condition will be false. If you want the lights on from sunset+30 to sunrise (or sunrise-30, for example), you would need to use a “between” condition. But what you have will work, just know that the light will turn off at midnight unless you change it to “between”.

The ReactorSensor will trip when ALL conditions in any group are met. So, if your shades are up > 50%, and the time is after today’s sunset+30 minutes, then the sensor will trip, and if your “garden light on” scene is set to trigger when this ReactorSensor is “tripped whether armed or disarmed” your scene will run. The ReactorSensor will untrip when the conditions are no longer met (i.e. it’s after midnight, or you close your shades), so you need a scene “garden light off” that triggers when this ReactorSensor “restores from tripped whether armed or disarmed.”

You can use the time control on the “Test” tab to manipulate what the ReactorSensor thinks the current time is, so you can test the sensor without waiting until actual sunset. Just set a time, then go back to the Control tab and his the “Restart” button to make the sensor re-evaluate its conditions. When you are finished testing, remember to turn the override off on the Test tab.

[rotbard]

Thanks.

I knew what went wrong…

The time check box on TEST tab was stuck as marked v.
So the plugin didn’t use real time.