use case 1:
A light-switch can be switched manually and via automation. In case of the manual switching I want the light to stay on until I manually switch it off. When the switch is switched on by an automation, a specific automation can switch it off.
In my case: I have a motion-sensor in the toilet that switches the ventilation system on and it is switched off after 5m. In the bathroom I have humidity-sensor which switches the ventilation on when humidity > 80% and an other automation that switches it of when humidity <= 80%. In order to get it to work correctly I had to store who triggered the ventilation in a separate variable.
use case 2:
For one switch there are multiple automations that can switch it on or off. If I want to debug why the light was switched, I have no way of knowing what triggered it.
Of course for every switch an alternative variable could be written from each automation that alters it state, but that becomes unmanageable quickly as your automation system grows.
This will make it possible in the future to introduce attribution.
Anyone knows if this was implemented?
https://data.home-assistant.io/docs/data_context shows that there is a context_id in the db.
âContext is not stored in their own table in the database. Instead, each row in each table maintains itâs own columns to store context.â
As I read it, I can get the context by querying the db, which sounds even more horrifying than writing a extra variable. (abusing a configfile to program in a template engine doesnât seem to be the best idea)
Speaking of attributions, I would appreciate if you fix the quote in your post. You have attributed it to me but I never wrote those words; they come directly from the linked blog. Please remove my moniker as the quotationâs source. Thank you.
Your Feature Request is a good idea. Iâve been using another home automation system for many years and it supports the concept of âthe source of the triggerâ. Rather than explain how it works in the other system, Iâll give you an example of how its implementation would look in Home Assistant (more or less). Basically, it would be part of Home Assistantâs trigger object.
- alias: Example
trigger:
platform: state
entity_id: switch.kitchen
to: 'on'
action:
service: notify.notify
data_template:
message: 'Switch was turned on by {{ trigger.to_state.source }}'
So if you were to manually turn on the switch, the source would be something like âselfâ indicating the switch itself was used to perform the operation (either via the UI or directly with the physical switch). If the switch was turned on by another automation then the source would be the automationâs name.
To be honest, I simplified the example because the other system provides more insight than just the sourceâs name. Nevertheless, that alone would be a step forward for Home Assistant.
As a part of the trigger object would certainly work for me. I am not that familiar with the HA codebase, but adding a source to the trigger object doesnât seem like a lot of work. Of course it wouldnât prevent collisions between automations, but youâd be a step closer to detect those.
Which other system are you using that supports this kind of stuff? Maybe we can learn something of that platform.
sysevent.srcElement.Class.Name
This is the class name of whatever caused the state-change. The closest analogy in Home Assistant would be the entityâs type (switch, lock, binary_sensor, climate, device_tracker, etc) or possibly even its platform.
sysevent.srcElement.Name
This is the name of whatever caused the state-change. In Home Assistant, this would be the entityâs object_id (or entity_id).
sysevent.srcProperty.Name
The device that caused the state-change is an object with properties and methods. This reports the objectâs method that was responsible for the state-change. Owing to architectural differences, I canât think of an equivalent in Home Assistant.
For my tuya devices I wrote my own little solution here. https://github.com/TradeFace/tuyamqtt It runs a thread per device monitoring how the state was changed; via the tuya device (button press) or via mqtt (ha automation). Atleast I am now able to use the wifi-switch also for presence detection.
Out of nowhere my bedroom lights went on in the middle of the night. It would have been nice to know what triggered it.
I think HomeKit integration went haywire but I donât have a way to probe it. It would have been nice to know if it was that or UI or AppDaemon web socket, automation, deconz integration, or what⌠Worse case I had my home assistant hacked and Iâm not even aware.
I hope this feature gets prioritise because it would really help to detect unusual activity and keep my mind at ease.
I guess duckduck isnât answering all questions.