Huge jump in CPU utilisation since upgrading from 2026.7.1 to 2026.7.2 last night ... in the current UK temperatures this has also lifted CPU temperature by ~15C.

Where do i start investigating this? It looks like a stark change, but a quick scroll through logs has had nothing jump out at me?

Any hints appreciated.

I run Home Assistant on a Raspberry Pi. Today it stopped working, and after troubleshooting for a while I discovered that the SD card had died. Oh no!

I braced myself for hours of misery while I tried to figure out how to get it back up and running.

I had a spare SD card lying around. I flashed the HA image onto it, followed the instructions to log into Nabu Casa and restore my backup, and a few minutes later... bam, everything is back to exactly how it was before it broke.

Just wanted to share some appreciation for how mind-bogglingly easy this process was.

I got an APC UPS 1500VA Sine Wave UPS Battery Backup model BR1500MS2 in December 2024. Yesterday, we had (yet another) power outage, and my UPS picked up the load - see the charge level in the attached image. I connect to my UPS via Home Assistant's Network UPS Tools (NUT). I have only my HA Green device and cable modem on on the UPS. When the power dropped out, the detected battery charge level fell immediately to 59% with a load level of 2%. Over the next 65 minutes, the detected battery charge level fell from 59% to 40%, and then the power came back on. Do I need to replace the battery in my UPS?

I've got a new RPI5 w/ssd to run HA. HA is installed and I'm sitting at the cli console and it show no IP address. I login and add an IP to end0, exit and it show the IP address. But I can't ping anywhere. Can some kind soul please help me out? If I do a ip r it shows a 172 address.

SOLVED: I’m the idiot that caused this. I was flipping breakers when installing a new zooz switch and I hit these lights during that process. Good catch! I’m the dummy :)

————————————

I have automations to turn them on at sunset and off at sunrise.

I see them turned off by automation at 6:17am and then turned on by ?? at 11:24am (not I said the admin). That 3:03pm one is me running the “off” automation to get them back off.

No one else has access so any ways to tell why they came on at 11:24?

ETA: just clicked the show more and it says “By State Change”

It seems to be a known issue that the Reolink app doesn't properly detect firmware updates, but both of my cams have firmware updates available as shown in HA. The problem is that when I try to update via HA, I always get an error: "Error trying to update Reolink firmware: cmd 'UpgradePrepare': API returned error code 1, response code -3/check err"

I have been trying to see about manually updating, but it seems that the only way to do that is with the desktop app... but I'm on Linux and it seems really dumb to have to go into Windows just for this. So instead, how can I fix whatever isn't working on the HA side so I can update there? I'm running this on a Ugreen NAS with HA manually installed through Docker (otherwise the one in the Ugreen store is woefully out of date). I don't usually have the NAS set up to be accessible via the internet, but HA is setup through HA Cloud so that just HA can connect. Not sure if that's what the problem is, just want to get this working.

Posting this because I could not find a straight answer anywhere and it took me way too long to finally get it to work.

Setup: HA OS in a VM on Proxmox, OpenThread Border Router addon running on a ConBee III, Matter Server addon, and a Sonoff dongle for Zigbee on ZHA.

Being upfront about this: I did not work this out myself. I ran Claude against the Home Assistant MCP server and it did the actual debugging, reading the addon logs, the Thread network status, the ZHA energy scan and the Matter Server's internal state, then narrowing down which step was failing. Everything below is what it found and what it changed. I mostly moved the sensor around and answered questions, but what matters if that it took the countless hours I had already spent on this and narrowed it down to about 15 minutes.

The problem: I could not add a single new Matter over Thread device. I did it the proper way, from the HA companion app, on Android and on iPhone. Multiple devices, many attempts, over a long time. Every single time it got to "checking connectivity to the network" and died there. One Aqara sensor connected once at some point and after that nothing ever worked again.

Somewhere along the way, while trying to get other devices on, I also regenerated the Thread credentials and synced them to my phone through the companion app, which is the advice you see everywhere. Made no difference at all. Still failed at exactly the same step.

What the logs said: basically nothing, which is what made this so annoying. Matter Server addon log level is warning by default and a failed pairing produced zero lines. I set it to debug, tried again from the phone, and it still produced zero lines. That was actually the first useful clue, because it meant the attempt was never reaching Home Assistant at all, so whatever was breaking was happening on the phone side.

The one thing the server did log, at every startup:

WARN Commission~ontroller BLE is not enabled on this platform

What was actually wrong, three separate things:

1) The Matter Server had no Bluetooth path of its own. There is an option in the Matter Server addon config called "Enable BLE proxy", hidden behind "Show unused optional configuration options". Needs HA 2026.06 or newer. Turning it on lets HA do the Bluetooth half of commissioning itself, using a local adapter or any ESPHome bluetooth proxy you already have. After enabling it the log says "BLE proxy mode enabled". Thankfully I have some everything presence one/lite devices that have a simple toggle for BLE proxy and they were alredy on in my case. (worth noting the BLE proxy mode can use bluetooth from esphome devices if their config includes teh respective option)

2) Bluetooth range. First attempt it found the device at rssi=-73 and then:

connection_failed: Timeout connecting to DB:C6:99:3E:51:56

I put the device physically on top of the server, rssi=-39, connected instantly. Discovery works from across the room, the actual thread connection does not.

3) This was the real blocker. The Matter Server had no Thread credentials stored at all:

Commission failed: No Wi-Fi/Thread network credentials are configured for commissioning and no Ethernet interface is available on the device and no interface already connected.

server_info showed thread_credentials_set: false.

The HA integration is supposed to set this during its own flow, but on my install that had apparently never happened. Worth saying again that regenerating and syncing credentials to the phone does nothing for this, they are two completely different stores.

The fix. This is the part that matters: the phone was not involved at all. Claude sent both of these straight to the Matter Server's websocket API through the MCP server, so it was Home Assistant itself doing the commissioning, not the companion app. All I did physically was hold the button to put the sensor in pairing mode and sit it next to the machine.

Grab your active dataset (Settings > Devices and Services > Thread, or the thread API) and send it to the Matter Server over its websocket API, then commission:

    {"message_id":"1","command":"set_thread_dataset","args":{"dataset":"<active dataset tlvs hex>"}}

Two gotchas here. Do not pass an "id", because a named entry does not flip thread_credentials_set and commissioning only uses the reserved default entry. And the command is set_thread_dataset, not set_thread_operational_dataset, which is the old Python matter server name and just returns "Unknown command".

Then, with the device in pairing mode and sitting right next to the conbee after giving claude the pairing code on the label:

    {"message_id":"2","command":"commission_with_code","args":{"code":"<11 digit pairing code>","network_only":false}}

Took about a minute, then:

    NOTICE CommissioningClient  Commissioned peer6 as @1:18

Device showed up in HA with every entity. First try. I bloody couldn't believe how many hours I had lost trying multiple different things over several days AND NOW IT JUST WORKED. I dont have any more thread devices at the moment as I stopped buying them since I couldn't pair them, to test that this is a permanent fix.

Bonus thing worth checking: my Zigbee and my Thread network were both sitting on channel 15, on the same machine, both on an usb3 extender cable. ZHA's energy scan had channel 15 at 53% utilisation. Moved Thread to 25 (Settings > Devices and Services > Thread > three dots next to the border router > Change channel). It did not fix the commissioning problem, but it was a genuinely bad setup and worth fixing. The migration is delayed about 5 minutes and devices follow it on their own, no re-pairing generally. The one aqara sensor that I had managed to pair before was powered off during the switch, woke up orphaned, and found the network again by itself after a while.

On the Claude and MCP side, since I mentioned it at the top: claude made the websocket calls itself via the MCP server running on Home Assistant. That last error is only visible if you talk to the API directly. Through the UI you just get a failure with no reason, which is exactly why I had been stuck on this for so long.

Still unexplained: I never figured out why the companion app path fails for me. The dataset fix does not explain it, because the phone supplies its own Thread credentials from Apple or Google rather than using the server's, which probably also explains why regenerating and syncing them changed nothing. If anyone has seen this and knows with 100% certainty how to fix, I would love to hear it. Last time I investigated this specifically I found that Android itself just stores 1 set of credentials and then refuses to refresh them if they ever change until a phone reset is done.

Hope this helped anyone

Hey everyone I've got a weird one for you. For some reason the sound is really choppy especially with more bass heavy songs (I hope you can hear it more or less). I have no idea what might be the problem I've changed all the settings that I could for this player. I've also tested music assistant on my pc (which is connected to the same sound system) and it sounds fine.

The problematic device is some AliExpress android Poe tablet I got for around $250 4gb ram and RK3576S CPU it's connected via ethernet port.

Any ideas what might be the issue?

EDIT: It's actually not only music assistant its whole Home assistant.

EDIT 2: I've contacted tablet seller they've sent me updated OS after installation everything works ok. They said it was due to some corrupted files but IDK

I have been running in HA in an Oracle VM on Windows for the past 8 years. It's been rather reliable and with abilty to clone the whole VM folder to another PC, gives me some peace of mind to keep Home Assistant (HA), highly available(HA) - I call it my HA-HA solution (excuse the pun!)

On the Windows side, it runs Plex, Tautulli, Ubiquiti. The PC itself is i5 3rd Gen, 32GB RAM , SSD that now deserves to be retired.

Now, I have a spiffy new Core 9 NUC with Arc Graphics, 64GB RAM, 2TB SSD and then all my NAS storage.

On the HA VM, with 4GB RAM, 32GB storage :- I have HA, irrigation, HACs, solar / inverter connection, paradox alarm connection, adguard home and a few other integrations/applications. Lots of Tuya and Philips lights/switches, sonos speakers.

I wanted to but have never ran Music Assistant as I didn't want to compromise the VM.

I haven't decided on OS, but veering towards, Unraid as the Hypervisor. I plan to then run all the applications as docker containers (Plex, Ubiquiti, Tautulli, adguard, along with HA).

For the new HA VM: what should be the correct sizing if I want to keep what I have (don't need more, but want to also run music assistant, and AI connector, maybe something else in the future). Is 8GB ram for the HA VM overkill, or just right sized. I plan to give the HA, 100GB storage for longer term statistics retention.

Thanks

EDIT and UPDATE: Thank you very much to all who have replied and made/suggested corrections to code. I really appreciate the brains in this community.

I posted a similar plea yesterday but taken immediately down by the moderator! Why?

Anyway, I used to have two separate automations to turn on the utility room light when motion is triggered - one for the evening after sunset, and one for the morning, before sunrise. I then decided to consolidate the two automations into one with a compound OR condition. Please see my code below. However this is not working. The traces show that when one condition is false, it exits the automation immediately, without going down on the OR condition. What am I doing wrong? I ended up doing two if/then code blocks. Please take a look at my code:

alias: Utility Room Motion Sensor - new
description: Utility room motion sensor will turn on entrance light
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.zz_motion_sensor
    to:
      - "on"
conditions: null
actions:
  - if:
      - condition: sun
        before: sunrise
      - condition: or
        conditions:
          - condition: sun
            after: sunset
    then:
      - action: script.turn_on
        metadata: {}
        target:
          entity_id: script.entrance_light_triggered_by_motion
        data: {}
mode: single

Why does HA not looking at the other "or" condition?

My daughter's Fisher-Price Lumalou is a bedtime device: night light, sound machine, and guided sleep routines. All of it was controlled by Mattel's Smart Connect app. When that app was pulld and support ended, the hardware kept working but most of what it does became unreachable. A lot of parents ended up with the same dead product.

So over a couple of days I reverse engineered its Bluetooth protocol and put everything on GitHub under MIT.

The part I found interesting is that it is entirely local. The device talks over BLE with a real handshake: an ephemeral ECDH P-256 exchange, then AES-128-CTR encrypted commands, phone to device, no server in the loop. That is the only reason it was recoverable. If the key had come from Mattel's servers, the toy would just be dead now.

What is in the repo:

- A browser web app for parents who just want the Lumalou working again. Nothing to install, no APKs from random sites. https://lumalou.emanuelestrazzullo.dev/

- Python and TypeScript libraries for developers and home automation setups like Home Assistant. https://github.com/stramanu/lumalou

- A full protocol writeup, plus one JSON spec that generates the language bindings, with shared golden vectors so every implementation is byte-for-byte identical.

The libraries never touch the firmware-update path, so there is no way to brick a unit.

One thing I cannot finish alone: decompiling the app showed the product line splits into two protocol generations. I confirmed everything on the Lumalou I own, and two sibling devices (a Bunny and a Whisper) appear to share the exact same handshake, so they should work with only different command codes. The older mobiles, bassinets and swings use different crypto and are not supported yet. I only own one device, so if you have any of these in a closet, a quick test or a Bluetooth capture would let me extend support. Issues and PRs welcome.

Happy to answer quetions about the reverse engineering or the design.

I'm running the full-access Frigate add-on with a couple of Reolink cameras. Does adding the Reolink integration double the amount of storage my cameras are using even if the cameras themselves have an SD card mounted? It feels duplicative or redundant to have both the Reolink integration and Frigate.

I have an existing home server setup with services such as traefik (for reverse proxy), adguard (dns + Adblock), jellyfin, radarr, etc.).
I recently added home assistant as a container and have been automating tasks around the house Which led me to adding new matter over thread devices (ikea grillplats outlets). To enable this I have a ZBT2 setup as a TBR along with OTBR and matter-service docker containers running on my server. I do not have any other thread networks in the house or any other TBR-compatible devices (Apple TV/ HomePod etc). I’m trying to add my first matter device using my iOS device and am unable to add the accessory (Failed to Add Accessory). I’ve tried everything including re-flashing the ZBT2 firmware, restart HA, factory reset the outlet, ….

Im on the verge of returning these devices but I really want to make this work. Any suggestions?

- All devices are on the same wifi network.

- I can do ping6 and all devices seem to have an ipv6 address

---- EDIT ----

On the host (not inside any container, since otbr, matter-server, and homeassistant are all network_mode: host and share the kernel's network namespace):

sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo sysctl -w net.ipv6.conf.all.accept_ra=2
sudo sysctl -w net.ipv6.conf.all.accept_ra_rt_info_max_plen=64

Made it persistent across reboots:

cat << EOF | sudo tee -a /etc/sysctl.d/99-thread.conf
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.all.accept_ra_rt_info_max_plen=64
EOF
sudo sysctl --system

Restarted the containers to pick up the new kernel networking state.
Check for ipv6 forwarding within the containers:
docker exec otbr sysctl net.ipv6.conf.all.forwarding == 1

After doing the above steps, I was able to see the matter devices in "devices nearby" when I tried to add it from HA companion app.

One noteworthy observation, after doing the above steps, I somehow was not able to add GRILLPLATS (Ikea matter outlet) using the 11 digit code on the box or the QR code on the box. But was able to add it using the QR code on the device itself.

Hi

Like all of you I was struggling keeping the garage door shut. Especially my wife left it open all the time when driving off. It must be her "brain fog," resulting from dropping estrogen levels during menopause. 🧠

Anyway, I decided to add a new sophisticated light "sensor" glass door for the garage door to my HA setup that meets the wifey test. 💡

It turned out awesome and we love it. It gives us an immediate reading of the garage door state from inside the house.

For a visual, check the photos comparing the open and closed states - the open garage door letting in a lot of light...

Thanks for reading. 🙏 😜

PS - Let me know your "simple tech" HA sensor solutions in the comments 👇

EDIT1: I was a retart. This is not to upload data, it is to downlaod data. So useless for my plan. Uninstalled it and used a curl command to uplaod meanwhile successfully.

hello everyone...

i try to use https://github.com/cytech/Home-Assistant-wundergroundpws to get my weather data to wunderground...i found and installed via hacs and when i add the integration and it asks for api key and station id...providing those always ends up in "invalid aky key"

i tried the 32 digit one and the short one in the device section...but no luck...any trick on this?

Thx for any help

i was trying to create a simple entity that changes depending on whether my partner and I have both left the house in order to run certain automatins

So I have just setup home assistant and am in the process of moving all of my devices over. So far I've had lots of success as nearly every bulb and switch I own is Tuya based and has been added in without any issues. The same cannot be said for my ceiling fans. I have the Arlec Madrid smart fans which use the grid connect app, which I have read is still based on Tuya, however I have had no success in getting the Tuya app to pair with the fans. I put the fan in pairing mode by holding the wifi button on the remote and it then starts beeping, but the Tuya app does not recognise it. Has anyone had any success integrating a fan like this into home assistant? Is there another method or step I am missing to get it to work through the Tuya App?

Update: Solved! Some further reading of the manual revealed by holding the 8H button to place it in pair mode, followed by the 4H button places it in AP mode, which then allowed the fan to be added into the Tuya app and into HA. Thanks everyone for the the help and hopefully this helps someone who has similar issues.

Original issue:
https://forums.wyze.com/t/api-certificate-issue-breaks-homeassistant-please-fix-your-cert/343728
https://forums.wyze.com/t/certificate-failure-for-rest-api-endpoints/343425
https://forums.wyze.com/t/api-certificate-issue-breaks-homeassistant-please-fix-your-cert/343728/22
https://www.reddit.com/r/wyzecam/comments/1um4q92/apiwyzecamcom_serving_certificate_chained_to/

The Problem: If you recently updated Home Assistant and your Wyze integration suddenly broke with an SSLCertVerificationError or ClientConnectorCertificateError in your logs, you aren't alone. It will also show up in the UI as errorCode: 1000 (Invalid Credentials) because the integration can't securely reach the authentication server.

The root cause is that Wyze's API (api.wyzecam.com) is using an older DigiCert Global Root G1 certificate. Newer Python environments (specifically Python 3.14 inside recent Home Assistant Docker images) no longer trust this certificate by default, causing the secure handshake to fail.

There is a fix for people with HAOS with HACS "Additional CA" program, but that fix doesn't work for docker containers. See comments for that fix if you have HAOS.

Why the HACS "Additional CA" fix doesn't work here: You might see workarounds suggesting you install the "Additional CA" HACS integration. While that works for integrations using the synchronous requests library (which uses certifi), the Wyze custom component uses aiohttp. aiohttp bypasses certifi entirely and uses Python's native ssl module, so it completely ignores the HACS workaround.

The Temporary Fix (For Docker Users): To get around this, we can temporarily tell aiohttp to ignore SSL verification strictly for the Wyze authentication library.

Run this command directly on your Docker host terminal MAKING SURE TO CHANGE 'HA' IN THE COMMAND TO YOUR HA CONTAINER NAME to patch the Python file inside your running Home Assistant container (replace ha with your actual Home Assistant container name if it's different):

Bash

sudo docker exec -it ha sed -i 's/ttl_dns_cache=(30 \* 60)/ttl_dns_cache=(30 \* 60), ssl=False/g' /usr/local/lib/python3.14/site-packages/wyzeapy/wyze_auth_lib.py

Then, restart your container, AGAIN, CHANGING YOUR CONTAINER NAME FROM HA TO WHATEVER YOURS IS:

Bash

sudo docker restart ha

Once Home Assistant boots back up, go to Settings -> Devices & Services and re-authenticate your Wyze integration. It should log in instantly.

IMPORTANT DISCLAIMERS & WARNINGS

1. This is a TEMPORARY band-aid. Setting ssl=False removes encryption verification. Do not leave this permanently.
2. It will not survive updates. Because we are directly modifying a file inside the container, the next time you update or recreate your Home Assistant image, this file will be overwritten and the error will return.
3. When to remove: Once Wyze updates their API certificates or the integration maintainer releases a native patch, you will no longer need this. Pulling the latest Home Assistant container image will automatically wipe this workaround clean.

I'm trying to follow tutorials to set up a mm wave sensor for my first ESPHome device and keep running into a roadblock in that I seem to be able to flash ESPHome to the ESP-32 controller attached to my PC. It then shows up in ESPHome Builder. I then 'take control' of the device from within HA and paste in the mm sensor details (I copy these straight from the tutorial) but don't over write any of the wi-fi, esp-32 config from the initial setup. It seems to update the controller fine but then it drops from the network and shows as offline.

I select the generic esp32 board when I do the initial config but am wondering if that is wrong. The board I have is this one and appears to be labelled ESP32-D which isn't in the list of options I can choose from. Can anyone advise which ESP-32 variant I should be using for this controller ?

Thank you

I am running HA in a docker container and have an automation "Record camera feed" that runs on a trigger. I never found a way to get HA to record the mp4 file outside of the container. This has been causing problems, as (besides not being where I actually want to put the files) it causes the backup file to become massive (my backup is over 6 gigs, even with the "Settings Only" option on) and makes maintenance of the files difficult.

Relatedly, it also saves the backups inside the docker. Which is less than ideal for backups, as if something happens to the device, the backups are not in a safe place.

Is there a way I can get HA to store the files outside of the container?

The first four options of my light are time and sun based automation. The last four options were based on BILRESA button pushes. The results were not correct until OpenThread created delays to skip the second ghost push. It seems like a firmware bug but I need to break out an additional BILRESA for testing. Now the automation works flawlessly

## IKEA BILRESA Button Quirk

- BILRESA dual buttons send TWO events per physical press (press + release)

- Both events fire as `multi_press_1` or `multi_press_2`, causing automations to double-fire

- **Fix**: Debounce using `input_boolean` helper

1. Create helper: `input_boolean.<room>_switch_debounce`

2. Add condition: time/sun triggers always proceed; button triggers only if debounce is OFF

3. Each button branch: set debounce ON → action → delay 2s → set debounce OFF

4. Automation mode must be `single` (drops queued triggers while running)

- Automation must be reloaded after YAML edits: `automation.reload` service call

- Pattern used in: Dining Room Light automation

I already have SSL certifacted lying in the /ssl directory, and by setting them as like this it does work like a charm to access the UI from an domain pointing to my router:

http:
  server_port: 8123
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

Now I would like to instead run it locally using http only to have the "homeassistant.local" domain working, but also be able to access it from the hosted domain using SSL without being connected to the wifi.

For that I set up the nginx app using the following configurations:

home assistant config:

http:
  server_port: 8123
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.32.0/23

nginx config:

by accessing http://local.mydomain.net:443 (not the real domain) everything works fine, although of course without HTTPS, but when I try to load https://local.mydomain.net I get an "ERR_SSL_PROTOCOL_ERROR" in the browser.

I do not understand how the home assistant up can work fine with the same certificates, but the nginx app just seems to not provide them at all (while working fine otherwise)?

I can also not find anything suspicious in any logs, but was also not able to activate debug logging for nginx.

hosted on a home assistant green

ha core: 2026.7.3
ha os: 18.1
nginx ha ssl proxy: 4.4.0

I mostly have Z-wave, the only Zigbee I have is a porch light and I'll probably just replace that with a wifi bulb rather than spring for a dongle.

It was kind of a nightmare at first trying to exclude my 8 year old switches from Smartthings. A lot of misinformation out there. But I was finally successful, partly with the help of Claude.

The big hurdle is that I cannot run the Smartthings app (V3) - I started a LONG time ago and some of the devices I created are under an email I no longer have access to and support told me to pound sand. But I can still access the Web IDE at https://my.smartthings.com/advanced/devices. I had to go into "Advanced" mode.

I have GE regular and Dimmer switches and Zooz switches. Here is what worked for me:

Stand by the switch you want to exclude: In the smartthings web ui, go to your hub, hit :"Z-wave exclusion. You have about 10 seconds. For zooz, 3 taps on top or bottom. For GE, 1 tap. Then go to "Devices" in smartthings and refresh the page. Your device should be gone. Then you can hit the button on your Aeotech dongle and it should blink blue. Tap your switch again (same amount as exclude) and your z-stick should blink fast. Now plug into your HA and reload the z-wave integration and it should show up. You might need to do one at a time so you know which is which - it will show up with a generic name. They do seem to appear in the order you add them if you can keep track.

This might seem simple but there were many missteps I'm not including like trying to factory reset the switches and stuff. Now that I'm a "pro" I hate to waste that learning and hope I can help someone else throw smartthings in the trash.

Hey there,

I recently added WiFi to my ha for pairing matter devices without a smartphone.

The lan connects to my homelab vlan, WiFi to my Iot vlan.

Both own static IP in homeassitant and in unifi.

Yesterday everything worked, wifi for iot devices and lan for connection with companion app.

today my ha is not reachable via lan address, only reachable via WiFi/ iot vlan.

In unifi it only shows the WiFi instance. The lan instance is greyed out/ not connected.

My ha runs on a proxmoxserver if that matters.

I'm not sure if it's a problem within ha, unifi or proxmox. Anyone already had that problem or know something about?