Just reviewing Hubitat Rule Machine, prior to purchase. Coming from Vera and using PLEG.
The Rule Machine is not making sense to me. You create a "Trigger" which is a conditional event. Then you create an "Action" which in every example, also contains conditional events, followed by an action.
Why are so many of the conditional events contained within the "Action" rather than within the "Trigger"? Can the "Trigger" be made more complex so that it contains all of the conditional events? Or, can you just forego the Trigger completely and put all of your conditional events and actions (IF THEN) within the "Actions"?
What purpose does the "Trigger" serve if you put most of your conditional events within the "Action"? Is the "Trigger" just a high level filter to reduce processing of rules?
Therefore a Door Contact Sensor sends an Event. That is the trigger, the State of the Door is then the condition of the Action.
Without going into all the "Twilight, gloaming, dusk, dawn" semantics I'll say that "sunset" is an instantaneous thing. It doesn't persist. After sunset comes Night.. and you can test for night, having set "Night" as a result of sunset.
If you want to use Rule Machine you need to understand the difference between an Event and a State. A switch turning on is an Event, a switch that is on is a State. An automation system is "event driven". Code that makes an automation take place are based on an Event taking place, not a State existing (if you think about it for awhile it is obvious why this needs to be).
Some interfaces that are used to create automations do not make this explicitly clear, and they try to decipher when it should execute based on the varied parameters entered. In Rule Machine this is explicit, a better word for Rule Machine's "Trigger" would be: "When this/these event(s) takes place, the rule machine app will load and execute code this is created based on the parameters entered below"
Understand that apps loading and running on any home automation hub is always based on events taking place and not states existing. Since Rule Machine makes this explicit you always know when your rule will load up and execute. Knowing this has immense benefit in helping to write efficient automations and trouble shooting problems.
Since this is the fundamental underlying architecture of home automation hubs, multiple triggers are always joined with "Or"
For example, I made a rule that turns on and off a variety of lights after I arm my alarm and leave my house. The rule is below, you will notice that the triggers are all events, whenever any one of them happens the rule is loaded up and executed. The conditions that are shown in the actions are all states.
Good explanation. However I also notice the original poster hasnt liked or replied yet. If it help, in plain english terms:
Something has to HAPPEN to be a trigger
But the conditional is an action can look at what currently IS
For for example:
"The light IS off" cannot trigger an event, cause the light is usually off. nothing has happened that Hubitat can see
"The light TURNED OFF " can trigger an event, because something changed that Hubitat sees happen
So then a rule is like this:
Trigger: WHEN the hallway light is TURNED OFF
Conditional Action: IF "it's after sunset" then "turn on the porch light"
Or if you want more flexibility:
Trigger: WHEN the hallway light CHANGES (meaning this rule will trigger when the light turns on OR off
Conditional Action: IF "the hallway light is now on" DO "some thing"
IF "the hallway light is now off" DO "some other thing"
Thank you for the replies, it helps and makes more sense, now.
Though, I am still unsure why evaluating an "event" needs to be any different than evaluating a "state". From a boolean logic point of view they can be evaluated in the same way...
IF (event) AND (state) THEN (action)
With the explanations provided, above, I think I will be fine. I do think the videos provided by Hubitat, at least the more advanced one, should provide some information on "events" and "states".
There's no and between the event and state. The event triggers the rule the action can have conditionals based on state but they are evaluated separately.
