Lost control of device and now unable to log in

[jwagner0789]

My air purifier wasn't responding to fan speed changes but the entity would update when changes were made via the app. I removed and readded the integration and now I'm not able to login. UI stating invalid username/password. I use a primary account on the app and a secondary account for HA. Please let me know if you need anything else.

Logs state:

This error originated from a custom integration.

Logger: custom_components.winix
Source: custom_components/winix/config_flow.py:45
integration: Winix Air Purifier (documentation, issues)
First occurred: 10:52:54 AM (2 occurrences)
Last logged: 10:53:03 AM

Unexpected error during authentication: An error occurred (ResourceNotFoundException) when calling the InitiateAuth operation: User pool client 14og512b9u20b8vrdm55d8empi does not exist.

[regaw-leinad]

I just had a user of my https://github.com/regaw-leinad/homebridge-winix-purifiers report the same thing. Came here to see if anyone else had this issue across ecosystems. I'm lookin into this today too

[mfncl9991]

@regaw-leinad @iprak dug into this and filed a couple of PRs fixing separate issues discovered after the today's Winix API backend rotation.

Confirmed the fixes allowed me to log in fine and control the fan/C545 again without issues. (FYI I did use claude code).

---

#158 — fix: update auth and device control for Winix API v1.5.7

Winix rotated their Cognito app client on 2026-04-16, breaking login and device control for all users. Key changes:

• New Cognito app client ID (5rjk59c5tt7k9g8gpj0vd2qfg9, public — no client secret)
• appVersion bumped to 1.5.7 (server enforces version/client pairing)
• Per-user identityId now required in registerUser and checkAccessToken payloads, fetched from Cognito Identity Pool via boto3
• New /init endpoint must be called between registerUser and checkAccessToken
• CTRL_URL now uses the user's identityId instead of the hardcoded A211 segment
• async_refresh_auth rewritten to use boto3 initiate_auth directly, since auth.refresh() calls get_secret_hash(None) which throws a TypeError with the new secretless client

#157 — fix: move ensure_on and speed command outside airflow guard in async_set_speed

Independent bug in async_set_speed: async_ensure_on(), async_manual(), and the speed call were inside an if ATTR_AIRFLOW != speed guard. Because async_manual() optimistically sets
ATTR_AIRFLOW = AIRFLOW_LOW, any subsequent call at the same speed level would skip all three — leaving the fan off or in the wrong mode. Fixed by moving all three calls outside the guard.

[nabeelr]

Yeah, I'm having this issue too, for the last couple days…

[ralong777]

@regaw-leinad @iprak dug into this and filed a couple of PRs fixing separate issues discovered after the today's Winix API backend rotation.

Confirmed the fixes allowed me to log in fine and control the fan/C545 again without issues. (FYI I did use claude code).

#158 — fix: update auth and device control for Winix API v1.5.7

Winix rotated their Cognito app client on 2026-04-16, breaking login and device control for all users. Key changes:

• New Cognito app client ID (5rjk59c5tt7k9g8gpj0vd2qfg9, public — no client secret)
• appVersion bumped to 1.5.7 (server enforces version/client pairing)
• Per-user identityId now required in registerUser and checkAccessToken payloads, fetched from Cognito Identity Pool via boto3
• New /init endpoint must be called between registerUser and checkAccessToken
• CTRL_URL now uses the user's identityId instead of the hardcoded A211 segment
• async_refresh_auth rewritten to use boto3 initiate_auth directly, since auth.refresh() calls get_secret_hash(None) which throws a TypeError with the new secretless client

#157 — fix: move ensure_on and speed command outside airflow guard in async_set_speed

Independent bug in async_set_speed: async_ensure_on(), async_manual(), and the speed call were inside an if ATTR_AIRFLOW != speed guard. Because async_manual() optimistically sets ATTR_AIRFLOW = AIRFLOW_LOW, any subsequent call at the same speed level would skip all three — leaving the fan off or in the wrong mode. Fixed by moving all three calls outside the guard.

So how can i apply those fixes?

[mfncl9991]

So how can i apply those fixes?

@ralong777 Here's the PR - working with maintainer for approval, then this needs to be merged and released.

#158

If you don't want to wait you can pull the custom config files directly from my branch the PR references, but best to wait for a new release.

[x86txt]

Came here for the same reason, awesome that it's already been fixed. I'll wait for the official merge.

[iprak]

This has been addressed in #158.

[ashint365-stack]

I see that this issue is closed but I'm still not able to login! I tried both version v1.3.10 and v1.3.09 and still unable to login. I'm using the latest Home Assistant OS for reference and have restarted the VM after the update but the issue persist.

[mfncl9991]

I see that this issue is closed but I'm still not able to login! I tried both version v1.3.10 and v1.3.09 and still unable to login. I'm using the latest Home Assistant OS for reference and have restarted the VM after the update but the issue persist.

Here is the error I got. I've verified that the username and password are correct.

Logger: custom_components.winix
Source: custom_components/winix/config_flow.py:45
integration: Winix Air Purifier (documentation, issues)
First occurred: 1:39:50 AM (3 occurrences)
Last logged: 1:55:08 AM

Unexpected error during authentication: An error occurred (NotAuthorizedException) when calling the RespondToAuthChallenge operation: Incorrect username or password.

Thanks for the report with the specific error.
I suspect the problem is with auth.login() that uses WarrantLite's SRP auth flow which breaks with the new public Cognito client (no client secret), causing the RespondToAuthChallenge failure for some accounts even with correct credentials.

Filed a new PR #162 with a fix to test - it replaces the SRP flow with USER_PASSWORD_AUTH via boto3, the same approach already working for token refresh.

Important

Edit: Turns out SRP is not broken by the secret, 162 is not the right fix.

[iprak]

@ashint365-stack Can you provide the debug log?

[mfncl9991]

@ashint365-stack Given testing 162 shows its not the right fix, thinking more about why it fails for you specifically.
I assume the same credentials were working before the outage/client rotation (same case, no changed password)? If so, one possibility is a server-side SRP verifier issue with the new Cognito client.

Can you try these steps?

1. Log into the Winix mobile app — this may force Cognito to rebuild the SRP verifier for your account under the new client
2. Then go to Settings → Integrations → Winix in HA and re-authenticate

If no luck, as @iprak mentioned, enable debug logging (add custom_components.winix: debug under logger.logs in configuration.yaml, restart, then try re-authenticating) and share the full error from Settings → System → Logs.
(Turn debug logging off after that to stop spamming of the logs)