Condition Hold Times (feature request)

[toggledbits]

Not just for service conditions, but geofence and others where it makes sense:

• The option to delay transitions (false->true and true->false), separate timing for each; the default would be immediate (current behavior/of course).
• The option to hold a state for a minimum period of time. This is basically the extension of a pulse from the condition: a short true of the condition test turns into a longer true output state of the condition itself. And maybe shorter? e.g. reset the condition state even though the underlying test is still true (no further true until it resets through false---how does this relate to current latching feature?) This timing would apply equally to true and false states (with possible different timing values for each).

Question/thought: how does the above effect how we implement time-triggered resets for service "changes" operator, intervals, and reload conditions? All have pulse periods.

Question: is "delay on" different from "sustained for"?

[BuxtonCalvin]

Hey, I'm struggling with some dog door logic that pertains to this post. Like most dogs, mine will often go in and out of his door multiple times within a minute or two. I'm trying to write a sensor where I will be notified when the door is tripped (and I'm away) as there have been a couple of cases where the local rifraff has tried to gain entry to my home via the door. The door is sensored to my alarm panel on a non-arming partition. My idea is to attach a camera snapshot to a message when the door trips, and if there's anything amiss, I can take action. That's very doable, but if the door is constantly being tripped in a brief interval, I only want one notice as getting spammed by messages weakens the purpose.

Do you have any ideas? I don't think I can do this in the current reactor beta.

As a further aside, I'd like to have a different activity fire depending on whether I'm at home or away, conditioned by whether it's sleeping hours or wake hours.

[toggledbits]

It takes two ReactorSensors to do it in 2.x currently (at least, I haven't put in the mental energy to figure out how to do it in one, but I've pointed several people to the two RS solution). Here's the Reactor 3.0 solution (without the Hold Time option being discussed here). For 2.x, it's the same, just put the groups in separate RS's,...

Group 1: Test that the door is CLOSED for the debounce period

• Service condition, door sensor tripped is FALSE; + option: sustained for: period seconds

Group 2: Signal door open

• Service condition, door sensor tripped is TRUE; + option: LATCHED
• Group state condition, group 1 is FALSE; no options

Group 2 will go "true" when the door opens. If the door "swings" during the debounce period, there will not be additional signals. If the door remains closed for the debounce period, group 2 will go false and group 1 will go true.

This has actually become one of my automated test cases. Even if (when) I implement Hold Times, I will continue to test against this case--no reason it should ever not work as described, and it's a good demonstration of latching.

[BuxtonCalvin]

OK I think I have this right, but not really sure to be honest. There is something with the way the nesting is portrayed that doesn't seem right.
My sense is that what I'm trying to do should be split up between the underlying trigger condition (dog door moves--with bounce traps) and the activities that follow depending on environment conditions (Home, Away etc.)
So I could imagine a sensor that follows the dog door movement as a condition, and then a similar--condition style UI in the activities pane where one could use some if/then logic to choose from a limited set of conditions, If home, blink the lights in room x, elseif away, send a snapshot, else if on vacation send an mp4 of the area from the local camera. Anyway, just my two cents. Attached is what I have so far. My topmost groups are probably off as I'm not able to create separate activities for home and away.

[toggledbits]

OK, structure-wise it looks like you've set up the debounce conditions correctly. What doesn't look right is that you can't "AND" test the two groups of the debounce to get a useful result. Only the second group (the one with two conditions) produces the logic output,

So, I would "unwrap" the Location Away group (for example)--make it its own group under root, with a single condition that just follows Door State Away (e.g. Group State Door State Away is TRUE). Do the same for Location Home.

Or, if all of the activities associated with these conditions is to be contained in the same ReactorSensor, it's fine just as it is, just put the actions in the "Door State Away is TRUE/FALSE" and "Door State Home is TRUE/FALSE" activities.

[toggledbits]

Implementation for "delay reset" option (hold time) is complete, and will be included in the 19090 beta release. This can be used to "debounce" a device state, as in the foregoing discussion, or to create an "off" delay on a motion sensor, etc. When specified, the "falling edge" (true->false transition) of the condition is delayed by the specified number of seconds. The delay is persistent and will survive Luup reloads (i.e. if the reload occurs during the delay period, the false transition occurs as close to the expected time as practicable).

[toggledbits]

This is in 3.0beta-19090

[BuxtonCalvin]

Will the sensor still trigger immediately upon a state change if the "delay reset" option is specified? I deleted the above sensor and am starting fresh here.

[toggledbits]

Delay reset does not affect the false->true ("leading") edge of the condition (the "sustained for" and "repeats" options do, however).