It’s what I mention earlier as well. Seems socket issue. I use simple TCP.
Same here … cannot reach the server at all
2024.5.4 released - and Traccar server integration still working unreliably.
Works only after HA reboot for a few hours, then stops updating data.
Broken after 2024.5.0.
Issue was registered 
.
The problem is specific to websockets transport, the PR has already been made: Fix setting MQTT socket buffer size with WebsocketWrapper by bdraco · Pull Request #117672 · home-assistant/core · GitHub
I tested it and it solves my issue.
Im seeing constant disconnects for my 2 EM’s
Another gen 1 device is doing the same.
They are still online in the shelly app
It doesnt appear to be an issue with gen2 and 3.
Last logged: 09:48:51
Error setting up entry Shelly EM AC for light
Error setting up entry Shelly EM AC for sensor
Error setting up entry Shelly EM AC for switch
Error setting up entry Shelly EM AC for update
Error setting up entry Shelly EM AC for valve
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 575, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/binary_sensor/__init__.py", line 234, in async_setup_entry
return await component.async_setup_entry(entry)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 185, in async_setup_entry
raise ValueError(
ValueError: Config entry Shelly EM AC (14b43330d70d1594b834e553c7831635) for shelly.binary_sensor has already been setup!
2 Likes
Installed some ubuntu 22.04 updates and rebooted the pi.
Made the update from 2024.5.2 to 2024.5.4.
Running HA in docker.
My bluetooth sensors stopped updating. That’s in the logs:
homeassistant | ESC[33m2024-05-19 21:50:30.018 WARNING (Recorder) [homeassistant.components.recorder.util] Ended unfinished session (id=1426 from 2024-05-19 19:49:13)ESC[0m
homeassistant | ESC[31m2024-05-19 21:50:34.239 ERROR (MainThread) [homeassistant] Error doing job: Future exception was never retrieved
homeassistant | Traceback (most recent call last):
homeassistant | File "/usr/local/lib/python3.12/site-packages/bluetooth_adapters/dbus.py", line 154, in _get_dbus_managed_objects
homeassistant | reply = await bus.call(msg)
homeassistant | ^^^^^^^^^^^^^^^^^^^
homeassistant | File "/usr/local/lib/python3.12/site-packages/dbus_fast/aio/message_bus.py", line 384, in call
homeassistant | await future
homeassistant | File "src/dbus_fast/aio/message_reader.py", line 19, in dbus_fast.aio.message_reader._message_reader
homeassistant | File "src/dbus_fast/_private/unmarshaller.py", line 777, in dbus_fast._private.unmarshaller.Unmarshaller._unmarshall
homeassistant | File "src/dbus_fast/_private/unmarshaller.py", line 638, in dbus_fast._private.unmarshaller.Unmarshaller._read_header
homeassistant | File "src/dbus_fast/_private/unmarshaller.py", line 376, in dbus_fast._private.unmarshaller.Unmarshaller._read_to_pos
homeassistant | File "src/dbus_fast/_private/unmarshaller.py", line 339, in dbus_fast._private.unmarshaller.Unmarshaller._read_sock_without_fds
homeassistant | EOFErrorESC[0m
Please open a github issue and provide a full log with screen shots of the Bluetooth config entry.
Yes 5.2 or 5.3 fixed the issue. However i need to rewrite all my automation because the old one does not work. I forgot what the old one is base off, but the new update all the Pico button events is base off an unique ID “uuid”. You can use event listen to get each pico remote button ID. Below is one of my remote example.
alias: Remote - Lutron Pico Family
description: ""
trigger:
- platform: event
event_type: "lutron_event "
event_data:
uuid: "1418"
id: Button 1
- platform: event
event_type: "lutron_event "
event_data:
uuid: "1421"
id: Button 2
- platform: event
event_type: "lutron_event "
event_data:
uuid: "1424"
id: Button 3
- platform: event
event_type: "lutron_event "
event_data:
uuid: "1427"
id: Button 4
condition: []
action:
- choose:
- conditions:
- condition: trigger
id:
- Button 1
sequence:
- service: light.toggle
metadata: {}
data: {}
target:
entity_id: light.kitchen_common
- conditions:
- condition: trigger
id:
- Button 2
sequence:
- service: light.toggle
metadata: {}
data: {}
target:
entity_id: light.dimmable_kitchenbar
- conditions:
- condition: trigger
id:
- Button 3
sequence:
- service: light.toggle
metadata: {}
data: {}
target:
entity_id: light.family_room_common
- conditions:
- condition: trigger
id:
- Button 4
sequence:
- service: light.toggle
metadata: {}
data: {}
target:
entity_id: light.back_yard_backyard
mode: single
Thanks! This doesn’t seem right that all of a sudden we have to go from event_data id triggers as documented in the Lutron integration doc page to event_data uuid. Perhaps a bug?
@jztan79 Thanks for the suggestion to use the event listen.
I think what’s happened is that event full_id seems to have been renamed for Picos. Instead of the name I give the Pico in the Lutron editor (which was always the behavior), it now uses the Room Name (e.g. room_off, room_on). This is problematic because it means the event full name is the same for multiple picos in the same room.
This has to be a change or possibly bug recently introduced.
Same issue on 2024.5.4 with MQTT. had to roll back to 2024.5.3
When is Home Assistant devs going to give Home Assistant Yellow users the ability to make use of their 3.5mm audio jacks with built in “High Quality Audio DAC”?
I would have thought that the HA Yellow image from Raspberry Pi imager would have included the necessary drivers for the 3.5mm Jack to show up natively under “media devices” as something like “HA Local” or something like that but we don’t have anything. So that port is just an ornament at the moment
That seems unrelated to the 2024.5 release.
But anyway, according to the entry in the Yellow FAQ the 3.5mm jack should work with the VLC addon.
If that does not work I would suggest to open a separate thread or contact support (listed at the bottom fo the faq page)
1 Like
Install squeezelite.
Hi Alex,
I checked again and indeed in MQTT integration, it was websocket, not TCP as mentionned.
so aligned with you 
1 Like
Hi great work all the releases!
In 2024.5.4 I observed services media_player.media_play / media_player.media_pause / media_player.media_pla_pause for a Sonos 5 via the Sonos integreation did not work for me.
After downgrading (ha core update --version 2024.5.3) to 2024.5.3 these services were functional again.
Had anybody else similar observations?
Hello
What do you think about a couple of month of debug instead of improvement?
I mean to try to stop improvement/update and focus on debug all the bugs/errors that we have.
This only for July and Augyst maybe.
Maybe by introduction a temporary special button to send the errors, LOGs and details to the correct page on Github (or forum).
I think that could be improve the stabiity, efficiency and velocity of the entire HA system.
Like a waypoint in the videogames.
Thanks
8 Likes
I’m still on .4 April release, is there any way to find out if an integration uses something like ipmi used to do (“integration ‘ipmi’ calls async_dispatcher_send from a thread”), BEFORE updating to the may release?