This caught me out too -
now I have to use:
country: gb
province: Scotland
Whereas previously the documentation said:
country: Scotland
This caught me out too -
now I have to use:
country: gb
province: Scotland
Whereas previously the documentation said:
country: Scotland
Yeah, the breaking change appeared to be in the library HA uses but doesn’t manage. Hence why it was missed.
Doesn’t it feel “devastating” that Scotland “still” is a Province to a “Country” called gb ?
Just reverted back to an older version for the time being and things are ok.
yes MariaDB…
there’s a whole other discussion on that still being advised or not
For those who have Zigbee ZHA issues after updating to 2022.4, this is what I have learnt:
There were significant changes to ZHA quirks going from .69 to .71. If you were using custom quirks, you either need to replicate those changes there or ensure you are using .71. Don’t ask me questions about this as I am just repeating what I read and can’t add anything to it
If you have a ConBee II coordinator, like myself, the issues may be unrelated to the update itself but rather a recurring issue that ConBee II users tend to run into. I have before but was able to recover with things like unplug, plug back in, reboot, etc but this time this has not worked. ZHA folks are trying to make this better but I don’t think there is a timeline. I have opted to move to a Sonoff Zigbee 3.0 Dongle Plus as it appears to have better hardware than the ConBee II and will hopefully not suffer from this issue. It would seem that the ConBee II can run into this issue (dead or very unresponsive network) with a simple reboot… I am not certain but I believe I’ve had this happen to me at least twice in 8 months or so. Time to move my 90 devices over to a new coordinator as this is too big of an issue.
Sometimes some zigbee devices mutiny the coordinator and just start causing network issues. I have a couple of those (not unique devices, but they seem to be culpable when this happens) and when I delete, reset, add back, the issues go away. (Smarthings Samjin pocket socket & Jasco Light Switch - I have quite a few of each but only these 2 tend to cause trouble, and no I don’t have mesh issues where they are)
While there are quite a few of us that started having issues after the update, I was told that my logs show the coordinator can’t talk to the devices as they are stating they are busy. The logs that revealed that were from AFTER quite a few radical attempts at fixing this mess so… who knows… the update may have sparked a sequence of events that led me to where I am now. I deleted ZHA and added it back to see if it would help… I lost all my entities for 90 devices… but I intend to change coordinator tomorrow so it was worth a try. I am still waiting on the mesh to build up, or whatever it is doing, to see if the devices start working again, regardless I will reset and add them to the new coordinator tomorrow.
I don’t know how correct what I wrote above is, as I am still learning, but I hope it can help others.
Agree with observations. I had a custom quirk for a curtain and when I updated, it borked my ZHA network. It was easy to tell the custom quirk was an issue so I removed it and I assumed it was from the changes to quirks. HA and the other 62 ZHA devices have been woriking since but now I am in search for an updated quirk or ZHA support for _TZE200_rmymn92d.
I also have no idea of how to fix/move forward aside from getting the _TZE200_rmymn92d entities supported same as _TZE200_xaabybja.
If somebody could provide a newly updated quirk from somewhere to where I can plug in my own guts, that would help me. I just don’t know enough about custom quirks to create one without copying somebody elses.
Has anyone else noticed significatly longer restart times for Home Assistant with this release?
I’ve gone from 65 sec to 3 minutes at best and 5 minutes at worst and it’s not just integration initialisation. The frontend is not available for a lot of that time. I see this in the previous log (config/home-assistant.log.1):
2022-04-09 15:40:38 WARNING (MainThread) [homeassistant.core] Timed out waiting for shutdown stage 1 to complete, the shutdown will continue
2022-04-09 15:40:54 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/zeroconf/_services/browser.py", line 444, in _async_start_query_sender
await self.zc.async_wait_for_start()
File "/usr/local/lib/python3.9/site-packages/zeroconf/_core.py", line 500, in async_wait_for_start
raise NotRunningException
zeroconf._exceptions.NotRunningException
2022-04-09 15:41:38 WARNING (MainThread) [homeassistant.core] Timed out waiting for shutdown stage 2 to complete, the shutdown will continue
Hi Guys,
could it be, there is a Bug in Play Media with Sonos and a scene (Version 2022.4.1)?
I use a scene to start my Sonos like this:
- name: "Morgen"
entities:
media_player.standardraum:
state: "playing"
and now I get this error:
Entity media_player.standardraum does not support this service
so i chanded the state to one of this:
turn_on, media_play, play_media
now ill get no more errors in the log file, but the Sonos is not playing anything
In Version 2022.3.8 everything is fine
The fix is easy. Just modify the file called out in the link above.
Lost all my zigbee devices as well. At first the restore didn’t seem to work either, but luckily they woke up in a minute.
Just the opposite, the startup is noticably Witcher, butt the rendering of dashboards is jankier.
Changed it and still doesn’t work,
@property
def extra_state_attributes(self):
Hi all,
Thanks for all the hard work all the the new stuff
Problems that where better or worked in 2022.3.8
Best regards
Thekholm
Just found a GitHub issue for the issue with scenes: LG webostv unable to restore state in scene when sound_output is external_arc · Issue #69740 · home-assistant/core · GitHub
yes, thats what I am seeing too, loads of frontend delays (where it was supposed to be much faster because of the web socket changes,HAWS 6.1 by balloob · Pull Request #12016 · home-assistant/frontend · GitHub and Websocket api to subscribe to entities (payloads reduced by ~80%+ vs state_changed events) by bdraco · Pull Request #67891 · home-assistant/core · GitHub). As far as I can tell that hurts. And frequent auto reloads too.
on top of that, I also see the new update entities are very often unavailable. Which is really nasty, because having moved from rest sensors to rely on this new integration doesnt prove to be very reliable currently.
startup itself varies I must admit. Sometimes it really is faster (2 minutes for a full restart where it was more than 4), but sometimes I see the same as Tom, and the exact same messages.
dev tools states is really much laggier than before, and pages with history graphs / apex custom cards dont release the frontend when eg clicking a more-info…
add that to the not working statistics editor
and its a bit of a mixed experience
Just wondering if there is / will be an MQTT discovery variable for ‘Switch as X’ ? There is currently a “device_class”, variable in the switch platform, but the only available option right now is “outlet”, and all it does is change the icon in the interface. . It might be nice to expand on that and add these newer options I imagine that is what it was originally intended for.
That looks like an integration is creating tasks at shut down that are not completing. Turn on debug logging for homeassistant.core and it should report the tasks it’s waiting for.
It seems to be Kodi.
It only occurs if my Kodi boxes are awake.
EDIT: Ok False alarm. This was caused by my Cinema Kodi box half crashing. I could still connect to it via SSH and connect to it via the web interface so I thought it was ok, but when I actually went and looked I was unable to control it with any remote control.
After restarting the cinema Kodi box my restart times are back to 60 seconds!
This is with both the Kodi boxes awake. I’ve yet to see what happens when they are asleep but I’m closing the issue.
Really awesome new feature list, great work
Many useful improvements, love them