Securifi Community Forum

General Category => Ideas/Feature requests => Topic started by: btosch on January 16, 2015, 01:10:40 pm

Title: Rules Improvements
Post by: btosch on January 16, 2015, 01:10:40 pm
Its nice to see the rules working in the beta.  But the basic IF/WAIT/THEN structure is not enough to do much meaningful.  Here are some things that would allow me to do more than just demo rules.  These aren't really novel so hopefully they are on the roadmap already.

- Sunrise/Sunset.  When you are as far from the equator as I am (Seattle) time based rules pretty much have to be indexed to sunrise/sunset to be of any use.

- Get/Set Variables.  For example, I would like to be able to "arm" the house with the keyfob.  The rules need to check if the house is "armed"

- Check status of sensors in rules.  For example, I want to turn a light off when the door is closed, but only if another door is also closed.
Title: Re: Rules Improvements
Post by: LGNilsson on January 17, 2015, 01:08:35 am
The first two are planned, not sure how we'd do the third one, but I'll pass on your feedback to the software team.
Title: Re: Rules Improvements
Post by: Automate on January 17, 2015, 07:07:07 am
Seems like for #3 you could add the ability to have AND  and also OR statements in the conditions of the IF.
Title: Re: Rules Improvements
Post by: LGNilsson on January 17, 2015, 07:23:53 am
Well, AND is there already to a degree as you can have multiple IF and multiple THEN. So if you have two IF's, then both have to be true before the THEN is done.
Title: Re: Rules Improvements
Post by: btosch on January 18, 2015, 01:35:28 pm
The problem, at least for me, is that I need to evaluate the state after the wait/timeout.  For example, if I close a door, I want to wait 1 minute and then turn a light off, but only if the door is still closed.

I don't know if its best to start a new thread, but here are some more rules features that I would put to immediate use.  In the end this is really why we need a scripting interface because you'll just be trying to emulate as much in the GUI.

- Ability to repeat/loop the THEN clause.  Repeat X times.  Repeat until Y sensor state. Repeat until Z time.
- Ability to call a rule from another rule
- Ability to have rules with no trigger.  Effectively sub-procedures to be called by other rules
- An alternate implementation of the above 2 would be the ability to define and send virtual events and then build rules that triggered on the virtual events.
- Ability to cancel a rule in progress.  Otherwise rules rapidly descend into overlapping chaos especially if you use wait clauses.
- A log of all sensor events, rule executions, and command sent as a result.  Maybe I am missing this?  I had a rule that was working, but is not now, and I don't know why.
Title: Re: Rules Improvements
Post by: bwainscott on January 18, 2015, 06:16:17 pm
I have similar interests to those expressed by btosch.

I've suggested the ability to have an external script as an event, along with a rules API, which amounts to much the same thing.  The two rules I'd implement right now:

- if the front door is closed, call a script that will wait 5 minutes then lock the door
- if the front door is opened, call a script that will cancel any running wait script that is about to lock the door
The end result is that the door will lock itself if it has been closed for 5 minutes.


- if I open the outer garage door (eg just coming home) then activate the following rule for the next 3 minutes:
  - if the door between the garage and house is opened AND my kitchen and family room lights are both off,
   and it is (after 5pm, after dusk, a light sensor reports dark, whatever) then turn on the kitchen light

Anything less complex is just not going to be smart enough.  Making the GUI complex enough to handle all foreseeable combinations is going to be unusable (if it is even possible).  But a scripting language, or the ability to interface to external scripts, would be extremely powerful.

External scripts could be supported by having some fixed directory on the A+ exported via samba, so scripts are managed via the user's normal file manager interface.  Well, for security maybe they should be uploaded via the web UI.  Anyway,  I would suggest python for the language (I'm quite partial to it myself), which could be supplied via an external python implementation (which I know is available on OpenWrt)  or perhaps be embedded in the Rules driver.  Python would be a lot simpler for end users than requiring them to use the full C++ based SDK.  Sensors could be class level objects that can be queried, activated, etc -- it would be very nice to use.

I'm sure there are a lot of different opinions on exactly how to do this, which language to use, etc, but I think a high level scripting language of some sort would REALLY make the A+ a powerful home automation controller.