Hello
I have a rule without trigger. Instead of if in action I set a predicate condition. I call this rule from another rule with "Run Rule Actions". And predicate are not taken in account.(which is expected). Is there a option to trigger a rule from other one instead of just running the actions?
I found also a bug in rule 5.0
I want a new condition to compare a local variable with a hub one
I choose local variable
I choose relative to a variable
I choose hub variable
and in this moment the local variable I choose at point one is automatically replaced with the hub variable from point 3
Another question: I have a boolean hub variable with a swicth connector. When I change variable value switch is not updated. Is this normal behaviour?
I've seen both of the issues you note in the last part of your post reported elsewhere. Presumably, they will be fixed in an upcoming hotfix (the second issue hadn't been acknowledged yet when I read that thead, but the first had).
Regarding predicate conditions and running rule actions, you should already be able to achieve the desired effect in one of two ways. The most similar to a predicate condition would be to put your "Run Rule Actions" actions inside an IF THEN/END-IF (conditional action) or a simple condition (if that works for your condition) in the rule that does so. You're simulating the behavior of a predicate condition by not running the rule actions if the condition is not true.
Alternatively, you can probably just use "regular" conditions in the actions of the rule that gets run (with the advantage here being that you only need to do this once--in this rule--rather than in every rule that runs this rule's actions, should you have more than one such rule). For a rule with no trigger, I can't see why this would be different: predicate conditions prevent the rule from triggering when the desired event happens, which is perhaps most useful when the actions check some event that would have been changed by the trigger (e.g., if you want to check for a specific state change). But with no trigger event, this should never matter. If you share a use case, someone can perhaps suggest something that would work if neither of these options sound right to you, but it sounds like one of these would work.
It should be noted that predicate conditions are not exactly the same as just putting a "regular" condition (IF THEN/END-IF) around your entire "Actions to run" section, although I suppose they could be used to achieve a similar result--but in many cases, it probably isn't the best way to do that. Predicate conditions, unlike regular conditions, create a subscription to the device in the predicate condition. This is because the rule has to know the "previous" value (before the rule triggered, since by the time the rule does trigger, it may be too late; one use for this, again, is to allow capturing specific state changes). If you just want to check whether something is true/false before running your actions, a "regular" conditional inside your actions is still probably the best option--no subscription (the rule app doesn't "wake" on corresponding device events), just an evaluation when the actions are run.
I suppose there is a flip side to this: trigger events are un-subscribed to while the predicate condition is false. Therefore, if you have a particularly "chatty" triggering device (or devices) and a relatively "stable" predicate condition (i.e., your predicate condition is likely to change less often than your triggering events fire), then if your concern is to reduce the number of time the rule wakes up as the result of a subscription, this is one way to achieve that.
But ... I suspect most people will want traditional conditions for most of their use cases. I also suspect many people will not see the difference and use predicate conditions as a "shortcut" even if they don't really need them (or because they think the resulting rule looks prettier), but I guess in most cases it's harmless enough either way.
Ok, now I got the difference. Some predicates which are based on my global variables which will change seldom are good but on a motion sensor or illuminance sensor if more chatty.
Thanks
Lol. Yeah. The unintended consequences of new features, right? Which is better, a Predicate or a IF-THEN in the actions?
Subscriptions are free, so that's not a reason NOT to use Predicate. But as you point out, the question may be which form causes the rule to actually instantiate more often. Evaluating Predicate Conditions has the same "expense" as evaluating an IF-THEN or a Wait for Conditions. Except for very chatty devices this probably doesn't matter.
Overall, I'd say that if it makes the rule easier to read, cleaner, that's a good thing. Less is more, usually.
You can't have a Predicate Condition based on a variable, as variables don't throw events. You can have a Predicate Condition that uses a Connector tied to a variable. Presumably that's what you meant. It should be noted that Predicate condition that is a comparison of a device relative to a variable will only be evaluated when the device throws an event, not when the variable value changes.
Yes you are right, I create connectors and they have the same name. My mind thought is variable but was a switch connected to a boolean variable
Btw why connector can be shared between hubs?
thanks
