Comments (8)
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.
from reactor.
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.
from reactor.
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.
from reactor.
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.
from reactor.
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).
from reactor.
This is in 3.0beta-19090
from reactor.
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.
from reactor.
Delay reset does not affect the false->true ("leading") edge of the condition (the "sustained for" and "repeats" options do, however).
from reactor.
Related Issues (20)
- RS with Interval condition loses sanity on date/time conditions HOT 2
- delay timer HOT 2
- Add Stop Activity action HOT 2
- Backup/Restore should handle Reactor state/configuration
- Allow variable references in all condition options HOT 1
- Quickly find all devices used and where HOT 1
- Implement CallMeBot notification type HOT 3
- Allow variable pick in House Mode action
- Expose notification actions for external use HOT 2
- Warn when deleting condition group mentioned in Group State
- Store evaluation error messsage with result value
- Import conditions (could serve as clone) HOT 1
- values change in activity HOT 2
- v3.6 Variable values not printing in Syslog message HOT 1
- Reactor is creating fake devices
- Conditional Scenes with Reactor on Vera
- Comparing two curly-braced Expression values inside a Condition looking for change generates an error HOT 1
- RampUp command doesn't work
- SUGGESTION: Expression in conditions's restrictions
- Oddity in Vera log: luup_require can't find L_Reactor_LuaXP_ExtFunc
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reactor.