Having the exact same issue. This was working previously for over a year on 5 different casted Google Hub’s around my house but now the streams are freezing entirely, do not appear or are many minutes/hours behind.
I’m going to roll back for now until this is fixed
Has anyone had issues with Google TTS since the update? My automations are making the speakers go “splang”, but not producing any speech.
Getting the same behaviour if I open the device, Browse Media -> Text to speech -> Google and ask it to say something.
Yeah really weird…
I downgraded / restored 2024.1.x (latest) really like five times and updated to 2024.2 again… changed nothing and it’s really happening only on 2024.2
Not really much going on in logs though
Are you also using Frigate for the streams?
No I’m not using that… Look interesting though
This may be worth posting an issue on Home Assistant GitHub Core …
I came across the following:
It’s not so much an issue of the OS, but more related to the database functionnality and if it was decided to implement free-form geometry fencing.
I would say there is a solution for the databases that are used:
The areas can be recorded in a separate table. Circles need to be converted into consecutive segments to do spatial indexing on them as well. Once a spatial index exists, the database engine can do the job of efficiently finding the areas that contain the position.
I thing my issue with rtsp streams has to do something with updated HLS.js package used in frontend.
Issue comes up when updated to 2024.2 but only when new frontend is loaded by notification that there is a new frontend to load… Then page force refreshed by home assistant, and then issue is popping up.
Is there a way to debug hls? 
same here, going to roll back to 2024.1.6 until it gets sorted
I encounter an issue with the modbus integration, where I get the following error:
InvalidStateError: Invalid state with length 285. State max length is 255 characters.
It happens while using the AmtronXtraModbus template from @mfaust78 and I documented more details about the issue here.
Is anyone seeing the same or a similar issue with modbus? I downgraded back to 2024.1.6 and there it works again.
States have always been limited to 255 characters, and as that is a third party template you have raised the issue in the correct place.
Thanks Tom, I am aware of the 255 character limitation, I am using the standard HA modbus integration and I just mentioned the 3rd party template, but that is just a template. Isn’t the modbus integration itself part of HA core? I am copying my config below. It only reads “count: 38” and nothing changed between 2024.1 and 2024.2 in that configuration, so I am wondering what actually changed? Thanks.
My configuration is using the standard HA modbus integration (https://github.com/home-assistant/core/tree/dev/homeassistant/components/modbus):
# https://www.home-assistant.io/integrations/modbus/
- name: Mennekes Amtron Xtra
type: tcp
host: 192.168.12.200
port: 502
timeout: 5
delay: 1
sensors:
- name: "Mennekes Amtron Xtra Registers"
unique_id: f41b022d-c1bd-41d2-a01b-16700c5fde6d
slave: 255
address: 0x0300
scan_interval: 10
input_type: input
count: 38
data_type: custom
structure: ">2h15H22B10H"
- name: "Mennekes Amtron Xtra - Stromlimit Setzen"
unique_id: 6d3696ea-4a91-458c-8b71-6de2906e1a99
slave: 255
address: 0x0400
scan_interval: 10
data_type: uint16
input_type: holding
unit_of_measurement: A
device_class: current
- name: "Mennekes Amtron Xtra - Ladezustand Setzen"
unique_id: e06c40d0-ad10-4197-b41a-7c0f2856f36f
slave: 255
address: 0x0401
scan_interval: 10
data_type: uint16
input_type: holding
Okay, did some more digging and it looks like “count: 38” and the python struct: ">2h15H22B10H" actually leads to 285 Bytes and 2024.1 apparently truncated it or did something else and therefore it wasn’t a problem. 2024.2 now throws an error. I changed it to “count: 31” and structure: ">2h15H22B3H" which still gives me all the template sensor values out of the payload that I need and that now is less than 255 bytes and works fine. Sorry about the noise, but maybe it actually helps someone else as well who runs into similar issues. Thanks!
Does the MQTT breaking change refer to entries in the config yaml file or something else? I only have two mgtt_room entries for espresense in my config so I think I’m OK, but just want to be sure.
Thank you. That was far from obvious.
Which breaking change, there are 3 for MQTT.
Still, i can get devices by only one account, SmartLife or Tuya, not both.
The one that works is the one that i reload last.
Can’t get both to work at same time
was it 2024.2 that broke this icon from showing the correct ‘off’?
show_name: true
show_icon: true
type: button
tap_action:
action: toggle
entity: switch.front_room
it remains the original ‘on’ version, while we set it to change in the domain icons before.
I somehow missed that in the beta. (most likely because I have most of my interface with custom:button-card and dedicated icons there.)
this was ok before though.
update
I now see they lost/dont have the device_class: switch, even though the affected devices are core HomeKit or Shelly switches. how odd, I seem to recall they all had that from the moment of being integrated in the their integrations.
the HomeKit seems to be correct in not using device_class yet. (I moved those from Ikea, where they had it set)
Shelly still makes me wonder if that was the case before.
filed an issue in case the icon migration in 2024.2 just failed on this one.
checkin this a bit more, I see all of the integrations in my config killed the device_class: switch, except Hue and Unifi…?
Same here, I can put them in my language on the phone but they are translated into german on HA. Meaning in order to modify the list from HA I need to know the german names of things 
Who can we ping to check this out?
Hi
don’t know if it’s related to the update but since yesterday, my HA has been “hanging”.
I can no longer connect to it via the web (wan & lan). The container is not stopped, I see the logs continue to scroll but no access.
forced to restart, via portainer.