"Poke" a Reactor Sensor

Plugins & Plugin Development Reactor
#9

If you simplified your ReactorSensor to a single condition that only tests temperature > 77F, then if your temperature sensor updates every five minutes, Reactor is rechecking the condition every five minutes. Every time your sensor updates TemperatureSensor1/CurrentTemperature, Luup fires the watch callback to Reactor. That’s true whether Retrigger is 0 (the default) or 1, because Reactor is notified by Luup every time the sensor updates.

The difference Retrigger makes is what Reactor does when the condition is met (e.g. the temperature really is > 77F). When Retrigger=0, then the first time the condition is met, the ReactorSensor sets Tripped=1, and that’s it, it will not set Tripped again until the condition becomes false (temp 77 or less, when it will then set Tripped=0). But, if Retrigger=1, then every time the sensor updates and the temperature is still > 77F, the ReactorSensor will set Tripped=1 again.

Or put another way, if we look at a sequence of temperature measurements, here’s what Reactor does with Retrigger=0 (the default):

Temp Action 76 Do nothing (condition not met) 77 Do nothing (condition not met) 78 Set Tripped = 1 (condition met) 79 Do nothing (already tripped) 80 Do nothing (already tripped) 75 Set Tripped = 0 (condition not met) 74 Do nothing (condition not met)

And with Retrigger=1 (alternate behavior):

Temp Action 76 Do nothing 77 Do nothing 78 Set Tripped = 1 79 Set Tripped = 1 80 Set Tripped = 1 75 Set Tripped = 0 74 Do nothing

#10

perfect ,got it, thats what i thought
further tested and confirmed

now if there was just a way to enable the retrigger based on a condition
or the opposite and steal an idea from your light timer
a re-trigger inhibitor
then we could inhibit the retrigger based on conditions being true or not true using invert

is this something you would consider since its in your other app?

#11

You have to clarify for me why you would need to do that. Even so, an inhibit condition is just an AND added to other conditons (e.g., othercondition AND not inhibitcondition), and you can do that with the existing logic.

#12

i dont want to inhibit the conditions
i want to inhibit the retrigger being active

in my case i only want it to retrigger while we are sleeping and my thermostat running mode is night/sleep
so retrigger can be inhibited by a particular trigger
in my case that would be thermostat running mode not equal to sleep

so retrigger would = 0 as its inhibited
but as soon as thermostat is sleep
the retrigger would not be inhibited
therfore retrigger would =1

#13

You’re not really giving me enough to understand what problem you’re trying to solve, so the request seems really odd to me. But, if you feel you need to do it, here’s how:

Create two scenes. Scene #1 – triggered by the thermostat going into “sleep” mode (either a direct trigger using the thermostat, or you can make another ReactorSensor to look at the thermostat’s mode and device if it’s sleep or not), runs this Lua code:

luup.variable_set( "urn:toggledbits-com:serviceId:ReactorSensor", "Retrigger", 1, reactorsensor_device_num ) return true -- always end scene lua with a return bool

Then make the counter-scene – triggered by the thermostat leaving “sleep” mode (again, direct device trigger, or using the not-tripped test of the ReactorSensor created for the first scene), runs this Lua code:

luup.variable_set( "urn:toggledbits-com:serviceId:ReactorSensor", "Retrigger", 0, reactorsensor_device_num ) return true -- always end scene lua with a return bool

#14

i currently have 2 scenes that does exactly that
but you also need to reload luup as the new value only takes effect after the reactor restarts
i was just hoping to have it in the app as an option
it would eliminate extra scenes and be cleaner and be easier to manipulate

to help understand the problem i am trying to solve

the reasoning behind it is that when retrigger is enabled
as you mentioned
it puts more load on the system
which i want to avoid as much as possible

i only want to allow that extra load on the system under certain conditions
that condition is typically only met sometime after midnight and up to 6am or later
everyone asleep, no motion, no occupancy, etc…
so i dont mind the extra load as the controller is not doing much

#15

[quote=“charettepa, post:14, topic:199808”]i currently have 2 scenes that does exactly that
but you also need to reload luup as the new value only takes effect after the reactor restarts[/quote]

This is not correct. Changing the value of Retrigger is effective immediately, and will be noticed the next time a device changes and conditions are evaluated.

the reasoning behind it is that when retrigger is enabled as you mentioned it puts more load on the system which i want to avoid as much as possible

The load on the system is negligible. The Reactor is responding anyway every time the temperature changes, regardless of what the house mode or sleep state of your thermostat is. Every change wakes Reactor up so it can see what it needs to do. The only additional overhead is that of your scene execution, which for setting a fan controller to a prescribed speed is a tiny effort. I don’t even think it’s worth the return on investment for you to implement the two scene Lua control over it, but it’s there if you really want to do it.

EDIT: To be clear, what would load the system is having the house mode check retrigger–that’s why we moved it off. Even so, that load isn’t much, and I don’t think any Vera 3 or above would even whimper at the task (including executing your scene). It’s just best-practice.

#16

actually its putting heavier load on zwave system than needed
as when it retriggers it resends the fan switch loadstate to the desired level
even if already at that level
this is happening for all 3 bedrooms
so every 4-5 minutes a zwave command is sent to all 3

i suppose i could add a piece of luup code that says not to send the command if the current state
is already the value it is sending
ie set fan to 60%
with luup code that blocks the scene from running if the current state is 60% (device loadstate <> 60)
i’m just trying to avoid additional devices and extra scenes
i like to keep it clean

#17

i understand these are your applications and it is up to you to change or not change as you see fit
i truly appreciate these applications
i am just trying to get involved and add value/functionality where i think myself others could also benefit

please do not misinterpret my comments/suggestions/requests as disrespect

i highly respect the work you have done

#18

[quote=“charettepa, post:16, topic:199808”]actually its putting heavier load on zwave system than needed
as when it retriggers it resends the fan switch loadstate to the desired level
even if already at that level
this is happening for all 3 bedrooms
so every 4-5 minutes a zwave command is sent to all 3[/quote]

Well, if your network can’t take 3 Z-wave commands every 5 minutes, you may have other problems! :slight_smile:

i suppose i could add a piece of luup code that says not to send the command if the current state is already the value it is sending ie set fan to 60% with luup code that blocks the scene from running if the current state is 60% (device loadstate <> 60)

Actually, let’s take a step back here. I kind of feel like you’re trying to have it both ways–you want Retrigger, but you don’t want the effect of Retrigger. Let’s go back to the original problem, which was that your fan control switch comes up “off” after a power failure, and because your battery-backed Vera Secure rides that out (doesn’t restart) and doesn’t see that the switch reset, the state of the device on the Vera side is out of sync, and your fan never recovers after the power failure. So to start, we’re working pretty hard to solve a problem that I would think is actually pretty rare. But I agree it’s worth solving, and I’m sure we can.

I propose that a better solution may likely be turning Retrigger back off (Reactor’s default), and making sure your fan control switch has a reasonable polling interval set. When Vera polls the device, it will update the status, so if the polling interval is relatively short (say 600 seconds or 10 minutes), it would soon discover the fan’s new post-power-fail off state. Then, if you add a specific check to your ReactorSensors to make sure the fan is in the right state (your “loadstate <> 60” test), done correctly, that should make the ReactorSensor trip to bring the fan back up to the correct speed. No retrigger necessary.

And don’t worry. I’m all about discussion and figuring out what needs to be done. That will never offend me. But both Reactor and DelayLight have a very clear charter in my mind: keep it light, keep it clear. I don’t want to clog in features where other approaches can be made to work, so I want to make sure I pursue those first.

#19

thanks for your response
im glad you are not offended
and discussing this solution with me

also you are correct, its a rare issue and is not likely worth all the time i am putting in to it

i really do think the best solution is the retrigger that you suggested but with the additional luup code that only fires the scene if the switch state is not what its sending

i think the best of both worlds with the least amount of stress on the system is as follows

the out of sync fan switch does catch up within about 10-15 minutes already
thats less of an issue

the issue is that
the fan is now off
and the reactor sees that its off
but one of the other groups are on
so its still triggered but not turning it on as its not re-triggered
so retrigger does solve that issue

the frequent retrigger issue was solved by you yesterday
by moving the homestate to its own reactor

i also have retrigger only active for those 3 rooms overnight while asleeep/no occupancy/ no motion

and now finally to minimize excessive zwave sends
i can just use luup to only allow the scene to run if the desired load state is not currently true

i think this will work
its multiple pieces but gets the job done
thanks for being so active in finding a solution
i will let you know if it continues to function as expected

#20

[quote=“JJ10, post:1, topic:199806”]For one of my lights i have three options how the light can be turned on:

  1. Via motion during daytime → Light is set to 100% – light should be turned off after 5 min
  2. Via motion during nighttime → Light is set to 20% → light should be turned off after 5 min
  3. Manual by switch at all time → Light is set to 100% → light should be turned off after 1 hour[/quote]

You could probably work that out in steps with Reactor, but since you’re already using DelayLight, I don’t think you need to. Here’s how I would address your question:

First, since your motion timings are both 5 minutes, set your DelayLightTimer’s auto delay to 300. Manual at one hour would be 3600 seconds. Set the DLT’s trigger device to be your motion sensor, as you normally would. Then, set the “off” list to the controlled light, but leave the “on” list empty for the moment.

Jump out and create a single scene with manual triggering and no devices, but at the final page, copy/paste this (and edit in your light’s device number) into the scene’s Lua (click “Also, execute the following Luup code” to get to the Lua insert block).

local controlledLight = <device number of your light> local brightness = 100 if luup.is_night() then brightness = 20 end luup.call_action( "urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", { newLoadlevelTarget=brightness }, controlledLight ) return false

Save this scene. Then go back to your DLT, and set the “on” list to this new scene.

That should be all you need. No ReactorSensor necessary for this setup. The function of the scene Lua should be pretty straightforward. The trick here is that the DLT is watching both the “on” list and the “off” list for manual triggering. Since the “on” list is a scene with no devices, there’s nothing to see, but keeping the light in the “off” list makes it visible to/watched by the DLT, and also lets it turn it off directly when timing expires.

#21

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)?

#22

[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.

#23

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).
#24

Thanks for the plugin :slight_smile:

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

#25

[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.

#26

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.

#27

6 posts were split to a new topic: Read ReactorSensor trip state with Lua?

Read ReactorSensor trip state with Lua?
#28