Honeywell integration cookies are leaking, breaking deCONZ w/ HTTP error 431

[endrift]

The problem

After upgrading my several-month-old installation of hass core, I discovered that deCONZ was no longer working, generating HTTP 431 Request Header Fields Too Large errors when I attempted to access the Phoscon integration or toggle lights and the like.

After a bunch of investigation, I discovered that the header in question was a massive cookie header. The cookie in question was .ASPXAUTH_TRUEHOME, the auth cookie from aiosomecomfort. Somehow, that cookie was leaking out of honeywell's cookie jar and into the jar that was being used for deCONZ, causing it to break. Once I disabled the honeywell integration and restarted hass, everything started working again.

What version of Home Assistant Core has the issue?

core-2025.6.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

honeywell

Link to integration documentation on our website

https://www.home-assistant.io/integrations/honeywell

Diagnostics information

No response

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

No response

[home-assistant]

Hey there @rdfurman, @mkmer, mind taking a look at this issue as it has been labeled with an integration (honeywell) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of honeywell can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign honeywell Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

honeywell documentation
honeywell source
_{^{(message by IssueLinks)}}

[lurgh]

Been looking at the honeywell code since this seemingly impacted other integrations I use. The honeywell integration passes the shared aiohttp session async_get_clientsession(hass) to the aiosomecomfort instance, which in turn calls CookieJar.update_cookies() without passing a response_url, so the auth cookies it updates from the server response will be considered "shared" and sent on all sessions that use that shared aiohttp session, rather than restricted to the honeywell server's domain. That would seemingly be the cause of honeywell polluting the aohttp sessions used by other integrations.

That being said, maybe something else changed that was masking this, because the misbehavior only became evident when people started upgrading to 2025.6.x.

I have worked around the impacts on other integrations by patching honeywell to always create its own aiohttp session, not just when there are multiple instances.

[jl-678]

Can you share your patch? If it is easy to implement perhaps we can use it as workaround until we wait for the formal fix from the Honeywell maintainers?

[jl-678]

That being said, maybe something else changed that was masking this, because the misbehavior only became evident when people started upgrading to 2025.6.x.

I can confirm this as I rolled back to 2025.5.3, and everything works as expected, so it appears to be both an issue with the Honeywell integration and 2025.6.x

[lurgh]

Can you share your patch? If it is easy to implement perhaps we can use it as workaround until we wait for the formal fix from the Honeywell maintainers?

Not pretty but as a temporary patch all I did is at line 59 in homeassistant/components/honeywell/__init__.py, change 1 to -1, causing it to always call async_create_clientsession(hass) to obtain a new aiohttp session to initialize the aiosomecomfort instance, rather than using async_get_clientsession(hass) when there is only one honeywell device configured. So the section starting at line 59 now reads:

    if len(hass.config_entries.async_entries(DOMAIN)) > -1:
        session = async_create_clientsession(hass)
    else:
        session = async_get_clientsession(hass)

I believe this should be safe but use at your own risk. After changing this code you need to restart homeassistant.

[alvinchen1]

Can you share your patch? If it is easy to implement perhaps we can use it as workaround until we wait for the formal fix from the Honeywell maintainers?

Not pretty but as a temporary patch all I did is at line 59 in homeassistant/components/honeywell/__init__.py, change 1 to -1, causing it to always call async_create_clientsession(hass) to obtain a new aiohttp session to initialize the aiosomecomfort instance, rather than using async_get_clientsession(hass) when there is only one honeywell device configured. So the section starting at line 59 now reads:

if len(hass.config_entries.async_entries(DOMAIN)) > -1:
    session = async_create_clientsession(hass)
else:
    session = async_get_clientsession(hass)

I believe this should be safe but use at your own risk. After changing this code you need to restart homeassistant.

I am using honeywell integration and have been working with owner of another integration airq which started to fail with 2025.6.0. Following a few other issues all related to the aiohttp update, the airq owner also went with async_create_clientsession. One of the odd things for us until now, is that not everyone with air-q seemed to be affected by the 2025.6.0. With the discovery of honeywell behaving this way, it makes more sense.

See #146694 and #147027

[jl-678]

Can you share your patch? If it is easy to implement perhaps we can use it as workaround until we wait for the formal fix from the Honeywell maintainers?

Not pretty but as a temporary patch all I did is at line 59 in homeassistant/components/honeywell/__init__.py, change 1 to -1, causing it to always call async_create_clientsession(hass) to obtain a new aiohttp session to initialize the aiosomecomfort instance, rather than using async_get_clientsession(hass) when there is only one honeywell device configured. So the section starting at line 59 now reads:

if len(hass.config_entries.async_entries(DOMAIN)) > -1:
    session = async_create_clientsession(hass)
else:
    session = async_get_clientsession(hass)

I believe this should be safe but use at your own risk. After changing this code you need to restart homeassistant.

I implemented this change and can confirm that it addresses the situation. Thank you!

[alvinchen1]

Not pretty but as a temporary patch all I did is at line 59 in homeassistant/components/honeywell/__init__.py, change 1 to -1, causing it to always call async_create_clientsession(hass) to obtain a new aiohttp session to initialize the aiosomecomfort instance, rather than using async_get_clientsession(hass) when there is only one honeywell device configured. So the section starting at line 59 now reads:

if len(hass.config_entries.async_entries(DOMAIN)) > -1:
    session = async_create_clientsession(hass)
else:
    session = async_get_clientsession(hass)

I believe this should be safe but use at your own risk. After changing this code you need to restart homeassistant.

I implemented this change and can confirm that it addresses the situation. Thank you!

That's great that it seems to work. I'll just add that the code owner has spent a LOT of time over the last several years balancing the functionality of the integration with the rate limit honeywell puts on their API (search issues for honeywell rate limit). Not a programmer here, but would this new method of creating a client session cause the integration to run up against the rate limit on the API? Also if there are multiple devices attached to the same honeywell account, would this change exponentially increase the number of hits on the API?