Identify switch events that aren't triggered by an automation or direct interaction

My hot tub uses a third party controller that will randomly turn off its Economy Mode during expensive power times of the day. I have an automation that notifies me when this happens based on the time of day (ie Off Peak and Peak times should have Economy Mode On).

I don’t automatically turn it off because there can be times when we do want the heater to turn on in peak times.

What I’ve noticed is that when this turns off on its own, the logbook shows an event that has no “triggered by”, and whenever an automation or a direct interaction makes a change to this state, it has “triggered by” extra data

In this case, I want to only trigger an automation when the switch “turned off”. Happened twice today.

This integration isn’t turning off at known times like when HA reboots, or when the communication module loses connection. At least I haven’t found other ways to tie ths to a fluke/unwanted event vs a wanted event.

Add a condition to check that there is no context:

condition:
  - condition: template
    value_template: '{{ trigger.to_state.context.id == none }}'
  - condition: template
    value_template: '{{ trigger.to_state.context.parent_id == none }}'
  - condition: template
    value_template: '{{ trigger.to_state.context.user_id == none }}'

06283b2a5eaebf0b308f62c6b2b764cbb14fb723

The 4th option that the table does not show is no context for any of the context ids. That means it was changed outside HA.

Oh thank you. I’ll give this a shot.
Are you saying that if something outside of HA changes it, these conditions won’t catch it?

No. That is not what I am saying.

If context.id, context.parent_id and context.user_id are all none than that means the change was not by switching the physical device, the HA user interface or an automation. i.e. the device itself changed.

Actually scrap that. context.id might contain a value. You’ll have to test it.

Thank you! I’ll do some testing, this is very helpful.

Hi @tom_l

Thanks for your explanation! I want to use this throughout my house to identify changes outside automations (So interface and physical)

I have an automation that runs on a time and sets one light to 100%, that gives me the following event:

But after that, the event of the light is this:

It does not seem to match your scheme and there seems no difference between physical and automation now. What am I missing / doing wrong?

Kind regards,
Patrick

How did you trigger the automation?

Just a time trigger
image

Can you try with an entity?

e.g.

trigger:
  - platform: state
    entity_id: input_boolean.test
    to: 'on'

Yeah, in that case there is a Parent-id! So it seems that the kind of trigger defines if there is a parent or not. Would there be more exceptions like this that could behave like the time trigger?

I think most of my triggers will be boolean or binary sensors so it seems pretty reliable then!

Thanks for your replies!

It seems context.parent_id is related to an entity that caused the trigger.

So my guesses (untested):

Feel like testing them all? :slight_smile:

It is actually quite interesting how this works, because it means that the trigger is the parent of the event, and not the automation itself!

I don’t think I use them all, of know how to use as a trigger well enough to test correctly.

I will test the following today / this week: