Securifi Community Forum
Securifi Products => Almond+ => Topic started by: d.kiran on April 02, 2015, 10:04:08 pm
-
I have a simple rule that says, if my main door (Kwikset 910) is open beyond 9:30 PM, then automatically close the door after 2 minutes. Today I noticed that if the door has been left unlocked before the time specified, the rule does not run. However, a change in the state will make the rule run correctly.
Let me see if I can explain better. The rule should trigger at 9:30 PM. I unlock my door at 9:00 PM, I check the door again at 9:35 PM, still unlocked when it should have locked at 9:32 PM. I manually (on the lock, not using almond+) lock and unlock it again. Two minutes it locks itself as it is supposed to. It seems like after the rule time a state change in the z-wave device has to happen before it can trigger.
Is that your experience as well ?
-
I've found that when I do restarts that sometimes the time zone will be different.
It will say America/New York, but will be 4 hours ahead (Local time 5:00pm, Almond time 9:00pm). The workaround to this is to find the time zone labeled "US/(your time zone)" instead of "America/(Your time zone)." You may have to go into the OpenWRT UI under advanced to toggle this.
I'm not sure if this may have been your issue, but it's worth looking at.
-
I checked and my date in SSH matches both almond and openWRT. However, it was showing America/Chicago. I changed it to US/Central. I will check to see if that resolved the problem tomorrow.
-
I have a simple rule that says, if my main door (Kwikset 910) is open beyond 9:30 PM, then automatically close the door after 2 minutes. Today I noticed that if the door has been left unlocked before the time specified, the rule does not run. However, a change in the state will make the rule run correctly.
If I understand you correctly, then you have a rule that says:
If time between 9:30pm and midnight, if the door is unlocked, wait 2 minutes and lock the door.
Is that right? If so, then it is behaving the way I'd expect. The "between" time acts only as a filter, to disable the rule outside that time interval. The thing that triggers the rule is the door becoming unlocked. So when it unlocks (if between those times) then it locks in 2 minutes. I suggest you add another rule that says "AT 9:30, lock the door"
-
Hmm, I don't think it should work that way. I believe that when the rule starts, it should check the state of the device and then execute rules as needed. But maybe my understanding is wrong.
Let us say I have similar rule but with a motion sensor (between 9:30 PM and midnight, if a motion is detected then turn on my bedroom light) which does not get triggered at all before 9:30 PM. Should I intentionally trigger a motion so that the rules will work ?
If anyone else is reading this, please feel free to chime in on what your expected behavior of "between" rules should be.
-
Tested again and it looks like @bwainscott is correct. That's how the rules seem to work. Here's what my rules look like.
Intent: Lock My Main door between 9:30 PM and 06:00 AM automatically.
Rule 1: Lock My main door at 9:30 PM
Rule 2 : Between 9:30 PM and 11:59 PM, if Main door is unlocked, lock it after 120s.
Rule 3 : Lock my main door at 12:00 AM (for those cases where people might come in at 11:59 and leave the door unlocked)
Rule 4 : Between 12:00 AM and 06:00 AM, if Main door is unlocked, lock it after 120s.
That seems unnecessary and redundant doesn't it ?
-
Given the door locking case you describe, I agree that it looks redundant. The thing to keep in mind, however, is that the rules system must work for many different scenarios. What seems redundant here is, in actuality, the precision required to describe for the computerized rules engine exactly what you want. Let's consider another scenario that uses the "between" logic but with lights instead of doors. The goal of the automation is now energy savings more than security.
Between 4:00pm and 11:59pm if motion is detected, turn on my desk lamp 50%.
Between 12:00am and 7:00am if motion is detected, turn on my desk lamp 10%.
All I want is for the light to come on for me if it's late enough in the day and I'm at my desk. (If I'm working late, the light is a bit dimmer so I don't blind myself.) If the "between" logic automatically turned on my desk lamp at 4pm and 12am (even if I wasn't there) I would not be happy.
-
@fgtech. Thanks, but I am not sure I understand. Why would your desk lamp turn on when there is no motion detected ? The change of state should be the trigger. Here's the logic I expect (pardon my pseudocode).
Crontab starts fgtechRule1 at 4 PM
While CurrentTime Between 4:00 PM - 11:59 AM
If DeviceState=MotionDetected
Turn on Desk Lamp 50%
Else Do Nothing
End While
For me, it would be
Cron starts d.kiranRule1 at 9:30 PM
While CurrentTime between 9:30 PM - 12:00 AM
If DeviceState = Unlocked
Wait 120s
Lock Door
Else Do Nothing
End While
That would work for your case and mine. I am trying to see a case where this is not the expected behavior.
-
d.kiran,
I think the issue is that the rules can't reasonably be expected to run constantly, checking to see if your door is unlocked. I expect they only bother to check the rules whenever a sensor changes (or better still, just a sensor in the IF part of any rule). What you want is for them ALSO to test the rules at the start of any BETWEEN time interval. That seems to me to be a reasonable thing to do, but not something they are doing that I know of. So...
SECURIFI: would it be possible please to treat the beginning of any "between" time similar to an "at" time, in the sense that AT the start of the "between" time you check the IF of the rule and then do the actions as needed? Thanks.
-
@bwainscott. What you are saying is that the device is trigger and when the device status change, only then is the rule evaluated. That would definitely explain the behavior.
-
That is definitely more of the case. Especially with regards to battery powered sensors. Most of the sensors out there only send a status when they have a state change. The rest of the time Almond+ would have no idea what is happening with them or even if they are still in existence (maybe they broke, left the range of the router, ran out of power, etc...). If the sensor does not send something different the Almond+ continues to show the last status as the one that was there.
Some sensors are configurable. I have motion detectors that can be set. They default to 5min (they will send a motion detection, then check again in 5 min and change the status if needed). Other settings are 1min, 30min or pulse (which means when they detect motion they immediately check again and send the status again... and keeping doing it until the motion stops).
Some sensors do have regular readings. The new Aeotec MultiSensor 6 will send a few (temp, humidity, and light) readings in real time if it is on AC.
Almond+ cannot poll the sensors either. Not because it is incapable, but because most (I have not found any yet) sensors just aren't designed that way. I would love it if all the sensor designers out there went and added these 2 little features:
1) A regular, once a day (or better yet configurable) status, just to let the controller know it is still alive and kicking. That way you can make something in a controller that says if it does not get a status once a day you need to check the sensor.
2) When the sensor sends that regular status it asks the controller if it "has anything" for it. Firmware updates, status frequency changes, whatever. It is just an opportunity to have it check and be checked. Just to make sure everything is good.
-
@fillibar and @bwainscott : Thank you for that information. It makes a lot more sense now. While I think @bwainscott solution would be ideal, I have a better understanding of how the sensors work. You learn something new every day :-)
-
@bwainscott, I think you nailed the issue when you said "rules can't reasonably be expected to run constantly, checking to see if your door is unlocked." I think I was just assuming things would be driven in this event-triggered manner but I can see how @d.kiran (and other users) would get the impression there would be a time-based trigger from the way the rule is phrased: "between X and Y times if A then B."
However, for the reasons I explained in my example, I do not agree that Securifi should change the behavior of the rules. If anything, the rule creation screen should be updated to clarify that the system is event-based. Perhaps phrasing the rules as "If A then B between X and Y times" would do the trick.
@d.kiran, you are absolutely right that my light wouldn't get turned on in the case I contrived. My concern is more that we not muddy the waters between event-based and time-based rules as it could lead to all sorts of buggy and unexpected behavior. The best solution, IMHO, is to make the UI represent what the system will do as clearly as possible.
Of course we need time-based triggers as well. In an event-based model, these triggers can be thought of as "events" that are generated by the clock. Let's just be careful not to confuse the two things in the UI.
-
@bwainscott, I think you nailed the issue when you said "rules can't reasonably be expected to run constantly, checking to see if your door is unlocked." I think I was just assuming things would be driven in this event-triggered manner but I can see how @d.kiran (and other users) would get the impression there would be a time-based trigger from the way the rule is phrased: "between X and Y times if A then B."
However, for the reasons I explained in my example, I do not agree that Securifi should change the behavior of the rules. If anything, the rule creation screen should be updated to clarify that the system is event-based. Perhaps phrasing the rules as "If A then B between X and Y times" would do the trick.
@fgtech, yes the rules are clearly event based, which I think makes sense. I wasn't suggesting any significant change in that sense, just that perhaps the "begin" time of an interval ALSO act as an "at" time. In your case, I don't think that would change anything because the motion detection would also be required to turn on the light. In @d.kiran's case ("between 9:30 and midnight, if the door is unlocked then lock it in 2 minutes") then at 9:30 it would see the door unlocked and lock it at 9:32.
In any case, I'm sure we can all agree that the rules have some way to go. I still advocate for user defined scripts as actions, with an API so the scripts can query and activate sensors and devices, activate and deactivate rules, and even create rules on the fly (or delete them) -- basically the capability to take over and do it ourselves, for those advanced users that want to. Of course SECURIFI wants rules that are easy for the novice user. If they can do that and still give us the flexibility we want then great -- just so long as they don't cripple the device in the name of user simplicity.
-
I really hope someone from the Software development team is reading this.
Knowing this better now I agree that the rules need not be changed to be time based, however, I think there is a definitely value in evaluating the rule at the beginning of the interval, because I think that's what most users would expect. If not, then fgtech is right, the Device actions need to come first and then the time to reflect the current behavior.
Option 1:
Keep the UI as is and evaluate the rule when it first starts. Optionally have a checkmark/flag that enables or disables this in the case that is not what the customer expects.
Option 2:
If no change to the Rules evaluation can/will be made, then the UI needs to reflect the event based nature of the rules. It should have the device triggers first and then the Time.
I hope we can get someone from Almond to chime in on this.
-
Here are some screenshots from the Securifi website. It says you can use Time Based trigger or a Sensor based trigger. I think this is a wrong statement based on what we discussed here.
(http://i.imgur.com/z5z5AJV.png)
(http://i.imgur.com/Pj7BXIg.png)
-
Here are some screenshots from the Securifi website. It says you can use Time Based trigger or a Sensor based trigger. I think this is a wrong statement based on what we discussed here.
Not at all -- the AT time works great as a time based trigger. I have AT rules to lock my front door at 10pm, turn out all lights at 1am (the kids leave them on sometimes). The BETWEEN times on the other hand do NOT works as time based triggers, just "active time windows" for the rule -- sort of like "enable the rule at the start time and disable the rule at the end time"
-
I just put up a screencast on the blog yesterday explaining how to make time based rules - http://blog.securifi.com/how-to-create-a-rule-using-a-timer-and-delays-on-the-almond
-
I apologize in advance for being a pedantic bunny. But the rules are not clear in terms of Time. For example, the AT rule works like the following.
IF AT <time> AND <currentSensorStatus> THEN <delay>AND <sensorAction>
however, for BETWEEN, it works like
IF <sensorStatusChange> BETWEEN (<fromTime> AND <toTime> ) THEN <delay> AND <sensorAction>
The rules UI does not clearly explain this behavior. If you change the the Time section to below the device section then that would make perfect sense.
P.S. I understand that my nit-picking pedantry can be an irritating thing :-) (https://s3.amazonaws.com/lowres.cartoonstock.com/pubs-bars-pedantic-pedant-nit_picking-chats-conversations-kmhn57_low.jpg)
-
Actually, looking at your video, my suggestion doesn't make sense because it would have to be reworded as something other than IF and that would be complicated.
I think then @bwainscott's suggestion is the best. SECURIFI: would it be possible please to treat the beginning of any "between" time similar to an "at" time, in the sense that AT the start of the "between" time you check the IF of the rule and then do the actions as needed? Thanks.
-
I'm working on a screencast that shows how to use the between option as well, should be up in a day or two.
-
Waking this topic up.
I really hope someone from the Software development team is reading this.
Knowing this better now I agree that the rules need not be changed to be time based, however, I think there is a definitely value in evaluating the rule at the beginning of the interval, because I think that's what most users would expect. If not, then fgtech is right, the Device actions need to come first and then the time to reflect the current behavior.
Option 1:
Keep the UI as is and evaluate the rule when it first starts. Optionally have a checkmark/flag that enables or disables this in the case that is not what the customer expects.
Option 2:
If no change to the Rules evaluation can/will be made, then the UI needs to reflect the event based nature of the rules. It should have the device triggers first and then the Time.
I hope we can get someone from Almond to chime in on this.
@Ashok / Amritendu, Any of you guys willing to provide input on this. I find the between implementation to be incorrect. Can you take a feature request. Let me know if you need more details on the options above.
-
@ d.kiran,
It would be more helpful if you could get in touch with our support team at support@securifi.com to discuss more on this because here on this post we got few things discussed or send a PM to ashok.kumar@securifi.com.