I'd like a light to turn on for an hour in the morning. How should I do that so that it works with other rules as well?
I could make a rule that evaluates to true between two times and turns the light on when true. What about turning it off? I guess I should add an action to turn it off when false.
But what if I have another rule to turn on the light for an hour in the evening using similar logic? That would presumably create a contradiction: During the evening, the rule would be true and turn on the light, but the morning rule would be false and turn off the light.
What's the right way to do this? Triggers based on time? (And the general question: when rules contradict, what's the behavior?)
BTW, a related scenario: What if I manually turn on the light in the afternoon? Won't the morning rule, which is evaluating to false, immediately turn it off?
As an action, you can run actions of another rule or you can also cause another rule to evaluate its conditions. Should be fine if you handle it that way. If the light's already on and another rule tries to also turn it on, it's not going to hurt anything. Where you can run into issue, is when you forget that you had a rule doing something to a device and you can't figure out why your new rule isn't working like you thought it should
You can also use private boolean as a condition and the put in the OR operator. So if that condition is met, that rule will be evaluated.
I avoid using times in rules (unless they are specific like something HAS to be on between 9AM -5PM) and use modes instead. I have modes for various times of day (including versions for home and away) and use Mode Manager to change based upon time and presence. In doing this, I can specify light levels and on/off states using mode rather than time and evaluating rules. Then, in my rules, I just specify what modes certain lights should run in (3rd screen cap).
Yep, that's a good suggestion. I don't use modes myself, and they seem to be the subject of issues quite often. Bill has a much more complicated setup than I do though, so Modes make a lot of sense.
Wait, don't modes have the same problem? If Early Morning = turn on light and Morning = turn off light, that should work so the light's only on in the early morning. But suppose we write another rule that turns on the light for some other reason, such as Bill's phone arriving, which could happen at any time of day. Now suppose that Bill arrives in the morning? The Morning rule says light off, but the phone arrival rule says light on!
Rules don't work on STATE. Mode being true is not at all the same as mode becoming true (or false).
Rules evaluate on EVENTS, not state. Door open = event; Door close = event; Sunrise = event, Something has to Change to be an event, then the rule gets evaluated for true or false.
Exactly right. There will be two events, one when the time BECOMES true, and once when it BECOMES false. Your light will follow. Anything you do between, physical on or off, Another Rule that is based on Lux, for example, and it will not be a conflict.
I think it's because I am "routine" bound kind of guy. So, modes made more sense to me along with adding simplicity to rules. If I don't have to sit there and think "Ok, this light should be on between 20:00 and off at 23:00" and can instead just say "If the house is in Home - Night mode", it just makes it easier on my thought processes.
Once I finish my aquarium network, I'm going to get a separate hub for them with their own modes.
Hmmm, checking my understanding... When a rule is evaluated based on an event, it may need to check on other conditions that the rule uses. But presumably those conditions are stored state, right? It doesn't actually interrogate a sensor with a new network request, but just checks the stored value for its last update event.
If that's right, maybe it's better for my understanding to avoid the notion of 'state' and just use 'event' and 'last event value.'
No, that is incorrect. Rules have "truth". Whether the conditions of the rule are true or false. When the truth changes from True to False you get the False actions and when it changes from False to True you get the True actions. When a rule is false and another condition changes which does not change the overall truth of the rule....nothing happens.
So, when a device attribute change's it's state (like a contact sensor opening), all the rules that subscribe to that state are re-evaluated to see if their truth changes. You are imagining it's the rule initiating the sequence but it's actually the device changing that kicks things into action. The rule just subscribes to those changes.
Thanks for that. The right mental model will go a long way.
