2021.12: New configuration menu, the button entity, and gorgeous area cards!

delighted to hear you are making a record though not sure I’d put this on it :slight_smile:

anyway I may have been off with the version of HA this was released in…was maybe thinking of the general upgrade/refresh the Kasa integration got a few releases back…my bad.
That said, the changes around the LED setting and the new entity is definitely documented in the notes as I recall reading it…as I said it’s just a case of looking in the release notes (see below) :thinking:

Have Fun! :+1:t2:

OK, This solved the problem. Thank you.

Hi, I got Hassio last core (2021.12.4) on Odroid C4. Since the update from 2021.12.3 to 2021.12.4 my CPU usage jumped from 15% to 30-35% !!! Anyone already observed such bad behaviour ?

No change using the generic x86 image.

Here is my graph…

Which kind of card is this? :open_mouth:

Carpet plot plug-in in Grafana.

2 Likes

Is there any procedure to edit docs? I mean, may I add some changes to the docs, shall I approve it first?

At the bottom of every page in the docs you can Edit or Provide Feedback. You can either write up an issue to notify people that there’s a problem with the docs (Providing feedback), or you can suggest an edit to the docs (Edit).

This is then reviewed and merged (or rejected) by someone. The people that review & merge are usually frequent volunteers who’s been contributing for a long time or someone from the core team.

3 Likes

100% agree. I can’t understand why the Menu was changed in that way.
Merging and make it more “bling” is a good thing. But instead of “better looking” it should be changed in the way to make it easier or faster to do things. One click more sounds not a lot, but in the daily use its really annoying.

There’s a thread above that links to the discussion and the reasoning behind the change. It also discusses the direction the UI is moving in regards to this menu.

Yeah, knx is broken, I’m using auto config. Downgrading…

FYI: Only the auto gateway detection is broken. KNX itself works fine if you have manually specified the gateway.

1 Like

3 posts were split to a new topic: Irony about UI / Yaml changes

Hi! I had exactly the same problem.
This is because the format of the device / identifieds entry in the .storage/core.device_registry database, in my case for a MikroTik device, is incorrect, generated by the HACS add-in MikroTik.
The value of identifiers should be a list consisting solely of lists, and in this addon it was a list of scalars, including numeric ones. While string scalars can still be iterated without causing an error, numbers cannot.

How to solve the problem:

  1. Stop the homeassistant container
  2. Make a copy of core.device_registry (located in .storage)
  3. Open core.device_registry and find there the list item “devices” whose “identifiers” are not lists, but scalars (strings or numbers) and remove the whole thing from “devices” (or put every lite into square brackets).
  4. Try to run the container homeassistant - after that it started for me
  5. You need to remove the integration and then delete the problematic addon. After that the problem will happen again because the same data with the error will be written in the same file, but now in the list of deleted_devices - now you have to do the same thing, but now delete not from devices but from deleted_devices.

Maybe there is an easier way to fix this error. For example, instead of deleting block from devices you can put every scalar line in “identifiers” in square brackets.

1 Like

In my previous life as a Support manager for a global software publisher, that would have MANDATED a study on the effects and a UAT before deployment to the production branch

IMHO that is comparing apples and bananas. One the one hand a global software publisher with a full-time paid team and here an open-source project mostly driven by spare-time devs (very few at that when looking at the frontend specifically).

I get the point that this was a somewhat disruptive move and in the future might be handled differently, but you already mentioned the “pain” that trying to support various additional different parallel implementations (via different config checkboxes) would introduce and the maintenance burden that always comes with those.

Reg. more upfront communication (also mentioned by @maxym): Who should handle that? The already limited devs? Not really realistic for the project currently as far as I see it.
Looking at it from my purely personal point of view as an frontend developer in this project: I am already investing my spare time to e.g. fix frontend bugs (mostly ones that do not even impact my HA setup). I cannot see myself on top writing blog posts or forum posts about upcoming changes / fixes. Then many things would simply not get changed / fixed anymore.

Also the release notes are available a week before a new release in a draft version once the beta hits, so then people not following the development process, can already get a heads-up.

Once again, I understand where you are coming from, but I fear there is a lot of wishful thinking in that comparison.

6 Likes

Your issue on github requires more information as requested by the dev, untill you give that your not going to get much assistance and you will probably find it wont be fixed in 2021.12.5 or any till that occurs

I already write on GitHub with log . But the error is always there

Logger: homeassistant.config_entries
Source: components/xiaomi_miio/init.py:465
First occurred: 12:07:32 (1 occurrences)
Last logged: 12:07:32

Error unloading entry chuangmi.plug.m1 for xiaomi_miio
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/config_entries.py”, line 452, in async_unload
result = await component.async_unload_entry(hass, self) # type: ignore
File “/usr/src/homeassistant/homeassistant/components/xiaomi_miio/init.py”, line 465, in async_unload_entry
hass.data[DOMAIN].pop(config_entry.entry_id)
KeyError: ‘64f903fc67b6027e7420946d0b28bd0e

A link to your issue on github would be more useful.

1 Like
1 Like