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

[petro]

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.

[corgan (Stefan Knaak)]

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.

[petro]

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.

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

Hi all! Thank you for all the feedback about the menu change in 2021.12. Any feedback is welcome to make Home Assistant a better product for all of us . Although some comments are not constructive and may be interpreted as a personal attack. Love to see that a lot of you are personal committed to Home Assistant. Please use that energy into making something positive, like sharing thoughts and ideas. Or even design or develop! I just replied at the Github discussion, feel free to join: Navigation…

[smarty]

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

[spacegaier (Philip Allgaier)]

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

[denisbondar]

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.

[spacegaier (Philip Allgaier)]

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.

[aidbish (Adrian)]

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

[matteos1 (Matteo)]

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

[nickrout]

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

[matteos1 (Matteo)]

xiaomi miio & 2021.12.4

[smarty]

knx gateway auto discovery in 2021.12.5 is working again Thanks!

[Magnus33 (Eric)]

Anyone else noticing icons not updating their status correctly?

Seems to be on tuya connected ones…

After a restart it seems to work fine but randomly decides not to at a random time.

[thomassandsor (Thomas Sandsør)]

I only have 2 Tuya devices on Wifi and see them being wrong. If it is off and I turn it on, the switch jumps back to off (but lights stay on). If I click the switch again nothing happens, because it wants to return to off position. If I click quickly on and the off, the lights will turn off.

[Magnus33 (Eric)]

Its behaving like it did when they put out the new tuya and forgot to including adding the notification option during setup.
I no this is not the cause since i haven’t changed my tuya and i put in the edit request for the tuya documentation to prevent others from running into the problem.

Also on a restart everything works fine for a time then it suddenly stops updating so i doubt its tuya servers.

Looking at the git hub it seems it’s not a isolated issue either. issue #743

Looks like it was a issue with the token refresh not working and its been patched and is being tested so a tuya integration update should be out soon.

[xADDRx (Ben)]

Hi,

the menu items are listed, but the window simply stays black when you click on it.

Any Idea?

THank You

[Magnus33 (Eric)]

Go into integration and click on the three dots and reload the tuya integration.

This will refresh the token and let it work correctly for a few hours and then you will have to do it again.

They are aware of the problem and doing final testing on a permanent fix.

[xADDRx (Ben)]

sorry i forgot the file in www

Works now

THank You!

[pops106 (Jody Popplewell)]

Is anyone seeing any problems with Tuya Local after 2021.12.6 update, both of the devices are showing unavailable but Local Tuya all devices are working as expected.

I am using Local Tuya for switches and bulbs, then Tuya Local for climate(thermostat) and a power monitoring smart plug.

EDIT: It has come back now but took a lot longer than usual, I believe… I don’t exactly sit and watch it after a restart.