Yes, there’s a certain trade-off here. I think it’s a bug that configuration state for one entity is scattered all over the place… it would be good if policy associated with the entity could be… stored within the entity itself. Since these things are not linked together, you have to manually “garbage-collect” configuration state elsewhere if you delete an entity or rename it.
But Home Assistant has pretty strong feelings about having optional/unexpected/unknown attributes that you might try to specify, so you can’t really do this.
For example, it would be great if I could have some user-specified tag attributes for light entities… like this light is shouldn’t be dimmed. I have some LED lamps that just happened to be connected to Z-Wave dimmer switches that don’t behave well if you try to dim them. It would be nice if there was an attribute I could associated with that light entity that automations could consult and know not to try some clever dimming actions. But instead, I have to have a list of these special lights in various places and remember to update each of them should I replace the lamp with one that happens to now be dimmable.
Yea that’s fair. There was a pretty popular WTH post about getting this configurable in the UI as part of entity configuration. I even threw together a hacked up mockup somewhere down the discussion lol.
Btw for your second use case, you can use customize.yaml to add custom attributes to your entities. So if you want to add an attribute of not_dimmable to your non-dimmable lights you can do that with the current featureset. HA won’t look at that attribute as part of service calls but you can certainly leverage it in automations and templates.
I installed 2020.12.2 of Home Assistant and now all my Custom Frontend integrations installed via HACS (Vertical Stack in Card, Bar Card, Mini Media Player, Battery State Card and Mini Graph Card don’t work anymore.
I rebooted the whol Raspberry Pi (HassOS 5.9) but nothing changed.
The cards are all shown in red!
Indeed it seems HACS can’t start as per 2020.12.2. (click on HACS in sidebar). It says I should check the logs, but I can’t find anything related to HACS in there. But my custom_components installed via HACS are working (components, I don’t use cards).
Use include files and/or groups. Make the change in one place.
I frequently need a list of media players that are not speaker groups, Spotify players etc. Adding or deleting one of these media players is as simple as adding it or removing it from the include file list or group.
trigger:
- platform: state
entity_id: !include /config/include/entities/media_player_entities_single.yaml
The contents of /config/include/entities/media_player_entities_single.yaml.
I understand how using groups might work; however, architecturally the rest of the attributes of an entity are stored within the entity itself. So when I define an MQTT light in YAML, it seems most natural to have other attributes specific to that light be a property/attribute of the entity, defined in the same place. I find it a little ugly that I have to use customize: elsewhere to attach other information about the entity, rather than having it defined in the same place.
The “packages” thing at least let me contain the entity definition and customize stuff into a single file… It’s just that I have hundreds of entities and having definitional configuration state scattered all over the place make maintaining this stuff harder.
I suppose this is less of an issue with more and more of the entities and devices being instantiated by way of the UI rather than in a YAML file. In the grand scheme of things, this is not a huge issue, just a wart.
20-12-30 21:26:57 WARNING (MainThread) [supervisor.jobs] 'SnapshotManager.do_snapshot_full' blocked from execution, system is not running
20-12-30 21:27:36 INFO (MainThread) [supervisor.snapshots] Found 4 snapshot files
20-12-30 21:27:38 WARNING (MainThread) [supervisor.jobs] 'SnapshotManager.do_snapshot_full' blocked from execution, system is not running
One of the major pain points of HA is breaking changes that require restructuring. Sticking to semantic versioning allows one to have some confidence on the underlying software because t is generally accepted that there will be no breaking changes within a major release.
We currently know that breaking changes are likely because all the revisions are minor. The hope was that HA would eventually go to 1.x.y and there would be no more breaking changes until 2.0.0 There could still be functional improvements and additions provided none of them broke the API.
Moving to date versioning is just a cop out that avoids the issue.
That’s impossible, home automation is evolving so fast and there are so many APIs that change randomly that you can’t avoid breaking changes.
I started with version 0.4x, so I lived through quite some releases and breaking changes. I can’t remember a single release that took me more than 30 minutes to adjust my config for the breaking changes. Most of the time it takes me longer to read the release notes than to adjust my config. Especially since they optimized the release notes and breaking changes section.
Update to 2020.12.2 broke my Tasmota(beta) integration.
Going back to 2020.12.1 and everything is ok.
No related entries in the log that I could find. The integration is just stone dead.
I’m not sure I can agree 100% here. Certainly third parties can change APIs and that will impact any home automation system. I don’t see that as a “breaking change” within HA. Certainly we’ve all heard “Vendor X doesn’t support Function Y effective some date.” We don’t blame the platform we’re using it on, we blame the vendor (or cheer, as in the case of Flash).
True. But even so, without a fairly deep technical knowledge, it’s easy to miss a change that impacts my system. It’s happened to me. It will happen to any beginner.
I guess I’ve always known this, but frankly the comments above are an admission that HA will never be “ready for prime time.” It will always have a niche market of tinkerers and geeks. At least I know I’m in good company.
But I did have visions of a “Version 1” which I could recommend to friends who don’t enjoy spending hours reading release notes and digging into the system to see how the breaking changes might affect it.
If a manufacturer changes the way one needs to authenticate to communicate with their API, there’s nothing Home Assistant or any other Home Automation system could do, without a breaking change.
I think what CaptTom was pointing out that any vendor changing anything that causes Home Assistant not to run correctly is not a “Breaking Change”. This change effects both old and new code. If the vendor makes a change that still works in Home Assistant but doesn’t work in an update then that is a Breaking Change. In any case the changes get evaluated and either changes are made to Home Assistant to support the change or the documentation is updated saying that that device / vendor it is no longer supported.
