2 dev team: please stop moving all integrations to UI w/o yaml support

Ildar_Gabdullin · September 28, 2022, 8:37pm

Yes, this is an old issue.
But this trend becomes THE ONLY RIGHT WAY for developers of custom platforms.
They are following this trend and stop supporting of yaml - and then explain it as “this is a requirement from HA dev”.
Really annoying.

tom_l · September 29, 2022, 2:49am

This is the ADR that outlines the requirements for UI / YAML:

github.com

home-assistant/architecture/blob/2017fdae15d48f287f2398e3243a91ec7a34b161/adr/0010-integration-configuration.md

# 0010. Integration configuration

Date: 2020-04-14

## Status

Accepted

## Context

Home Assistant has been relying on YAML for its configuration format for a long
time. However, in certain cases, this caused issues or did not work at all.
These cases are best explained by listing the different categories of
integrations that we have in Home Assistant:

- Integrations that integrate devices. Examples include Hue, TP-Link.
- Integrations that integrate services. Examples include AdGuard, Snapcast.
- Integrations that integrate transports. These integrations allow users to
  define their own protocol. Examples include MQTT, serial, GPIO.
- Integrations that process Home Assistant data and make this available to

This file has been truncated. show original

Ildar_Gabdullin · September 29, 2022, 3:22am

I see, thank you.
Seems that because of a risk of loosing developers, HA devs decided not to insist on “always support YAML” way. Now it is “via YAML or via the UI” - and plugin developers prefer a simpler way “UI only”.

As for “only yaml for devices & services”.
For instance, these integrations:

Life360 (standard) - seems to be a “service case”, so it is “UI only”;
iPhone detect - a month ago moved to UI completely (no yaml support) - is it a “device case”?
Places - worked more or less OK, recently moved to UI (no yaml support) - is it a “service case”?
season (standard) - moved to UI - what case is it ?