Actually I think they’re reloaded by domains in that case, since you can have automation & scripts spread across packages as well.
I could be wrong, but that’s how I understood it. Since they’re not really working like a component ie: no requirements, no external polling etc.
Packages are loaded differently if you follow the code. Everything loads from a single file at first and separated after.
I’d love templates to have a reload function as well.
Ugh, don’t we all!
That’s a really great question, @hmoffatt. There are a few angles from which we can explore it. I should probably also do an experiment that touches on this as well. Thanks for the idea.
For now, this is my view of the situation:
First and foremost, Developers already have to update schemas, regardless of whether this works on YAML and/or the UI entities. The schema will change on the set up as well as how it’s passed to the DeviceEntity most likely.
With this proposed changed, the only additional change is to display that new data. (i.e. changing step 2 on the experiment). However, as stated before, what I would advocate is to make sure that the UI entities and YAML configuration match hence there are no additional changes needed, the output for future changes will already be fully updated.
The most important part here is that it would break for users. Hence, that’s where we should focus and expand a bit more.
The first way to look at it, and my personal preference, is that if there’s a schema change, YAML is expected to break. As such, the user is responsible for updating the configuration.yaml file. You can do that by going through the UI, for example, or reading an update on the changes as we have done until today (and, as a user, this has not been very frequent in my experience).
If this is not your preferred way, then you should probably stick to UI entities. I think this is an expectation if you are a tinkerer and want your YAML power.
Your question not only applies to YAML entities, but also to UI; hence, the first question is how UI handles it.
Let’s see at this code on the PS4 component from my previous experiment. The code responsible for the change of schema is async_migrate_entity. What this code does is read a parameter called “version” and change the schema from version 1 to version 2, from version 2 to 3, etc. At the moment we are on version 3. This data gets stored with the entity configuration so you can migrate from v1 to v3.
This very same logic can be applied to YAML. We could potentially add the version to the code (using Hue here instead of PS4, but it could be the same):
hue:
version: 1
bridges:
- allow_hue_groups: false
- host: 192.168.1.105
As this YAML should match the same as the UI config, it can use the same flow to input version 1 and output 2. The only complication here would be merging data when tokens and alike are present, but this is a different problem and I intend to also look at this a at a future experiment.
There are still issues when new data is required (unless default values are possible), but I think that would be the same for UI configured entities and the migration flow should handle that too.
You’re welcome to continue discussing this, but at this point it’s probably best if you make your own thread. Feel free to link to it from here.
I’m not sure why this should be split. All these messages are a request to bring back YAML, arguments against the original ADR-0010 and proofs of concepts that showcase the arguments.
This is not about custom components. I’ve just used custom components as a way to prove those points.
I feel like we are trying to silence the original blog posts making it seem like there really are no alternatives, and no more discussion to be made. And it’s a bit disappointing to see that on an open source community.
Since this is a topic in itself and still has a reference to the original thread there is no disconnect nor is there any censorship or silencing.
Could you please explain what Open source means to you?
You’ll notice an absolute lack of “silence”. If that’d been my plan you’d have found that the thread was locked and your posting rights revoked.
Instead your perspective on YAML has been moved out of the original thread, into a new one. This means that anybody interested can follow you here.
First of all, thanks for the replies. Tackling all of them in one post to avoid multiple messages.
Why move these posts, and not others, though? What’s the criteria? How’s my reply different than others or more unrelated?
I follow the Open Source Way: Transparency, Collaboration, Inclusive, Community are some of the words that comes to mind 
Fair, it could have been worse, yes.
Why move my perspective and not others’? My perspective, especially the first post moved here, it’s a direct response to the ADR-0010, or more specifically to the blog post itself. As such, I do not understand the decision and I do feel my opinion treated differently despite having invested time in reading and compiling all the messages, bringing arguments argued with data and examples, etc.
Also the blog post was moved as “YAML - cost of maintenance in custom components” which would make it uninteresting to people and completely unrelated to the actual topic. This is a thread about how I think the arguments given are debatable, and bring counterarguments, data and examples to it. It is was a conversation towards a decision with which I don’t agree.
(My response from Discord for reference)
“Hi Nito, sure thing. Because of the large amount of content in your replies (which is fine of course) I figured it best for you to have your own dedicated thread. The original ADR thread became busy very quickly, so having your own thread would help organize/consolidate your discussion. I didn’t actually make the decision to formally split the topic though.”
Hi @Tediore
As per our Discord, thanks a lot for your reply. It is very meaningful to at least get an explanation. I reached out privately on Discord to actually discuss aside of the community. However, since you have brought it here, happy to bring my reply as well and continue here if needed.
My objective with those posts is to bring counter arguments to the blog post; bringing a different point of view. These arguments include pure argumentation, bringing some data, a summary of the whole thread itself, and code examples to showcase that some of those counterpoints are valid.
I personally do not understand why some people’s opinions are valid to stay on the post, but mine needs to be split. Discussions were happening already, so it’s definitely not to boost the discussion (specially since this has been moved to “Uncategorized” with an unrelated title).
All the opposite, it feels like we’re trying to hide and bring those counter arguments away from the main thread on purpose (that’s how I feel). And that’s not really nice thing, in my opinion.
Not saying that your post/reply is different than others. But keeping this together makes it easier to follow as you’re providing a lot of content on that matter.
It would have been easier to follow if it was on the original post, to which they are related and a response to. Nonetheless, this is not a battle I’m going to win, you’re moderators and I’m not. You have the power to hide my responses away, to support the YAML deprecation as if no one is opposing to it or bringing valid counterarguments.
On my side, I will continue bringing counterarguments and bringing to the forum that I feel most relevant.
For the continued ‘clarity’ of others reading this post. It has unfortunately been split from the important discussion titled The future of YAML. In the interests of maintaining a lasting connection to that lengthy discussion which was split here may I suggest that those posting future responces should consider posting links to relavent sections of that post so readers may easily refer back from here if required.
No point in arguing about the split anymore. Let’s focus on bringing good examples about YAML maintenance.
For those interested in officially addressing ADR, I’ve submitted an architecture issue to allow YAML configuration optionally. The arguments that I’ve posted on The Future of YAML (now here) have been brought to official discussion. Comments can be done there instead of here as that’s the official channel for these conversations.
I have also submitted another one with a potential solution which advocates for reusing the same schema, set up and partially rely on UI to solve most or all of the problems with the “cost of maintenance”. This is based on the experiments that were published in this thread. More experiments could still be positive, for the same or different approach.
There are also alternative proposals. If you have your ideas, you should also feel encouraged to bring them.
That sounds encouraging at least.
Well, it will be less encouraging when you read that they will “not (be) doing this. Or any of your (my) other proposal.s”. 
However, this is the official approach to propose changes and everyone should be encouraged to do it. The owners of the project are on their right to decide what to do with those, but hopefully diverse perspectives and ideas can be heard; and, if we are lucky, we may hear the reasons for which those ideas are not worth pursuing.