architecture
architecture copied to clipboard
home-assistant
Definition of interfaces
Context
We have ever year the same discussion for fake/soft functionality on platforms/integration outside of the primary term on the underlying Hardware or target to solving the main issue. Everyone tries to solve his user case without care of the complexity grow, the maintainable, or a big picture in front of it.
An example, on the binary sensor platforms. We removed a lot of fake delay_on or delay_off because a Hardware interface should represent what the underlay hardware support and not add extra software logic. Before, we had the same code over and over in binary sensor code base on different integration. Most of the functionality like delay_on or delay_off can also be handled by an Automation state trigger like for. However, to point every time to an Automation solution, we had implemented this functionality even once to Template binary sensor. The template platform is our logic integration that can handle real software logic and can cover other Entities/Platforms to extend the functionality. Another example was the fake away function of some climate platforms; they now also removed.
However, we had the same discussion so many times in the year and on so many PR, that it not make fun anymore. And we should set a clear definition of what can implement soft logic and what is the primary goal of integration.
Proposal
An Integration with a hardware/service API reflects this functionality on Home Assistant in a typical way for the corresponding component/platform. Extra functionality/logic outside of the mapping between Home Assistant <--> hardware/service/API are not allowed.
Logic integration outside of Template allows because it makes some user cases simpler. They can't go into any competition to the Template equivalent and implement the minimum of needed logic.
Soft/Fake functionality, they can be used by different platforms, need to be implemented by the corresponding Template platform and allow to cover that case once for everything.
Consequences
Integration are better structured, and it's clearer how things work. It removes some ways to Rom, but on another side, it makes some exists way bigger.
If I understood corretly - in example users of RFlink with 433 MHz sensors that send only one code, wouldn't be able to use 'delayed_off' to change binary sensor to off? Right now in example I use door-sensor with one code to trigger binary sensor (which triggers all other automations) and after few seconds it changes it's state to off (as no other code is being sent by physical device).
Maybe, but it's much easier to see 'event' happened with binary_sensor changed state with entity added to UI. :-)
I have RF433Mhz motion sensors, they only transmit upon movement detection.
It's quite relevant to me to monitor them through a binary sensor. Please don't make them event's only...
Like this example other similar ones exist (can recall mqtt integrations)
I agree with this issue. All features need to be provided by the actual API of the devices or need to be provided by either the entity integration (light, sensor etc) or by integrations that only consume data from Home Assistant (ie template).
I do think that something like MQTT could be treated special, because MQTT is really a transport layer instead of protocol.
There can easily be a template binary sensor with a cooldown bound to an event, etc. That way we only have to build a UI once to tweak it. Maybe we can even allow integrations to expose the events that are suitable for this etc etc. Other alternative is that the binary sensor integration offers this functionality.
If only one signal is sent, shouldn't they be events?
Yes, there is some motion sensor, they send only events because the device has no "state". The last one they I had seen was on Xiomara. If they want fake a state, they could have a fixed value of maybe 30sec to fake a presence/motion binary sensor. Keep it simple work, in this case, perfect without need an option. Later the state trigger on automation can help to trigger that fake state binary sensor as they need.
I think 98% of our integration is confirming to this ADR. It's some times simpler to point to an ADR instead to have the same discussion again.
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
