Repository navigation
WebSocket disconnect: "Received frame with non-zero reserved bits" after upgrading to Home Assistant 2026.10 #6011
Description
iOS device model, version and app version
Model Name: iPhone 13
Software Version: 27.0.1
App version: 2026.9.3
Home Assistant Core Version
2026.10.0
Describe the bug
After upgrading Home Assistant Core from 2026.9.x to 2026.10.0, the Home Assistant iOS Companion App started experiencing frequent WebSocket disconnects.
Home Assistant logs show:
Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/http.py:569
Integration: Home Assistant WebSocket API
[3203406258096] Petar from 192.168.1.117
(Home Assistant/2026.9.3; build:2026.3126; iOS 27.0.1):
Disconnected: Received error message during command phase:
Received frame with non-zero reserved bits
This started after upgrading Home Assistant to 2026.10.0. The same setup did not produce these messages before the upgrade.
Network
The iPhone is connected to the same local LAN as Home Assistant.
The connection is local and does not depend on Nabu Casa remote access.
The iPhone is identified in the Home Assistant log by local IP address:
192.168.1.117
No network configuration changes were made when the problem started.
What is happening?
The iOS Companion App establishes a WebSocket connection to Home Assistant, but the connection is periodically terminated by Home Assistant with:
Received frame with non-zero reserved bits
The Companion App appears to reconnect afterwards, but the error can occur repeatedly and is logged by Home Assistant.
To Reproduce
Run Home Assistant OS with Core 2026.10.0.
Connect the Home Assistant Companion App 2026.9.3 (build 2026.3126).
Use an iPhone running iOS 27.0.1.
Keep the Companion App connected to the local Home Assistant instance.
Monitor the Home Assistant logs.
WebSocket disconnects occur with the non-zero reserved bits error.
Expected behavior
The Companion App should maintain a stable WebSocket connection to Home Assistant without WebSocket protocol errors or unexpected disconnections.
Screenshots
Additional context
The issue appeared immediately after upgrading Home Assistant Core to 2026.10.0.
The same iPhone, Companion App and local network configuration were working without this error before the Home Assistant upgrade.
The error appears to originate from the WebSocket protocol handling rather than from a normal authentication or connectivity failure.
I have not changed the UniFi network configuration, DNS configuration, VLAN configuration, or Home Assistant WebSocket configuration.
I would appreciate it if this could be investigated as a possible regression involving Home Assistant Core 2026.10.x, the WebSocket implementation, and the iOS Companion App.
I can provide additional logs or diagnostics if required.
Activity
Petarkir2000 commentedon Oct 8, 2026
Seeing the same symptom, likely related to #5999.
Additional data points:
The "non-zero reserved bits" error usually points to a compressed (permessage-deflate) frame sent without negotiated compression, so it may be worth checking the app's WebSocket client configuration against the aiohttp version bundled in 2026.10. I can't tell from my side whether the regression is in Core or in the app, so happy to provide app logs or test builds if useful.
aignersabrinaa-jpg commentedon Oct 9, 2026
Additional reproduction with correlated Companion App and Home Assistant server logs from 2026-10-09. Personal identifiers, LAN addresses and location data have been omitted.
Environment:
Sec-WebSocket-Extensions: permessage-deflatePython/3.14 aiohttp/3.14.4All times below are CEST (UTC+02:00).
The iPhone app logs and server logs match within milliseconds:
The same sequence repeats at 19:03:56, 19:04:52, 19:05:48, 19:06:44 and 19:07:44. A separate morning series contains seven code-1002 disconnects between 11:04:20 and 11:09:56, approximately 56 seconds apart. The current app log contains 33 code-1002 disconnects; seven more appear in the rotated log from October 8.
The server also records the identical reserved-bits error for the iPad app seven times between 18:48:14 and 18:53:50, approximately 56 seconds apart.
There are visible app interruptions/loading screens in this setup, whereas Chrome reportedly works reliably. Additional app-side evidence:
Web content process terminatedHard resetting disconnected web frontend after empty state backoffThe close timing suggests investigating Ping/Pong frame handling and the negotiated compression extension. This is a hypothesis, not a confirmed root cause. The native app WebSocket and embedded dashboard connection should be distinguished; these logs do not prove that every visible interruption is caused by the native WebSocket disconnect.
No Home Assistant configuration changes were made as part of this investigation.
danpeled7 commentedon Oct 9, 2026
Same issue here, matching versions:
Log (name redacted):
What differs from the original report: for me it is NOT every ~56s. On Oct 9 it occurred
only 5 times (07:46, 14:56, 22:10, 22:12, 22:23), which suggests it's triggered by
specific messages rather than a periodic keepalive.
User-visible impact: Assist requests from the app are lost. A typed Assist request sent
at 14:56 hung on "thinking" indefinitely, and the disconnect was logged at the same second.
The request never reached the pipeline (no run in the Assist debug view), while Assist
typed from a desktop browser worked fine at the same time. Other app functions keep
working because the app reconnects automatically.
nickneutron commentedon Oct 10, 2026
same issue here.. been a pretty frustrating few days dealing with this.
Never compress WebSocket control frames
Bump HAKit to 0.4.19
Bump HAKit to 0.4.19 in local package manifests
baetzmr commentedon Oct 10, 2026
Same issue here since updating Core to 2026.10.0 (Home Assistant OS).
Log:
Disconnected: Received error message during command phase: Received frame with non-zero reserved bits
The app reconnects on its own.
Since the app update did not change anything and home-assistant/core#184971 shows the same error from iPadOS 15.8.8 with an older app build, this looks like a server-side regression in Core 2026.10 (possibly the stricter aiohttp websocket frame checks).
Related: home-assistant/core#184799, home-assistant/core#184971, home-assistant/core#185083, #5999
crissmil commentedon Oct 11, 2026
Request: Core-side compatibility fix for older iOS devices
Thank you for identifying the root cause and preparing the Starscream fix in #6038.
I would like to raise an important compatibility concern for older Apple devices that cannot receive newer Companion App releases.
My Home Assistant installation includes:
Both devices exhibit the exact same WebSocket error every approximately 56 seconds. I documented the precise timestamps in home-assistant/core#184799.
Since the iOS 15.8.8 device cannot upgrade to a Companion App version requiring iOS 16.4 or later, the application-side fix alone will leave it permanently affected.
Could the Home Assistant Core team consider a backward-compatibility workaround for legacy Companion App clients?
For example, if technically feasible, a narrowly scoped workaround for the affected WebSocket control frames, without weakening validation for all clients.
I understand that the stricter aiohttp behavior is standards-compliant and that the original bug is in Starscream. However, a compatibility solution would be valuable for existing kiosk installations that rely on older, otherwise functional Apple devices.
I would prefer to keep these devices operational rather than downgrade Home Assistant Core indefinitely.
Thank you for considering this.
bgoncal commentedon Oct 11, 2026
On its way home-assistant/core#185746
Petarkir2000 commentedon Oct 12, 2026
Update: still happening after updating both Core and the companion app, so neither fixes it.
Current setup:
Same log entry as before:
"Disconnected: Received error message during command phase: Received frame with non-zero reserved bits"
(logger: homeassistant.components.websocket_api.http.connection, http.py:569)
What I can say from the three related reports (this one, #5999, #6011):
I can't tell from my side whether the trigger is in Core's websocket_api/aiohttp handling or in how the iOS 27 WebSocket stack sends frames, but the combination seems to be what matters. The app reconnects automatically and nothing visibly breaks, it only produces warnings in the log.
Happy to provide app logs or test a build if that helps.
Petarkir2000 commentedon Oct 12, 2026
Adding more data, in case this needs another look.
The issue is still reproducible after updating both sides, so it is not fixed by a newer app or Core build:
Same entry in the Core log:
"Disconnected: Received error message during command phase: Received frame with non-zero reserved bits"
(logger homeassistant.components.websocket_api.http.connection, http.py:569)
Other reports with the same message:
Across these reports the app build and iOS 27.x version differ, so the common factor seems to be Core 2026.10.x together with an iOS 27 client. Before upgrading Core to 2026.10 the same phone and app version did not produce this message. The entries repeat at a regular interval of about 56 seconds, as also seen in #5999, which suggests a periodic frame (keepalive/ping?) is being rejected. The app reconnects automatically, so nothing visibly breaks beyond the log warnings.
I can't tell from my side whether the cause is on the Core side (websocket_api / aiohttp) or in the iOS WebSocket client. If this was closed because information is missing, please tell me what you need (app logs, a packet capture, a specific test build) and I will provide it.
bgoncal commentedon Oct 12, 2026
The app version that patches this is 2026.10.1 not 2026.10.0