FR: Tracking the origin of Device Actions

Feature Requests
1

Hi,

I’m not really sure how to explain this request properly, but here we go…

Many devices that are set up in HA have local controls: i.e. buttons that you can push to turn the device on\off. As that device is also in HA, it is then also possible for HA to control that device, either using an automation or by Dashboard (or an API call, etc. etc.).

Currently when you control the device using one of these methods, the device logging just displays that the device was turned on\off at time xyz with a HA Action. It would however be great to see what the origin of that action was.

So instead of just displaying that the device was turned on\off at a specific time and an Action was performed, it would display also if this was caused by an automation (and if so, which one), a Dashboard control (with page URL), a NodeRED flow, or by the device itself (i.e. a local button), or anything else that could cause the Action.

This would obviously help tremendously when figuring out the cause of a device doing something it’s not supposed to be doing at one point in time (otherwise know as debugging).
However, if this control origin information is sent as part of HA’s internal control message, it would also enable automation override by a local control. Or even have different automations based on if the user controlled the device using Dashboard, a local button or even another automation. Or even have different automations based on which Dashboard page the device was turned on from.

Let me give a simple example (i.e. a use case):
In my office, the main lights are controlled by a Shelly Plus 1PM connected to a switch to directly control the lights. I also have a control for the 1PM on my Dashboard.
If I manually operate the switch (which means I’m physically in the office) I would like to power up my PC and turn on the monitors. However when I control the office lights using the Dashboard control for whatever reason, powering up the PC would not be necessary: i.e. the automation that does all the extra stuff should not run.

I know there are better use cases, but I hope this simple one makes clear what this Feature Request entails.
The improved device logging alone would imho be very beneficial for HA as a product. But for me the additional possibilities for automations would be the real Golden Egg in this basket.

Thanks!

2

This is entirely possible using the existing tools.

This is a template sensor I use to know what turned on the kitchen light.

- trigger:
    - platform: state
      entity_id: light.lichtkeuken
      to: "on"
  sensor:
    - name: "Keuken Licht On Context"
      unique_id: '018e8402-759b-761b-bf24-272b807826e6'
      state: >
          {% set c_id = trigger.to_state.context.id %}
          {% set c_parent = trigger.to_state.context.parent_id %}
          {% set c_user = trigger.to_state.context.user_id %}
          {% if c_id != none and c_parent == none and c_user == none %}
            physical
          {% elif c_id != none and c_parent == none and c_user != none %}
            dashboard_ui
          {% elif c_id != none and c_parent != none and c_user == none %}
            automation
          {% else %}
            unknown
          {% endif %}

The template creates a sensor with 4 states : physical, dashboard_ui, automation, unknown

Physical : someone turned the light on manually
dashboard_ui : someone turned the light on from the dashboard
automation : the light was turned on by an automation (motion sensor)
unknown : should not happen, but you need to have a final if :slight_smile:

In psuedo-code

  trigger
    state : light turned on
  condition: 
  - condition: state
    entity_id: sensor.keuken_licht_on_context
    state: 'physical'
  action
    turn pc + monitors on
3

Yes, I’m sure it’s possible to do it with this workaround. Also, it appears you’re using some “trickery” to see where an action originates from (using a bunch of other variables to create a pseudo origin), whereas this imho should be a native trigger variable.
I think this should be core functionality instead of me having to create a template for every device.