Hi Andreas,
I’m having the same problem. I have a bunch of Konnected devices that got upgraded to ESPHome 2025.10.x and I’m seeing the same CONNECTION_CLOSED error. Digging around I found this:
dev ← auth_request
opened 02:22AM - 15 Sep 25 UTC
# What does this implement/fix?
This PR renames the API protocol messages `Co… nnectRequest` and `ConnectResponse` to `AuthenticationRequest` and `AuthenticationResponse` respectively. This naming change better reflects the actual purpose of these messages - they handle authentication via password validation, not the connection establishment itself.
The RPC method is also renamed from `connect` to `authenticate` to maintain consistency.
This change was suggested by @jesserockz in #10704 and aligns the naming with the actual functionality - these messages are only used when `USE_API_PASSWORD` is defined and handle password authentication, not the TCP connection process.
## Types of changes
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Code quality improvements to existing code or addition of tests
- [ ] Other
**Related issue or feature (if applicable):**
- Related to discussion in #10704
**Pull request in [esphome-docs](https://github.com/esphome/esphome-docs) with documentation (if applicable):**
- N/A - Internal API protocol change
## Test Environment
- [x] ESP32
- [x] ESP32 IDF
- [x] ESP8266
- [ ] RP2040
- [ ] BK72xx
- [ ] RTL87xx
- [ ] nRF52840
## Example entry for `config.yaml`:
```yaml
# No configuration changes required
# This is an internal API protocol change
api:
password: "your_password" # Still works the same way
```
## Checklist:
- [x] The code change is tested and works locally.
- [x] Tests have been added to verify that the new code works (under `tests/` folder).
If user exposed functionality or configuration variables are added/changed:
- N/A - This is an internal protocol change that doesn't affect user-facing configuration
## Additional Notes
### Breaking Change Details
While this is technically a breaking change at the protocol level (only for consumers of api.proto as the wire protocol is the same), it should have minimal impact because:
1. The primary consumer of this API (aioesphomeapi) handles this as an internal implementation detail
2. The companion PR for aioesphomeapi updates it to use the new message names
3. Home Assistant uses aioesphomeapi and won't be directly affected
4. The messages are only used when password authentication is enabled (`USE_API_PASSWORD`)
### Changes Made
- Renamed `ConnectRequest` to `AuthenticationRequest` in api.proto
- Renamed `ConnectResponse` to `AuthenticationResponse` in api.proto
- Renamed RPC method from `connect` to `authenticate`
- Updated all C++ references:
- `send_connect_response()` → `send_authenticate_response()`
- `on_connect_request()` → `on_authentication_request()`
- Regenerated protobuf files with new names
### Coordination Required
This PR should be merged in coordination with the corresponding aioesphomeapi PR to ensure compatibility. https://github.com/esphome/aioesphomeapi/pull/1346
It’s labeled as a breaking change so I suspect this is the cause. There are also several open issues noting connection problems since upgrading to 2025.10.x
