system
June 11, 2025, 8:01pm
1
12 Likes
a_d
June 11, 2025, 8:05pm
2
recorder.get_statistics: Wohoo, no more manual digging through the database to get some (anyway already calculated) mean values for jumpy sensors. Thanks!
4 Likes
Nice release, thank you everyone
Will ot be optional to bind the sidebar layout to the user rather than the device?
Would be nice if we could chose what to bind the sidebar to. Seemed more elegant on a device rather than user basis.
15 Likes
Hedda
June 11, 2025, 8:39pm
4
Please also consider reusing that network visualization component/code to make the UI for connection graphs / network maps consistant between Bluetooth, Zigbee, Z-Wave, and Thread (Matter).
Would in addition be great if areas (i.e. rooms) could be represented in the network visualization graphs, so that devices that are tagged as being in the same area (i.e. room) show up grouped together in the connection graph / network map.
I think that having areas in all the network visualization graphs could further help troubleshooting connections, especially for IoT protocols that uses mesh networking with routers/repeaters.
On a side-note I would love if future designs of all of Home Assistant Voice devices could also have Thread radio in them too so they could optionally be used like a Thread Border Router:
opened 02:57PM - 21 Jan 25 UTC
For the next-generation voice satellite board design/schematics please consider … also adding another ESP32 SoC to the same PCB board as well as code support for that secondary ESP32 SoC to in the future be used as a Touchscreen Display Controller and/or Thread Border Router. Specifically suggest adding an [ESP32-C6](https://www.espressif.com/en/products/socs/esp32-c6) as a second radio SoC to the same so PCB and make that secondary act as a "co-processor" and "IEEE 802.15.4 radio" module.
**UPDATE:** FYI, ESPHome has a new "Packet Transport Component" component to allow for communications between different ESP32 chips if they are both/all running ESPHome, see -> https://esphome.io/components/packet_transport/
The two main real-world use cases I see justify adding an ESP32-C6 SoC as coprocessor and radio module are primarily two-fold:
1. Perhaps more interestingly, the ESP32-C6 has a built-in IEEE 802.15.4 radio which means it can be used as a "Thread Border Router" (with OpenThread Border Router RCP firmware), to enable a Thread network and another entry point that can be used by Matter standard fabric. So if add this and could get it working as a TBR/OTBR then it would be super easy for users to add multiple Thread Border Routers to their network.
* https://www.home-assistant.io/integrations/thread/
* https://www.home-assistant.io/integrations/matter/
This the reason why smart speakers from both Apple and Google have for a long time had Thread radio built-in to be future-proof.
2. That ESP32-C6 could be used as a display/controller (or offload some other related things to free up resources and make it more future-proof).
Regardless if having an integrated "Thread Border Router" would be the most practical new feature or not in the long-run. For the short-term I personally believe that the coolness of having a alternative model variant of Home Assistant voice satellite is the coolest fearute that woulc attract the most new users and developers, as having at least one early model with a a relativly large touchscreen should attract interest for even those users and developers who are not interested in voice.
As such having the suggested secondary ESP32 on the same board should in theory allow support for a capacitive touchscreen display with a local UI without sacrificing resources on the primary ESP32. It would at least be awesome to have a variant of a Home Assistant Voice Satellite with a large touchscreen display (.i.e. something similar in design to the existing Google Nest Hub / Google Home Hub and the Amazon Echo Show products).
* Check out for example this 7-inch series of capacitive touchscreen displays from Elecrow with display driver for embedded ESP32 (which actually do have a microphone so could potentially be used as-is for development) -> https://www.cnx-software.com/2025/01/17/crowpanel-advance-esp32-s3-displays-with-replaceable-wifi-6-thread-zigbee-lora-and-2-4ghz-wireless-modules/
(ex. CrowPanel Advance 5-inch/7-inch touchscreen use a SC7277 Display Driver and has presoldered ESP32-S3 + extra ESP32 slot -> https://www.elecrow.com/pub/wiki/1_Introduction_to_CrowPanel-Advance-HMI_Screen.html ):
One downside of adding an extra ESP32 (ESP32-C6 or ESP32-H2) it obviously that it would take up some additional space on the PCB and complitate FCC certification a little because of it now having multiple radios, however I do not believe it would add that much larger BOM cost, but the additional possibilities such an extra ESP32 SoC could add should hopefully more than make-up for that slightly higher cost(?).
While I think that it having "Thread Border Router" will be of most interest to many users in the future, and alternativly use case for ESP32-C6 could be to instead use it as a remote Zigbee Coordinator (also known as a Serial-over-IP Zigbee controller adapter) for [Home Assistant's built-in ZHA integration (native Zigbee Gateway)](https://www.home-assistant.io/integrations/zha), see/follow this work-in-progress but note that the ESP Zigbee radio for zigpy is is still very experimental and not yet fully working with ZHA:
* https://github.com/lhespress/zigpy-espzb
* https://github.com/zigpy/zigpy-cli/pull/45
* https://github.com/zigpy/zigpy/issues/1052
And yet another option could of course be to also use the ESP32-C6 as a "coprocessor" module a a dedicated Bluetooth Proxy chip with ESPHome:
* https://esphome.io/components/bluetooth_proxy.html
Note that the reason main you want to combine ESP32-S3 and ESP32-C6 is not only to off-load those processes but more importantly so you separate Wi-Fi signals from Thread/Zigbee signals, and that is due to WiFi tendacy to overwhelm and interfer with Thread/Zigbee communication because how they both work. Same goes by the way for WiFi and Bluetooth Low Entergy but it usually is not a great impact on user experience as for Thread/Zigbee:
* https://www.home-assistant.io/integrations/zha#zigbee-interference-avoidance-and-network-rangecoverage-optimization
* https://www.home-assistant.io/integrations/bluetooth#bluetooth-interference-with-other-devices
Anyway, what I think what would make a products like Home Assistant voice satellites perfect as a "Thread Border Router" is that a user can add multiple Thread Border Routers (TBR/OTBR) to their Thread/Matter network for redundacy (using fail-over) and having multiple voice assistant hardware apöliances around thier home is something that many Home Assistant users are likely to have many of and placed all over their home, so having many Thread Border Routers is one of the keys to getting a more robust Thread network.
* https://www.home-assistant.io/integrations/thread/#about-thread-border-routers
_Image taken from [the Thread Smart Home Fact Sheet](https://www.threadgroup.org/support#Resources) by the Thread Group. It illustrates the landscape of Matter, Thread, and Border routers. Instead of Matter, you could also see another protocol here, such as HomeKit._
_Unlike other IoT protocols, Thread can use multiple border routers in a single network. This increases wireless coverage and reduces the risk of a single point of failure. Ideal for home automation, with a potentially large number of devices spread over a large area._
Slightly different image here on the threadgroup.org when they describe a Thread based Matter fabric using similar text, again including mentioning that _Thread Border Router can be built int many devices such as access points, **smart speakers**, etc._:
* https://www.threadgroup.org/BUILT-FOR-IOT/Smart-Home
Also check out this blog which better describe what a Thread Border Router actually is and why it is very good to have many:
* https://www.threadgroup.org/news-events/blog/ID/356/WHAT-IS-A-THREAD-BORDER-ROUTER-AND-HOW-IS-IT-DIFFERENT-FROM-A-HUB-OR-BRIDGE
As proof-of-concept for the idea of using a ESP32-S3 + ESP32-H2 combination board made for this purpose check out the "**_ESP Thread Border Router_**" board which is an official Espressif official SDK reference hardware for this purpose (can that use used as either Thread Border Router or as a remote Zigbee Coordinator):
* https://openthread.io/guides/border-router/espressif-esp32
* https://www.sparkfun.com/products/25497
Not tested myself but suposedly you can already get those working with Home Assistant's Thread integration:
* https://www.youtube.com/watch?v=nHH7j--lfDo
* https://github.com/home-assistant-libs/python-otbr-api/issues/61
Development is primarily being done with Espressif's ESP Thread Border Router SDK hardware (based on ESP32-H2-MINI-1 module):
- https://docs.espressif.com/projects/esp-thread-br/en/latest/
- https://github.com/espressif/esp-zigbee-sdk/tree/main/examples/esp_zigbee_gateway
- https://github.com/espressif/esp-thread-br
- https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br
- https://openthread.io/guides/border-router/espressif-esp32
OpenThread Border Router Example as in a similar two-SoC setup combining both a ESP32-S3 and ESP32-H2 in the same solution:
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br
PS: From a marketing point of view it would also allow you to add Thread's Thread Border Router icons on each product box too:
* https://csa-iot.org/wp-content/uploads/2023/08/Matter-Retail-Education-Presenation.pdf
12 Likes
00uzwz961
June 11, 2025, 8:41pm
5
That sounds awesome, it would mean my problem with iBeacons can be fixed without HACS? iBeacon distance to which (multiple) Bluetooth Proxy? - #2 by gregrs
Where are the Bluetooth maps found in the UI?
1 Like
Wilber
June 11, 2025, 8:50pm
7
Go to Integrations, Bluetooth, Configure, then it’s in the second box down. (Took me a while to find it!)
2 Likes
00uzwz961
June 11, 2025, 9:12pm
8
And restart the mobile app.
tom_l
June 11, 2025, 9:22pm
9
Create a user for each device you want a different layout on.
Townsmcp
June 11, 2025, 9:24pm
10
If you rely on calendar entries to start/stop triggers in automations, be mindful that functionality is broken. See CalDav calendar trigger doesn't work anymore · Issue #145886 · home-assistant/core · GitHub
5 Likes
Nice, I can finally hide some items in Sidebar for good!
1 Like
sdaltons
June 11, 2025, 10:27pm
12
Sorry but can someone please explain to me like I’m 5 how to generate the OTP for the new Amazon devices integration?
Edit: nevermind, was still using SMS lol
1 Like
0kk0
June 11, 2025, 11:24pm
13
zala143
June 12, 2025, 12:32am
14
love the release - great work. regarding the very cool network visualization maps, any way to change the colors - the blue and green shades are too close for my eyes at quick glance - would like to pick more contrasting colors. cheers - always appreciate the work from the team!!!
1 Like
Oh, why is it available in app only??? And why it is not made clear in doco?
Any one else have their Lovelace sub-views go empty after updating? I use them heavily and after updating earlier today I noticed all of them were empty (had to refresh the page to notice). I restored from backup, then copied the entire lovelace raw configuration code and decided to upgrade again. After the second time I noticed the same thing, all the sub-views are empty. I went into the raw code editor and the code is all there, every line.
I’m currently restoring from backup again. Only sub-views were impacted, all other views were fine.
1 Like
tom_l
June 12, 2025, 1:38am
18
It is not only available in the app. I can see it on my desktop.
1 Like
dwalme
June 12, 2025, 1:43am
19
Bluetooth is broken in this release. At first HA could not find my bluetooth adapter. Rebooted, adapter there and loaded, but none of my devices would show up.
Didn’t have time to mess around so I restored 2025.5.3 and everything works again.
FYI to anyone else that relies on Bluetooth. Make sure you backup before updating.
How is the new Alexa Devices integration different from the Alexa Media Player integration?
1 Like
