Closed elupus closed 1 year ago
An alternative approach here would be if we can deduce the trigger cause by looking at the context parameter of the service call. But even if we support that, i think explicitly stating a cause would be nicer.
This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.
For that reason, I'm going to close this issue.
../Frenck
Still relevant, but gave up in internal stuff and moved to custom component.
Context
Currently to keep track of what/who triggered a manual alarm, you need to keep some separate helper entity updated when triggering alarms to indicate what was the cause of the trigger. This leads to extra complexity on manual alarms.
Proposal
Allow the alarm_trigger and possibly other services to take a
cause
parameter that can get stored in the already existingchanged_by
attribute populated by some non manual alarm panels.Consequences
The notifications based on a triggered alarm can use the attribute of the alarm panel to indicate what triggered the alarm without introducing additional helper entities.