Thanks Bruce. 
1 Like
I'm interested in feedback on this point. There is no reason that it couldn't work the way you thought it should, other than that is not the way it started out working. ??
If these are "restrictions", then it probably should work the way you thought.
1 Like
I suppose it depends on what the user is trying to do.
In my 'repeat loop' above I would want my delayed actions to mature and not be stopped if the predicate condition becomes false mid execution of the repeat actions. I would however want the repeat to be stopped.
This is a tricky one as other use cases may want me to stop everything straight away. 
The only way around that I suppose would be able to define in the predicate area whether the user wants delayed actions to mature or not and whether repeats need to be stopped or not.
Not easy I suppose. 
I think it has to mean one thing or another. Restrictions, when in effect, stop everything in their tracks. There are other ways to stop repeat actions.
I will leave it as is for now.
3 Likes
2 Likes
My preference would be to leave it the way it is. Stopping delays and repeats can be done in other ways. The way predicate actions are currently defined is useful. It has a simple, well-defined single function. KISS.
3 Likes
That is where I see the value of them too. Not sure if I am missing the point of them though.
I haven't messed around with this new feature too much yet, but I am going to rethink a few older rules that will probably be much more efficient (or easy to write) with predicates.
4 Likes
If you are saying "don't fire the rule again, but do not affect the rules operation" I agree with you. It can run again when PC is true.
1 Like
I find myself struggling with the new hub variables.
I have a rule which has a predicate condition...Run if variable in kitchen = true
Then a motion sensor on the livingroom will trigger and turn off the kitchen light and then set the in kitchen variable to false.
This ends the rule.
There is a second rule when the kitchen sensor detects motion to reverse the process and reset the variable.
Now I've found that the variable does change as it's supposed to and when it's supposed to. However the predicate condition status does not. Its status remains false, and the only way to update it is to edit the rule and press update rule.
My workaround was to create a presence connector to the variable, and use that connector in the predicate condition instead. This now works and is updating as expected. But then the hub variable is obsolete. I can just use a simulated presence device not attached to anything and it would do the same. My whole reasoning for using variables is to eliminate so many placeholder devices.
Using variables worked great with the legacy rule machine, except the rule would fire every time there was motion, and then the actions would be conditional. (I usually added an end rule routine at the beginning of the rule so if in kitchen variable was false when motion is detected it would end right there and prevent processing more than was needed) I rather prefer the predicate condition approach if I can get it to update it's status based on a hub variable.
How are you using "variable" in Predicate Conditions. That isn't a choice. Do you mean a Connector?
Please show the rule.
This may worth looking at. There could be a toggle offered, where when off Predicates work as they do now, namely, having to be true for a rule to be triggered. If the toggle were turned on, call it something like "Hard Restriction", delays, waits, and repeats would not run if the Predicates are false when their time to run comes up.
4 Likes
Here is the rule.
As you can see the variable is shown as true, and it shows the condition as true, but the predicate remains false (shown on the top), and therefore will not allow the rule to execute. The only way to change this is to actually hit the update rule button.
Workaround is to use a connector instead, but then like I had said previously, that's not ideal.
Variable conditions are not allowed in Predicate Conditions. Evidently more must be done to enforce that. There are no corresponding events, so the Predicate Conditions will not change from true to false ever.
Not allowed? Well it lists all conditions created within the rule as options for a predicated condition. I had already created the one with the variable and so it shows up as an option in the list.
May I ask the reasoning behind not allowing variables here?
There are no variable events. Yes, you grabbed it from the Conditions, but you could not have created it in the Predicate Conditions section itself. They aren't allowed for the simple reason that they won't work. To work properly, Predicate Conditions must have subscriptions to events -- otherwise they won't be set correctly before the rule is triggered.
The next release will fix that, not allowing the selection of conditions already created. In the meantime, your Predicate Conditions based on a variable comparison won't work, so you might as well get rid of it.
If you want to use a variable value in a Predicate Condition, you would have to use a variable Connector. Since that's a device, it does generate events. It's value is set whenever the variable's value is set, so it's a stand-in for the variable.
2 Likes
I can not seem to get this RM5 rule to install. I just downloaded 2.2.8.138 on my C7.
Am i doing something wrong with the time connectors as triggers?
Open Logs in another tab. Hit Done, and see if there is anything in the Logs. What happens when you hit Done?
Crap. when I had the error I thought of the logs but then got distracted before coming back to post.
single log entry when i hit DONE
OK, my bad. That's a bug, found and fixed. Will be fixed in next hotfix release.
4 Likes
Thank you Bruce
