Hi there,
I have an outside awning that I am attempting to fit into reactor but one requirement I am struggling to fit into reactor.
The awning is set to auto deploy if in home mode, if light sensor goes about 900 and humidity sensor is <90% but often sun may go behind clouds dropping the light sensor level below 900 for 10 or 15 mins or so. Currently I use a countdown timer with various other virtual switch?s to stop the awning for going in and out frequently and also trying to go out twice. Is there a way to currently do this in reactor or might it be possible to add a delay timer into reactor to delay the change or state to tripped or not tripped?
This way if the reactor was tripped and sun went behind clouds for 10 mins (changing the reactor state to not triggered) I could set a delayed change condition for not triggered for 15 mins giving time for all conditions to be met again and this not moving the awning in and out all the time.
[quote=“PrincessCleavage, post:1, topic:200373”]Hi there,
I have an outside awning that I am attempting to fit into reactor but one requirement I am struggling to fit into reactor.
The awning is set to auto deploy if in home mode, if light sensor goes about 900 and humidity sensor is <90% but often sun may go behind clouds dropping the light sensor level below 900 for 10 or 15 mins or so. Currently I use a countdown timer with various other virtual switch?s to stop the awning for going in and out frequently and also trying to go out twice. Is there a way to currently do this in reactor or might it be possible to add a delay timer into reactor to delay the change or state to tripped or not tripped?
This way if the reactor was tripped and sun went behind clouds for 10 mins (changing the reactor state to not triggered) I could set a delayed change condition for not triggered for 15 mins giving time for all conditions to be met again and this not moving the awning in and out all the time.[/quote]
There is a “sustained for” option on conditions that you can use for such a purpose. If you haven’t seen the condition options, they are hidden until you click the downward-pointing arrow next to the value field when you are creating/editing a service/variable type condition. Here’s how I would approach your problem using that:
I would make a separate ReactorSensor called “TooDark” or something of that nature. The condition for this sensor would be a single service/variable condition: LightSensor CurrentLevel < 900, and turn on the option “sustained for” and set it to, let’s say 900 seconds (15 minutes). So this sensor will be FALSE/untripped when the light level is 900 or more. If the light level goes below 900, it won’t react immediately, it will have to stay below 900 for at least 15 minutes, and if that happens, the condition will then be fully met and the ReactorSensor will go TRUE/tripped. Note that this inverts the sense of your test, but it’s easier that way. Sometimes you have to turn the logic around to get to the easy answers.
This new ReactorSensor now serves as a proxy for our light sensor: it’s a filtered version of its output that is only TRUE when the light level has been below 900 for an unbroken period of 15 minutes or more. I would then use that in my shade sensor logic (building your rules as stated above):
Condition Group 1:
- House mode is “Home”
- TooDark Tripped=0
- HumiditySensor CurrentLevel < 90
Note that we’ve also used two ReactorSensors for this job. Sometimes it’s easier to break your logic up into parts like this. ReactorSensors are cheap on resources by design; you could create hundreds of them and not significantly drag on memory or CPU.
Thanks I will give this a try
Nice and very handy hidden feature here (drop down option for delays) I have actually made redundant several countdown time devices after finding this feature.
Thanks!
[quote=“rigpapa”][quote=“PrincessCleavage, post:1, topic:200373”]Hi there,
I have an outside awning that I am attempting to fit into reactor but one requirement I am struggling to fit into reactor.
The awning is set to auto deploy if in home mode, if light sensor goes about 900 and humidity sensor is <90% but often sun may go behind clouds dropping the light sensor level below 900 for 10 or 15 mins or so. Currently I use a countdown timer with various other virtual switch?s to stop the awning for going in and out frequently and also trying to go out twice. Is there a way to currently do this in reactor or might it be possible to add a delay timer into reactor to delay the change or state to tripped or not tripped?
This way if the reactor was tripped and sun went behind clouds for 10 mins (changing the reactor state to not triggered) I could set a delayed change condition for not triggered for 15 mins giving time for all conditions to be met again and this not moving the awning in and out all the time.[/quote]
There is a “sustained for” option on conditions that you can use for such a purpose. If you haven’t seen the condition options, they are hidden until you click the downward-pointing arrow next to the value field when you are creating/editing a service/variable type condition. Here’s how I would approach your problem using that:
I would make a separate ReactorSensor called “TooDark” or something of that nature. The condition for this sensor would be a single service/variable condition: LightSensor CurrentLevel < 900, and turn on the option “sustained for” and set it to, let’s say 900 seconds (15 minutes). So this sensor will be FALSE/untripped when the light level is 900 or more. If the light level goes below 900, it won’t react immediately, it will have to stay below 900 for at least 15 minutes, and if that happens, the condition will then be fully met and the ReactorSensor will go TRUE/tripped. Note that this inverts the sense of your test, but it’s easier that way. Sometimes you have to turn the logic around to get to the easy answers.
This new ReactorSensor now serves as a proxy for our light sensor: it’s a filtered version of its output that is only TRUE when the light level has been below 900 for an unbroken period of 15 minutes or more. I would then use that in my shade sensor logic (building your rules as stated above):
Condition Group 1:
- House mode is “Home”
- TooDark Tripped=0
- HumiditySensor CurrentLevel < 90
Note that we’ve also used two ReactorSensors for this job. Sometimes it’s easier to break your logic up into parts like this. ReactorSensors are cheap on resources by design; you could create hundreds of them and not significantly drag on memory or CPU.[/quote]
I had to switch to emby forums as Vera forums see to have a PM message limit
Does it work for geofences too (I can’t see such option if I choose geofence)?
My idea is to trigger some event if I pass two geofences in a certain order within specified period of time. I can do it with a virtual switch (switched on by entering geofence 1 and then off after specified period of time) and a logic that if I enter geofence 2 and virtual switch is ON then run an action.
I would like to avoid virtual switch and Reactor’s logic “sustained for” would be a perfect replacement (Reactor sensor would stay “Triggered” during a certain time after entering geofence, even If I already left it.
Does it work for geofences too (I can’t see such option if I choose geofence)?
My idea is to trigger some event if I pass two geofences in a certain order within specified period of time. I can do it with a virtual switch (switched on by entering geofence 1 and then off after specified period of time) and a logic that if I enter geofence 2 and virtual switch is ON then run an action.
I would like to avoid virtual switch and Reactor’s logic “sustained for” would be a perfect replacement (Reactor sensor would stay “Triggered” during a certain time after entering geofence, even If I already left it.[/quote]
“Sustained for” operates a little differently from what you’re describing. With the current “sustained for” (which does not work for geofence conditions yet, but can be added), the condition would not go true at all until the condition has been met for the prescribed period, and it would not go true at all if the condition’s test went back to false before the expiration of the period. If/when the condition meets the sustaining period, it then goes true (so there’s a delay in the transition from false to true), but then goes immediately false when the condition’s test resets.
It sounds to me like you are simply looking for a guaranteed length of time that a “true” from the condition or sensor is held: the sensor or condition goes true immediately when the test is met, but then during the “debounce” period that follows it remains true regardless of any changes in the test conditions. This is not a current feature of Reactor conditions, but has been emulated using other conditions and options. But given that you want it for the geofence condition, where “sustained for” is not currently an option and is required for this workaround, I won’t go into it here, and rather commit to adding the “debounce period” (or some better name if we can come up with one–any ideas, or is that OK?). If you want to know the details anyway, it’s described in this thread (the problem description is a bit different, but the solution/approach is the same).
[quote=“rigpapa, post:7, topic:200373”].
“Sustained for” operates a little differently from what you’re describing. With the current “sustained for” (which does not work for geofence conditions yet, but can be added), the condition would not go true at all until the condition has been met for the prescribed period[/quote]
You are right, I didn’t read carefully 
Yes, exactly that’s the idea
I’ve read the other thread and maybe I can adopt this logic. But the “debounce” (hold or triggered?) period would be nice to have, as you don’t need two sensors to make the rule.
The newer 3.0 version of Reactor upcoming will let you do it in one ReactorSensor, but either way, it’s a long way going about a simple task, so a direct approach would be better, I agree. That’s issue #6 now in the Github repository. I’m not sure if it will make the 3.0 release, which just went to beta yesterday, but if not, certainly not long after.
Good to hear, I tried your plugin very recently and I really enjoy it 