I hope they find a way that both ways can coexist. Otherwise home assistant will loose a lot of early adopters
5 Likes
Hi, please check the email for group partner
We’re writing to let you know that the group you tried to contact (partner) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren’t able to post…
Agree, Both ways need to exist
Off-hand, I cannot think of any (or many) GUI options added that intentionally broke YAML customization.
Fixed the email permission settings.
1 Like
this is why I hard-code my devices instead of relying on ‘discovery’.
But in this case the log is constantly spammed with a lot of error messages or the component does not start…
What Home Assistant really needs for 1.0 is to separate components and make it possible to install components from other sources. (No I don’t mean putting them in custom_components)
Home Assistants can’t be responsible to make sure the Verisure or Volvo-on-call component works. A component maintainer should be able to release a new version, without the need to do a PR to HA core.
HA core should be just core, maybe some small essential components, but the majority of components should not be included in core at all. They should be maintained outside core. Just look at any other open source plugin framework/platform. None is holding all plugins in the core.
This also brings us to the release notes:
By just providing core, there wouldn’t be any patch releases because some small mistakes in a single component. Right now, I’m updating core every time a new release is out, just to be sure not to miss anything or make it impossible to upgrade the next time. This is not a sustainable solution.
Also, here we have the “custom release notes”. Uses will only get release notes for core (that we all use) and the components that we actually use.
2 Likes
You are describing Hassio addons, each in their separate Docker container.
Are you suggesting that the binary sensor nest should be an hassio addon?
That sound like a very bad pattern to me.
1 Like
The addons run in a maintainer controlled environment independent of Hassio That appeared to be what you were requesting & it is available now to anyone who wants to create & distribute an addon.
If they wish, they can submit a PR to have it added to the default repository.
Nah, that wasn’t what I ment.
Lets take the “tråfri” component as an example.
It is a component consisting of at least 3 platforms (light, switch and sensor).
Every time there is a change to one of them, or the component itself, someone has to make a PR to the HA core. Then someone with commit access most accept that PR and merge it into core. Then core has to make a release so everyone can upgrade to the newest stuff. If for what ever reason, the change in the trådfri component is a breaking change, the the HA core release will become a release with breaking changes. In any normal application development state, this would mean a major version bump. To only bump a minor, which is the case today is just because, I don’t know, the project might have grown to large.
I don’t use Trådfri at all, why should I have it on my system? It has nothing to do with HA core. HA will still work fine without trådfri for me. There are about 800+ components bundled with core now. Can you imagine what this will be in a year? In five years? Not sustainable at all.
Config entities doesn’t solve this either. Sure it will make it better, but in the long run, this will be the death of HA.
2 Likes
Ah, I see. I thought I read somewhere that they were looking toward more of a “plugin” model.
I expect some components not all of us use will still be considered core. I do not use the cloud service but expect it to remain core in order to promote its use.
On Breaking changes
The changes as such do not scare me that much.
The issue is in the release notes. They are mostly 2-3 lines and links to resources that do not say anything about the changes. The link to the github defect is most often some insider talk with little information what I need to do to do the upgrade. And the link to the documentation shows how things are after the change IF the documentation has been updated.
What I usually end up with is finding a forum discussion where people are in trouble and get help and that is where I learn what I need to do.
What would help me is that the release note shows a few lines of config with the message
If you have this config related to XXX you need to change it to this config
The last update to the Google TTS was a bit cryptic but ended up being incredibly simple once you understood that you needed to find a specific content in a yaml file and change one line and add one line. With just a few lines of example the release notes become much more easy to follow even without the need to understand the technical background
1 Like
You should listen to the Home Assistant Podcast. Their most recent episode they had Pascal on who talked about exactly this.
Thanks, I will.
Oh, and the Home Assistant Architecture repo. A lot of the ideas I see brought up by users as new ideas for HA are often things that the developers have already thought about or are considering. The Architecture repository is where these things get discussed.
1 Like
Awesome resource. Thanks for letting me know. I will follow that issue.
This information needs to to be in the Release Notes.
Not everybody has time to watch a podcast and some of us are hearing impaired which adds another level of difficulty.
There’s nothing released yet, he was just talking about possible future plans on an unofficial podcast. I don’t think release notes is the right place to speculate about future possibilities.
If you want a written version you can read through the architecture repo.
That’s fine. I’m sure it will be in the release notes when there’s a final product. I was just suggesting a place to hear the inside scoop, nothing most users need to know unless their interested to know what’s in the works, or suggesting new ideas that are already planned.