Cognito GetUser called on every poll, eventually trips TooManyRequestsException

[ajplotkin]

Describe the bug

populate_AWS_token() calls the AWS Cognito GetUser API on every poll window, even when the cached token is still perfectly valid. That is an unnecessary round-trip on a fixed cadence, and it eventually trips Cognito's rate limiter:

botocore.errorfactory.TooManyRequestsException:
  An error occurred (TooManyRequestsException) when calling the GetUser operation: Too many requests

When it fires, the entity update fails and the sensor keeps its previous value until the next successful poll.

Details

pentaircloud.py:

def populate_AWS_token(self) -> None:
    if self.cognito_client is not None:
        self.cognito_client.check_token()
        new_token = self.cognito_client.get_user()._metadata["id_token"]   # <-- every time
        if self.AWS_TOKEN != new_token:  # Token has been refreshed
            self.AWS_TOKEN = new_token
            self.populate_AWS_and_data_fields()

check_token() already handles refreshing an expired token — that's its job. The get_user() call that follows is a full AWS API round-trip whose only purpose is to read id_token out of the response metadata, and it runs unconditionally.

populate_AWS_token() is called from update_pentair_devices_status(), which is throttled by UPDATE_MIN_SECONDS — so this is one GetUser per throttle window, continuously, for the life of the integration.

Full traceback

File "/config/custom_components/pentair_cloud/sensor.py", line 142, in update
    self.hub.update_pentair_devices_status()
File "/config/custom_components/pentair_cloud/pentaircloud.py", line 306, in update_pentair_devices_status
    self.populate_AWS_token()
File "/config/custom_components/pentair_cloud/pentaircloud.py", line 201, in populate_AWS_token
    new_token = self.cognito_client.get_user()._metadata["id_token"]
File ".../pycognito/__init__.py", line 544, in get_user
    user = self.client.get_user(AccessToken=self.access_token)
File ".../botocore/client.py", line 1094, in _make_api_call
    raise error_class(parsed_response, operation_name)
botocore.errorfactory.TooManyRequestsException: ... when calling the GetUser operation: Too many requests

Frequency

Three occurrences in two days on my install (roughly a 12-hour cadence), each taking out one entity update. It self-recovers on the next poll, so it's not fatal — but it's avoidable load on Pentair's auth endpoint and it produces recurring ERROR-level noise.

Suggested fix

Only call get_user() when the token has actually been refreshed, rather than on every pass. pycognito's check_token() returns whether it refreshed, so the round-trip can be gated on that — or the id_token can be read from the client's own state after check_token() without a network call.

Worth noting as corroboration: the Homebridge plugin for the same Pentair cloud API (homebridge-pentair-cloud) authenticates via Cognito SRP and does not issue a GetUser per poll — so the per-poll call doesn't appear to be required by the API.

Environment

• Home Assistant 2026.7.3 (Docker), Python 3.14
• pentair_cloud v1.1.0, installed manually (no HACS)
• Pentair IntelliFlo Pro3 VSF, deviceType: IF31 (device id redacted)

[ajplotkin]

One piece of context for whoever picks this up, and a correction to something I nearly assumed.

dcondomitti/pentair_cloud has independently hardened this same function, but it does not address the rate-limiting cause — it still calls get_user() on every pass. What it adds is a proactive AWS-credential expiry check alongside the token comparison:

new_token = self.cognito_client.get_user()._metadata["id_token"]
token_changed = self.AWS_TOKEN != new_token
creds_expired = (
    self.aws_credentials_expiry is not None
    and time.time() > self.aws_credentials_expiry - 300
)
if token_changed or creds_expired:
    self.AWS_TOKEN = new_token
    self.populate_AWS_and_data_fields()

That closes a real gap this repo has — currently the AWS identity credentials are only refreshed when the Cognito id-token changes, so credentials that expire without a token change would go stale. Worth having regardless of the rate-limiting issue.

So the two are complementary: a fix here should drop the unconditional get_user() and keep an expiry-based refresh path like the above. Credit to @dcondomitti for the latter.