Individual condition for each trigger

[123 (Taras)]

@Hellis81

there is definitely a difference

Yes, the first one doesn’t get its last_triggered updated, the second one does.

How significant this is depends on the user. I doubt it’s especially meaningful to the author’s intended audience of the technically-challenged.

If anyone is curious as to why the automation triggered, the automation’s trace tells the story.

[MiguelAngelLV (Miguel Ángel)]

@Didgeridrew

But you are trying to support that claim using an example that ignores existing methods that make things less verbose and “cleaner”.

For me, it is cleaner put the condition together the trigger. Looking the trigger I would know when is triggered. I don’t even need the tigger ID, in my example, only “Apagar” for the choose.

If I put the condition in another place, I need search the trigger ID in choose or in conditions.

[bdshields (Brandon Shields)]

I’d like to see something equivalent an AND operator when choosing a trigger. I feel this is slightly different to a condition per trigger, but not that different. something similar to the template trigger transitioning to TRUE.

TV == ON AND Time > 17:00

This would trigger at 17:00 if you were watching TV OR you started watching TV after 17:00.

This is a simple example, but the main reason behind this request is so that the trace history for an automation isn’t flushed out with false hits.

[Hellis81]

@bdshields

I’d like to see something equivalent an AND operator when choosing a trigger. I feel this is slightly different to a condition per trigger, but not that different.

Triggers can’t have and since they are events or (possibly) very short states.
That is why you have the conditions.

In your example you have a state trigger on the TV == on , and a time trigger at 17:00.
Then in conditions you have condition TV == on and time after 17:00.

[bdshields (Brandon Shields)]

Yeah, I understand that ANDing two events together is essentially building a trigger for when 2 events happens simultaneously, which is somewhat insane.

I’m only after something that equates to a simple ANDed template trigger, and the main reason is to reduce the traffic of false events that flush out the TRACE buffer for an automation. Perhaps there’s a way to dig further back into the TRACE history.

I’ve re-read this thread and have a much greater appreciation for the reluctance for this type of request and will just continue to utilise the template trigger. I’ve also learnt that I can utilise Trigger IDs within the condition section to help filter out unwanted triggers.