#Why is there no "Devices" domain for integrations that don't act as platforms?

91 messages · Page 1 of 1 (latest)

proven flame
#

I'm getting into home assistant and I want to deploy all my config completely with yaml to follow IaC best practices, but one thing that seems to be missing is the inability to create device level integrations through the yaml config.
It seems that this would be pretty easily resolved if any "root level" device integration would just have a dummy parent domain called "Devices" that it could then act as a platform for.

For example, it doesn't make any sense that I can add an integration for Emby just because it can be used as a platform for the Mediaservers domain (see example yaml code below), but a similar setup for something like Sonarr isn't available because the integration isn't a platform.

media_player:
  - platform: emby
    host: emby.mediaserver.svc.cluster.local
    api_key: !secret emby_api_key
    port: 8096
    ssl: false

#### WOULD LIKE THIS TO WORK ####
devices:
  - platform: sonarr
    host: hostname.example.com
    api_key: !secret sonarr_api_key

Question,
If I were to build out an integration that did this, would this be as simple as just adding a wrapper around the device registry entries, or would this completely change how everyone would have to write their integrations moving forward, ie, all would have to support a platform for this new top level integration domain?

summer cobalt
#

Well that was the old way of doing things

#

and we dont do that anymore

#

as in, back in the day, the platform was the start, and there were components for that platform

#

then that got switched up into integration keys

#

so like modbus or mqtt now has

#

But everything is moving to the UI at a slow pace, so I would just suggest to not do this

#

you can manually add json config entries in a .storage file

proven flame
#

that kinda bites, I was hoping to be able to completely automate my config

summer cobalt
#

I mean, you can still automate your config, but its not as simple as just putting everything in a YAML file anymore

#

I think its also good to keep in mind HA was not built with the intention to automate your config

#

but in theory its possible

proven flame
#

I guess I got lead astray by old youtube videos when I was choosing platforms cause everyone was like, "yeah and it's completely configurable in yaml!"

#

and I got excited since I basically live in yaml config world for my job

summer cobalt
#

I received a nice sticker about that last weekend

proven flame
#

if you don't mind me prying, what was the reasoning behind the idea to start moving to the UI exclusively and not support both

#

couldn't the UI and the yaml interact directly with a core API for a more streamlined development flow and then make everyone happy

summer cobalt
#

as in

#

we don't want users to set up the same device twice

#

or service

#

And with UI we now just have a registry of all the configuration entries someone has

proven flame
#

ooooooooo

summer cobalt
#

I believe this was the whole YAML gate thing

#

you can probably search for it

#

But with that unique thing is, entities in the past came and went, they were fluctuous

#

they renamed with a code change and god knows why your automation failed

#

And we don't want changeable things in the unique id

#

as in, we want entities and devices to have an unique id, so we can track changes and you are able to rename them in the UI or do whatever with it

proven flame
#

oh so upstream changes would completely nuke configuration options and then your yaml magically was no longer parsable

summer cobalt
#

but that unique id can't contain ip address or stuff

#

so if you then have a service like sonarr or radarr without something unique, we can't give you all the possibilities of customizing the entity like you could before

#

And personally

#

HA is going in the direction of "my parents could maybe start using it"

#

and if YAML was still playing this big role it did

#

it would most definetly not suit my parents

#

Like, HA already has a massive learning curve, we don't want a million configuration options and another million ways how to do something

#

And would that suit the project? Since its open source and techy? Probably

#

But would that slow down adoption in the general public? Yes

#

Do we care about that? Yes in a way

#

we now get attention from the big players and manufacturers

#

LG made its own integration in core

#

Xiaomi is also making its own integration (custom and aimed at china, but still)

#

And do you have to care? No, not really as you might not use their devices, but in the end, the whole ecosystem of smart home will benefit from changes like these

proven flame
#

I get it. I was just hoping to hop into the power user side of things and it's a bit disappointing to hear after taking a while to go through the docs and understand the terminology in order to figure out how I wanted to build out my module structure and everything haha

summer cobalt
#

just build an ansible plugin to add config entries lol

#

I know that will be a future and its only a matter of when

#

😂

proven flame
#

that's not a bad show

#

shout

#

well now I'm super glad I moved off running core on kubernetes

summer cobalt
#

how so

proven flame
#

cause most of the integrations weren't available except through using the yaml stuff for core

#

or so I thought I read

summer cobalt
#

what version were you running

proven flame
#

uhh don't remember I can check the manifest that I had... one sec

#

oh no I remember what it was

#

you can't do addons

summer cobalt
#

oh

#

right

#

yes

proven flame
#

which was fine, most of my stuff runs on the cluster anyway

summer cobalt
#

I was about to say

#

Running core in kubernetes and then still wanting addon support sounds a bit double

#

like, go full kubernetes or go home 😂

proven flame
#

but I was having a hard time with egress traffic and I couldn't figure out why

proven flame
#

honestly now that I think of it, it was probably becuase that core weather checking integration uses something from the network capability and I never gave it that

#

that seemed like it was the only issue...

oh plus getting the sonoff dongle to work passing it through into a container

#

biggest pain in the ass

summer cobalt
#

core weather checking integration

#

bigger headache than kubernetes?

proven flame
#

I meant

#

that was the only thing that wasn't working while I had core running in Kubernetes

#

well, obviously not working anyway

#

I got the emby integration working

summer cobalt
#

what core weather checking integration uses the network?

proven flame
#

uhh

#

this guy

#

one sec...

summer cobalt
#

weatherflow?

#

tempest

proven flame
#

yeah

summer cobalt
#

UDP moment

proven flame
#

it was giving me network errors that it couldn't hit their api

summer cobalt
#

wait

proven flame
#

yeah

summer cobalt
#

weatherflow_cloud or the local one

#

the cloud one should still work

proven flame
#

it shouldn't have been blocking outbound connections right

summer cobalt
#

ah