fix: replace WarrantLite SRP login with USER_PASSWORD_AUTH via boto3

[mfncl9991]

Problem

Users are reporting login failures after deploying the v1.5.7 fix:

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

RespondToAuthChallenge is part of Cognito's SRP auth flow — used by auth.login() via WarrantLite. The root cause is the same as the one already fixed in async_refresh_auth: WarrantLite calls get_secret_hash() which breaks when client_secret=None (the new public client has no secret). This causes the SRP password verifier to be computed or submitted incorrectly for some accounts.

The failure is not universal — users with existing sessions that re-auth via the stored credentials may not notice it, but any fresh login (new install, reconfigure, or re-auth for affected accounts) hits it.

Fix

Replace auth.login() with a direct boto3 USER_PASSWORD_AUTH call — the same pattern already used in async_refresh_auth — which bypasses SRP entirely and is not sensitive to the missing client secret.

References

• Same root cause as the async_refresh_auth fix in fix: update auth and device control for Winix API v1.5.7 #158

[mfncl9991]

Requested impacted user to help test, as at least my HA session is not impacted by this. See #155 (comment)

Test instructions:

Grab helpers.py from this PR branch and drop it into /config/custom_components/winix/, then restart HA and retry auth.

[iprak]

I hit this exception

My workflow was to setup integration from scratch.

[mfncl9991]

@iprak thanks for this, there's our smoking gun that kills this PR/hypothesis:
InvalidParameterException: USER_PASSWORD_AUTH flow not enabled for this client

SRP is not broken by the secret.

Looking at WarrantLite's actual source — it explicitly checks if self.client_secret is not None before including
SECRET_HASH in both get_auth_params() and process_challenge(). So with client_secret=None, it correctly omits it entirely.

USER_PASSWORD_AUTH is not enabled on this client, so PR #162 is the wrong fix and should be closed.

The SRP flow is actually correct for users where it works. The question is why it fails for the specific user... with WarrantLite correctly patched, the most likely remaining causes are:

• Username case mismatch (Cognito is case-sensitive for some pool configurations)
• Account-specific state — e.g. account requires password reset, has never authenticated via the Winix app, or the SRP verifier in Cognito is stale/missing
• Special characters in the password interacting with the UTF-8 encoding in the SRP computation

Propose we close this PR and continue troubleshooting via the issue.

[mfncl9991]

Closing. Confirmed issue was with the users password containing special characters. This fix not relevant.

#162 (comment)

Special characters in the password interacting with the UTF-8 encoding in the SRP computation