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.
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.
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:
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.
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.
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.
knx gateway auto discovery in 2021.12.5 is working again 
Thanks!
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.
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.
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.
Hi,
the menu items are listed, but the window simply stays black when you click on it.
Any Idea?
THank You
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.
sorry i forgot the file in www
Works now
THank You!
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.
