Not fair, I’m telling mum.
1 Like
I don’t really have any special insight into this process but personally I wouldn’t expect a release until this OOO message gets taken down from the repo.
2 Likes
It would nice if you could add custom attributes to specific entities (and perhaps have useful defaults) that the recorder (and related, like influxdb) components could consult to decide to save the state of entities when they change. Right now, there’s configuration state specific to an entity spread all around. It’s more of an issue in these modern times when entities spring into existence without you editing a YAML file. You have to discover these new entities that get created by integrations and then remember to update the recorder settings. And in my case, for influxdb. Usually I miss these until it’s too late and a series has already been created in influxdb…
In this way, one could decided that the uptime sensor by default doesn’t get stored in the recorder database, and you’d end up with a sensor that more directly measures what’s of interest.
It sounds like you want an include filter instead of an exclude one in recorder and influxdb.
If you exclude the entities you don’t want then all new entities are included by default unless you specifically exclude them as well. If you include the entities you do want then all new entities are excluded by default unless specifically included.
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.
1 Like
The exact same problem with me. Have you found a solution?
Hello!
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!
Does someone else also has this problem?
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).
I’ve updated successfully to 2020.12.2 and HACS and my custom components are working as well.
Thanks. I did an additional restart of HA and now HACS is working.
/edit: after that reboot ZHA didn’t work. And after yet another reboot, that also worked again. Weird stuff…
Very strange, after two hours all is working fine. What is this for an error?
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.
- media_player.living_room_speaker
- media_player.dining_room_display
- media_player.bedroom_display
- media_player.bathroom_speaker
- media_player.laundry_room_speaker
- media_player.garage_speaker
- media_player.living_room_tv
- media_player.bedroom_tv
- media_player.deck_tv
The same thing with groups.
trigger:
- platform: state
entity_id: "{{ expand('group.media_player_entities_single')|map(attribute='entity_id')|join(',') }}"
group:
media_player_entities_single:
entities:
- media_player.living_room_speaker
- media_player.dining_room_display
- media_player.bedroom_display
- media_player.bathroom_speaker
- media_player.laundry_room_speaker
- media_player.garage_speaker
- media_player.living_room_tv
- media_player.bedroom_tv
- media_player.deck_tv
You can even combine the two and use both if you want!
group:
media_player_entities_single:
entities: !include /config/include/entities/media_player_entities_single.yaml
1 Like
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.
Since new release 2020.12.2, snapshot failed 
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
well… works again after several attemp. Strange
2020 12 02: Denon integration working again, Thank You Very Much !!!
Snapshot works here.
Sorry, but I have to disagree.
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.
2 Likes
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.
3 Likes
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.