I just tried 0.110 on dev environment… Seriously guys, this is not funny anymore. I lost my ability to configure ONVIF via Yaml files. I’m not going that way and will stick with 0.109
UI integration should be also more matured allowing a control over integration after first time install. Today a lot of integrations don’t alliw perform changes other way than removing integration and setting things up again. Such limited possibilities are not acceptable.
10 Likes
That is in train.
This, and very much this!
I’m wondering if it’s worth continuing with Home Assistant if my configuration API is disappearing…
6 Likes
Keep up the great work.
I like the new front end and cleaner yaml files.
Helpers are awesome.
Now with more tasmota auto discovery options for sensors and switches it makes things even faster to integrate new devices.
1 Like
For those of you who are frustrated by this decision:
It seems a bit hard to change the decision that has been made and the owners of the repository can (unfortunately) take such decision. There’s a bit of evil on the good, and a bit of good in the evil.
Like many of you, I have also expressed my opinion on why I do not think this is the right decision from an Open Source perspective. Although many of you have articulated the reasons for which is a bad decision much better here.
However, my question would be: when the decision is implemented, what can we do? I have some ideas and I will be sharing some of them soon both focused on users and developers. I would love to read some of your ideas too.
10 Likes
From your twatter thread
Personally, I’ve taken down 2 published components, removed HACS support for one of them and cancelled other plans for components that I was building for home_assistant and their HACS support.
Childish? Yes
And what have you got against HACS?
2 Likes
Apparently HACS is an official custom integration. 
It’s not.
My first idea was to completely remove the integrations, which I did consider and did with some of them.
I finally decided that having to copy the code was better than install it from a UI. It’s kind of the opposite of what was decided on this blog post to force people to use UI for official integrations.
Thanks for sharing your opinion. You can read my previous message on why I want things to be installed only via code rather than via UI only.
(Actually, I would prefer both, but then the official integrations only offer one of them).
Removing your custom components from HACS is unrelated to this issue. Anything on HACS is installable via command line.
Also custom components do not have to be configurable by UI. They can stick to yaml. They won’t ever make it to core, but that is not the point.
To be very clear, this thread is about the deprecation of core integrations to be configured by yaml.
1 Like
It was not me who brought it up and I agree. Let’s focus on Home-Assistant to not support YAML on new integrations.
Yes you did, you said you were removing HACS support as protest about partial yaml deprecation.
I linked Twitter with my opinion. 99% on that tweet is about why I think deprecating YAML on official integrations is a bad decision and powered by NabuCasa interests. From that tweet, you cherry picked the part about me deprecating HACS and, instead of replying on Twitter, copied that fragment to this post.
In any case, can we focus on the topic at hand around the deprecation of YAML for new integrations? (and probably in the past ones at some point, since you cannot also make changes to the YAML config and if the spec changes, YAML configuration would no longer work).
1 Like
It has been discussed to death. The decision is done, for better or worse, so your protests, like the others (including me), will fall on deaf ears.
Given that it is a done deal, either you want to work with home assistant or you don’t. If you don’t, then I suggest you get an interest in procreation and travel.
1 Like
That was a smooth change in topic, but at least back to the original and ‘productive’ one 
It has been discussed to death. The decision is done, for better or worse, so your protests, like the others (including me), will fall on deaf ears.
Yet, you’re still replying and replying to my posts. If you really do not care, there is no need for you to engage. You do not need to reply. It would best for both
If you are wrong and someone cares, they will engage. If you are right and no one cares, then there’s nothing for you to worry.
Given that it is a done deal, either you want to work with home assistant or you don’t. If you don’t, then I suggest you get an interest in procreation and travel.
I think there are more options than this. My post was asking and trying to be productive on that:
However, my question would be: when the decision is implemented, what can we do? I have some ideas and I will be sharing some of them soon both focused on users and developers. I would love to read some of your ideas too.
I do have some ideas and I am working on a small post that I will be sharing when ready. I hope those who care will engage, but so far I’ve only encountered people deviating from productive conversations or even from the main purpose of this conversation.
2 Likes
For those interested in the “cost of maintenance”, this is how much it took me to add support to the PS4 component:
Config = collections.namedtuple(
'Config', f'{const.CONF_ENTRY_ID} {const.CONF_DATA}')
async def async_setup_platform(
hass, config, async_add_entities, discovery_info=None):
"""Loads configuration and delegates to official integration."""
# Load configuration.yaml
host = config.get(const.CONF_HOST)
name = config.get(const.CONF_NAME, const.DEFAULT_NAME)
region = config.get(const.CONF_REGION)
token = config.get(const.CONF_TOKEN)
# Format it in the new config_entry JSON format.
config_entry = Config(
util.slugify(name),
{
const.CONF_TOKEN: token,
const.CONF_DEVICES: [
{
const.CONF_HOST: host,
const.CONF_NAME: name,
const.CONF_REGION: region,
},
],
}
)
await ps4_media_player.async_setup_entry(
hass, config_entry, async_add_entities)
return True
Although, of course, this assumes you already have the token. However, the same config_flow could provide that for you to configure as many other components do. I will be publishing a full example when completed.
It might work but its not an acceptable implementation since you go to async_setup_entry directly
Can you explain further on what’s wrong with it and/or how to fix it?
Do note that the full code is not here, I am working on a component based on this. However, happy to tackle any issues that there might exist.
1 Like
You need to create a config entry in order to use async_setup_entry. You need to create a config flow with an import step that can be called in async_setup