2026.8: Approachable by design

[tom_l]

@rmaeder

Now I add it to the device pulse integration, which just adds a single sensor ‘ping’ so I know when the device goes offline

Just use the status binary sensor in your ESPHome configuration.

Status Binary Sensor

It does the same thing and will be part of the device.

[MandM78 (Greg)]

The 2026.8.0 update spiked my CPU (i3). Glances told me after the update that the homeassistant container was running 200-215% of CPU. (I went from about 9-10% general CPU use to 65-70%.)

I rebooted the host. I let it “stabilize” for 15-20 minutes. Nothing changed. Rolled back to 2026.7.4. CPU usage back to normal.

[dumbdevice]

@rmaeder

The device listing now has two identical copies of that ESPHome device, with the same name!

I have the same two identical copies for LVA entities and borked related automations. Had to manually remove the copies and fix automations..

[smithbill17 (Bill)]

I use AdGuard Home as the DNS on my LAN with my OpenWRT router as the DHCP. Previously I used to get a lot of reverse lookups from Home Assistant in my AdGuard Home logs, so I had added the ‘default_config_disabler’ integration to disable ‘dhcp’ within Home Assistant. However, after upgrading to 2026.8.0 (which made some changes to the config within configuration.yaml & moved it into the Network UI) I’m now seeing AdGuard Home being flooded with reverse lookups again of the form x.x.168.192.in-addr.arpa

How do I stop all these reverse lookups from HA 2026.8.0 with minimal changes?

[rmaeder (Roman Mäder)]

thanks for the pointer. But I have lots of random Wifi devices that I want to check with ping, not just for ESP (some Shellies, various media players).

[Spamfast]

I see ‘configurable from the UI’ means ‘no longer configurable from YAML’ again.

Hey ho.

Anyway, the OpenWrt (luci) integration imported my router settings from configuration.yaml but failed to import all the carefully constructed device tracker entity IDs, icons & friendly names from known_devices.yaml. So yet another round of clicking my way through the UI a thousand times to sort them out.

The only upside is that they’re now uniquely IDed so can be assigned to areas.

I have to say, when I first read the headline I thought it said ‘2026.8: Apocalypse by design’.

Not quite that bad but once again the amount of rote work for existing users with complex setups hasn’t been considered.

[AndyBrad (Andy)]

locked me out of settings menu now!

[karwosts]

Looks like maybe the state class of that entity changed from total to measurement?

[thislooksfun]

If there is something you would like to see, we would love for you to weigh in.

Yes! Please allow us to put combination logic in automation triggers! Doing something simple like “turn off the bathroom fan when the humidity is low and the room is unoccupied” either requires adding two triggers (“humidity low” and “bathroom unoccupied”) and then repeating those again in the “if” block to make it only happen when both are true, or adding a custom helper entity to combine the states into a boolean and then having the automation trigger on that. Neither of those options are super beginner friendly, and it adds just enough friction to making automations that I often put it off.

Here is a link to the GH discussion about this: Trigger automation when any referenced entity changes · home-assistant · Discussion #439 · GitHub

[sondreen]

What was the rationale about this change? I want the exact opposite of this and detest this change.

[monsieurlatte]

yeah you shared the 7.2 reference, however I now see why I was confused, here’s the notes that I had been reading on HA. It says 7.1 not 7.2. Full changelog for Home Assistant 2026.8 - Home Assistant

[tototo23 (Auré)]

Great job!

There is something i dont really understand about Google Health integration. For what I understood, Google Health Connect works locally on the phone, and local apps can communicate with this “hub” to read/write data, but it doesn’t go to Google Cloud… Right?

For now i’m using the Home Assistant Android app to send my Google Health data to my Home Assistant (including weight, kcal burnt, …) but i miss the kcal income from nutrition sensor. So I hoped this new integration, which has this sensor, would help, but it says there is no Google Health data on the cloud… So I dont understand what i’m missing…

[Schildi]

Also a big dislike from my side for the separation of devices into integration. What I really liked from the very first second (and what gave me a “wow” moment) was when I had a ESP-Home Device and added my fritzbox later and directly I could see in the devices overview, the network state and that I can now switch off internet access for that device.
I am now thinking about beeing busy, trying to build Dashboards for devices, just to rebuild this previous functionality.

I think the “Device First” instead of the “integration first” apporach was a good idea, also for beginner like me back than. I want an overview page, where alle possible entities of a device are shown, irrelevant which integration was needed to achive this information.

@finity

@finity

I really dislike that every entity even slightly related to a device that is created by a different integration is listed in every device integration page with no indication of which integration created them.

here is an example of a zigbee button:

if I click into the ZHA integration for the device it shows correctly that the ZHA integration only provides three entities.

I totally got your point and I am also on your side, that it really bothers to identify the responsible integration. But I think the current separation is more a work around than a solution to the issue.

Please correct me if I am wrong: The single elemtes in an device are called entities, and each entity consists of a name, which can be non-unique, and an entity-ID which must be unique.

So what about this instead:
If HA detects, that a device gets a second integration feeding an entity, lets say sensor.device.batterylevel
It creates two new entites with, each with a prefix in the entity id, identifying the integration providing the information. So for example ending up with the exampled from @finity:

• sensor.device.batterylevel
• sensor.device.batterylevel.zha
• sensor.device.batterylevel.battery_info

Whereas the sensor.device.batterylevel holds the “last-wins” value.
And then also make it possible to show the entity-id name also in the Device info page under ( at least these) entities.

I think this would really beginner friendly, as I assume, 90% of the people just want to have the battery level and don’t care too much how it was mined.
Maybe add a featuer/field (or how it is called) to make it traceable, which integration last updated that main sensor.device.batterylevel , like it is stored who or what triggered a script.

These are my 2 Cents, if I got anything wrong, please correct me, I am still in the beginning of HA.

[paulmro]

Please don’t transform Home Assistant into Apple slop.
Leave it somehow technical to use (but doable if you really want to) .
I used to have supervisor and running great and I have absolutely no codding knowledge but by shear will made it to work with tons of complex scripts and automations , all done in yaml

The joy and satisfaction when I got something running (finally) was all I needed to keep going

Now with every release I lose something that I managed to get it right the way I needed it after countless hours of finding solution on forums and documentation.

[Spamfast]

There are now two Google ‘apps’. Google Health is basically the rebranded (and much improved) Fitbit app. Google Health Connect is a local database with an API that allows different fitness/health apps to share information.

I’m unsure as to what the new Google Health integration and the Google API to which it connects is using.

BTW, the Home Assistant companion app can already be given access to the Health Connect API in its permissions exposing a bunch of sensors.

[Linwood (Linwood Ferguson)]

This is the first one in a long time I’m terrified to install. Moving critical stuff like web server address and ports out of yaml into the UI means, of course, if something there goes bad and you can’t get into the UI you can’t fix it. Or so it seems.

WHY do you think making things accessible by allowing UI setup means you have to take it out of YAML, which is very “accessible” when things go wrong.

Automations are (I hope still) a great example – I can edit in UI, but they are saved in YAML.

Critical, startup related configuration information should be there also!

Sorry, but I do not trust programmers (any programmers) to think of all the failure mode and try to automate it as an alternative to direct access to the setting when things will not start.

About to start arranging a backup copy I can run and see what happens, but now every update, every change I make related to web pages, I will be terrified of being locked out.

Not good. I don’t care if it works perfectly this month… as a philosophy, not good.

Edit/addition: OK, I snapshotted my system and upgraded and the network changes apparently come only with specific action. I’m pleasantly surprised so far things are working.

[zweckj (Josef)]

It still lives in a config file for your emergency cases, just a different one. It’s in config/.storage/http now.

[shgadget]

Roborock Q10 has a map image!
Nice to finally tidy my dashboard.

Minor issue though, it’s a mirror image

[smithbill17 (Bill)]

I cannot now stop Home Assistant 2026.8.0 spamming my AdGuard Home logs with reverse lookups of the form x.x.168.192.in-addr.arpa

I’ve tried all the various suggestions in Google, but since the 2026.8.0 update, the 'default_config_disabler’ integration I used to use to disable ‘dhcp’ within Home Assistant, doesn’t seem to work.

Anyone got a solution to stop HA 2026.8.0 spamming my AdGuard Home with reverse lookups?

[Antasp3136]

Maybe I’m going to check when I get a test instance spun up.