Automation trigger: local device control vs triggered by automation

Hello friends,
I have a GE/Jasco 14287 fan controller. I have an “fan speed control automation” that controls the fan speed based on room temperature. This automation has a blocking condition which relies on an input_boolean to be true. I’d like to have a second automation that sets the input_boolean false if the 14287 is manually set at the device itself.

I’ve tried using the solution that @freshcoast posted here, however this doesn’t differentiate between the device being controlled locally vs when the device is triggered by the “fan speed control automation”.

I have noticed in Developer Tools, when listening for state_changed that root context.user_id == “null” when operating the device directly, rather than when it’s triggered by the automation, in which case != “null”… (see snippet below)

event_type: state_changed
data:
  entity_id: fan.living_room_ceiling_fan1
  old_state:
    entity_id: fan.living_room_ceiling_fan1
    .
    .
    context:
      .
      .
      user_id: 1234567890
  new_state:
    entity_id: fan.living_room_ceiling_fan1
    .
    .
    context:
      .
      .
      user_id: null
origin: LOCAL
time_fired: "2023-07-17T00:18:00.440875+00:00"
context:
  .
  .
  user_id: null

However, when I try to use this data as part of the Event Trigger for my second automation, the second automation picks up on the context.user_id of the child “old_state” or “new_state”, rather than the root context.user_id.

Here’s what I’ve tried to use as an Event Trigger, which is unreliable:

platform: event
event_type: state_changed
event_data:
  entity_id: fan.living_room_ceiling_fan1
context:
  user_id:
    - null

If anyone has thoughts between how I can trigger an automation based on the state change via local device control vs state change via triggered by automation, I would very much appreciate it.

Thanks

Try this for a null value:

context:
  user_id: []

However you need to check more than just one context and I think you may have it back to front, both physical device and automation return a null user_id context:

Screenshot 2022-06-21 081430

The other option is to create a sensor like this that stores the last context and use that in a state condition:

Thank you @tom_l, this works great, much appreciated!