This object is in archive!
Issue with Autolock Rule
Need Answer
I have Yale Z-wave doorlock and a zipato multisensor quad in the same door. My objective with the attached rule is to automatically lock my door under two circumstances;
1. It is 10:00 pm AND the door is already closed AND my lock is currently unlocked.
2. If it's between 10:00 pm and 8:00 am, and I open the door and remains locked for 30 seconds and my lock is currently unlocked.
The rule works but it locks the doorlock every time I open/close the door. It is not following the TIME BETWEEN puzzle. If I remove the scheduler from the OR condition, the TIME BETWEEN puzzle works.
The same question 
No connection
Real-time notifications may not work
Just one idé but try to put the schedule and time constrains in the if block?
Then the rule runs every time ther is a change in the dorlock status or try to use other triggers.
The schedule I think is only trigger 20:00 and then it does not trigger.
I also think the time constraint should be in the if block. Not useful in the when block. But I am really not sure.
Worth a try!
Best regards Jacob
Just one idé but try to put the schedule and time constrains in the if block?
Then the rule runs every time ther is a change in the dorlock status or try to use other triggers.
The schedule I think is only trigger 20:00 and then it does not trigger.
I also think the time constraint should be in the if block. Not useful in the when block. But I am really not sure.
Worth a try!
Best regards Jacob
Alberto,
I too am experiencing issues with schedulers.
My suggestion is that you remove the scheduler from the OR condition and instead have the schedulers in separate, stand alone WHENs, where they activate a virtual switch, and that you use this virtual switch instead in your OR clause.
Best regards,
Robert
Alberto,
I too am experiencing issues with schedulers.
My suggestion is that you remove the scheduler from the OR condition and instead have the schedulers in separate, stand alone WHENs, where they activate a virtual switch, and that you use this virtual switch instead in your OR clause.
Best regards,
Robert
But the schedule is on ly triggering things one time at a certain time right?
But the schedule is on ly triggering things one time at a certain time right?
Hey guys,
Thanks for your answers. Indeed I thought about both solutions you're proposing, I tried Jacobs and it works in one rule, see attached. Also I use Robert's for more "generic" schedulers like Sunset/Sunrise, Reboot Check, Hourly Check. But honestly I just couldn't understand the issue on my first rule, looks like the schedulers used on AND or OR puzzles always are true, if you remove the OR and the scheduler or the time constrain it works with either/or functionality correctly from the first rule.
Hey guys,
Thanks for your answers. Indeed I thought about both solutions you're proposing, I tried Jacobs and it works in one rule, see attached. Also I use Robert's for more "generic" schedulers like Sunset/Sunrise, Reboot Check, Hourly Check. But honestly I just couldn't understand the issue on my first rule, looks like the schedulers used on AND or OR puzzles always are true, if you remove the OR and the scheduler or the time constrain it works with either/or functionality correctly from the first rule.
Alberto,
As a long time software and systems developer, I am trying to understand the inner workings of the Zipato system, in order to find ways to utilize the devices and hopefully develop some clever business around them.
(Disclaimer: The following thoughts and comments are speculations and guesswork)
A scheduler is NOT to be confused or mixed with a sensor or device: It is to be used as the initial part of a WHEN. When the rule set are saved or being synced to the box, a trigger is created based on the schedule. This is what causes the WHEN rule to be run.
Rules testing for changes in sensors or whatever, get their entry points in an event queue, and are triggered accordingly.
My gut feeling is that the pieces of Java code which the rules are compiled in to, are put in one of two places in the system: either it is hooked to the event queue, or it is in the scheduler system. It cannot be both places.
The way this fits together means that you simply cannot have an OR with a schedule the way you have used it; it won't ever get run.
Disclaimer 2:
The above mentioned thoughts may be just "hogwash" with no merit whatsoever :-)
Nevertheless: no WHEN which combine a scheduler with an action event will ever be triggered by the scheduler...
Alberto,
As a long time software and systems developer, I am trying to understand the inner workings of the Zipato system, in order to find ways to utilize the devices and hopefully develop some clever business around them.
(Disclaimer: The following thoughts and comments are speculations and guesswork)
A scheduler is NOT to be confused or mixed with a sensor or device: It is to be used as the initial part of a WHEN. When the rule set are saved or being synced to the box, a trigger is created based on the schedule. This is what causes the WHEN rule to be run.
Rules testing for changes in sensors or whatever, get their entry points in an event queue, and are triggered accordingly.
My gut feeling is that the pieces of Java code which the rules are compiled in to, are put in one of two places in the system: either it is hooked to the event queue, or it is in the scheduler system. It cannot be both places.
The way this fits together means that you simply cannot have an OR with a schedule the way you have used it; it won't ever get run.
Disclaimer 2:
The above mentioned thoughts may be just "hogwash" with no merit whatsoever :-)
Nevertheless: no WHEN which combine a scheduler with an action event will ever be triggered by the scheduler...
Robert,
Thanks for sharing your thoughts. I'm also a software developer, but for industrial automation, so I'm also trying to figure out how the processor works so this information is appreciated since I'm not familiar with web based programming languages.
This is funny, the first rule works all the time without considering the time restrain. Scheduler works (rule is triggered at 10:00 pm) and also everytime I close the door regardless of the hour. It's like the time restrain RLO (Result of Logic Operation) is always TRUE.
Seems like the scheduler is not the problem, I got it working moving the time restrain inside the WHEN, and only left the Door Sensor OR Scheduler to trigger the rule. See my previous comment for snapshot of the rule.
Robert,
Thanks for sharing your thoughts. I'm also a software developer, but for industrial automation, so I'm also trying to figure out how the processor works so this information is appreciated since I'm not familiar with web based programming languages.
This is funny, the first rule works all the time without considering the time restrain. Scheduler works (rule is triggered at 10:00 pm) and also everytime I close the door regardless of the hour. It's like the time restrain RLO (Result of Logic Operation) is always TRUE.
Seems like the scheduler is not the problem, I got it working moving the time restrain inside the WHEN, and only left the Door Sensor OR Scheduler to trigger the rule. See my previous comment for snapshot of the rule.
Alberto,
I'd wish Zipato had a white paper of some sort, outlining the internal working principes, or that they could comment on our guesswork, steering us in the correct direction :-)
IMO, what we deal with is not in any way a web based programming language: The rules we create are mere real clever visual representations of something which is the basis of real java code, which then is compiled and sent to the controller ("syncronized") and loaded as executable code there.
It would seem logic that a <scheduler> should very well function as a "trigger point" in a rule *together* with events from devices or whatever. What I don't know, is if the fact that they currently don't, is a bug or an architectural limitation.
Alberto,
I'd wish Zipato had a white paper of some sort, outlining the internal working principes, or that they could comment on our guesswork, steering us in the correct direction :-)
IMO, what we deal with is not in any way a web based programming language: The rules we create are mere real clever visual representations of something which is the basis of real java code, which then is compiled and sent to the controller ("syncronized") and loaded as executable code there.
It would seem logic that a <scheduler> should very well function as a "trigger point" in a rule *together* with events from devices or whatever. What I don't know, is if the fact that they currently don't, is a bug or an architectural limitation.
Replies have been locked on this page!