I know what I want to do, but then having Hubitat do it. That is the big question. It is not easy to find the correct syntax. But it's fun to learn, but frustrating
Somewhere deep in the archives is an old post describing "Ways to Find the Day of the Week" using Hubitat, all of them fairly obscure methods. Pretty soon thereafter, @jshimota wrote his Date Time Parser driver, sparing everyone the effort. 
Moral: There's always more than one way, some more fun, some more challenging, some vastly easier.
1 Like
The beauty of Hubitat. If there is something you want to do, there a WAYs to do it! and no one way is the right or best way.
I continue to be completely amazed with this product. Sometimes I wonder if it is amazement or an addiction 
I can spend several hours a day) adding new functionality and / or reading the community forum (also thanks to the great ideas of the community) and just when I think I may have everything I need or want I am off working on a new initiative.
- Don
2 Likes
Thanks for this. Quite helpful. I wasn't aware you could list multiple items in a single trigger. That said doesn't that contradict the no AND rationale for triggers??
Just trying to understand. Since my example below works I must assume the trigger is evaluated at each state change of the various trigger items but only goes true if both element meet the AND condition (all turn on).
2 Likes
Yes, sorta, but not really.
You can have, as youāve shown, have simultaneous state checking (AND) within a trigger, but it is still not possible between triggers as they are evaluated independently.
Similarly, a conditional trigger could also be considered a case of AND of state and event.
4 Likes
Some triggers allow for multiple selection (switches, dimmers, motion, illuminance, etc...) where you can select either "any of them" or "all of them" as the actual trigger. However, it's only using a conditional trigger that allows for an "and" across two different type of things.
It's the logs that show how this plays out:
Think of this trigger as looking for three separate events to occur in a specific order for the rule to run. So, in one view it is an "and"; however, it fits Hubitat in that it is defined by distinct event of all three switches being on.
1 Like
No specific order required, just that all the others are in the right state when the ālastā of them fires.
Since at least one was in the āwrongā state when each of the first two turned on, the trigger WAS evaluated but did not fire then.
2 Likes
Good catch! That's poor wording on my part.
1 Like
I'm not sure this is true at least in the traditional sense. With conditional triggers, the logs will show the trigger being skipped due to the conditional being false. In this scenario, it's the third event that leads to the trigger. There is no "skipping" of the trigger based on the first two events.
The trigger had to be evaluated just to be sure that the other two were not in the correct state. I agree the log does not show the trigger skip, but think about how it has to work.
Except it's events that are evaluated to cause triggers. With logging of rules, it always goes events then triggers. In a scenario of all switches on, the rule is evaluating the events and looking for all necessary switches to register an "on" event before triggering the rule. That's why there is no trigger skip in the logs, which we would see in a conditional trigger with the conditional being false.
Maybe a case of semantics, but WHY is the event getting evaluated at all? Because the trigger attaches (subscribes) to it.
Thatās why they are called āTrigger Eventsā.
