Fix Play/Stop Sound: accept and forward the cache kwarg (TypeError on every press)

[totol123]

Problem

Pressing any Play Sound (or Stop Sound) button does nothing. The log shows, on every press:

ERROR ... custom_components.googlefindmy.api: Failed to play sound (async) on <id>: async_submit_start_sound_request() got an unexpected keyword argument 'cache'
DEBUG ... custom_components.googlefindmy.coordinator: Entering push cooldown for 90s after transport failure

GoogleFindMyAPI.async_play_sound / async_stop_sound call the submitters with cache=self._cache:

• async_submit_start_sound_request(device_id, token, session=self._session, cache=self._cache)
• async_submit_stop_sound_request(device_id, token, request_uuid=..., session=self._session, cache=self._cache)

but async_submit_start_sound_request / async_submit_stop_sound_request do not accept a cache parameter → TypeError on every press. The resulting failure also enters a 90s push cooldown, which makes the buttons intermittently appear unavailable too.

Fix

Add cache: Optional[any] = None to both submitters and forward it to async_nova_request(...), which already accepts cache. This mirrors the existing device-list path (async_request_device_list(..., cache=...)).

Forwarding the entry-scoped cache also ensures the correct account's tokens are used in multi-account setups (reproduced with two Google accounts configured — without this, the sound action can resolve against the wrong cache).

Testing

With two config entries (two Google accounts), Play Sound now reliably rings the target Android phone. Verified via the device's Émettre un son button entity and via dashboard button.press actions; the unexpected keyword argument 'cache' error and the spurious 90s push cooldown are both gone.

Affected version: 1.6.2.3.

[jleinenbach]

Thanks for tracking this down, and for including the exact log lines. I verified the report
independently. Below is what I measured, for the record.

The bug is real on main

I ran an AST scan over main that checks every call's keyword arguments against the signature
of the function actually being called. It flags exactly the two call sites you name:

• custom_components/googlefindmy/api.py:767-769 -> async_submit_start_sound_request(..., cache=self._cache)
• custom_components/googlefindmy/api.py:804-806 -> async_submit_stop_sound_request(..., cache=self._cache)

Neither submitter on main declares a cache parameter, so both raise TypeError on every
press. The released tag V1.6.2.3 (2025-11-13), the version you report, carries the same code.
This is a shipped defect, not a broken working copy.

Where this code lives, and where it does not

• main is this repository's default branch. Its most recent commit is from 2025-12-02, and
  the last release cut from it is V1.6.2.3. Everything above applies to it, and to anyone who
  takes the default branch (Code -> Download ZIP, or git clone without -b 1.7).
• Every release since then comes from the 1.7 branch, up to v1.7.14 (2026-07-18). The two
  lines have diverged: GET /repos/BSkando/GoogleFindMy-HA/compare/main...1.7 reports
  status: diverged, ahead_by: 3048, behind_by: 2. main is not an earlier point on the
  same line; there are 3048 commits on 1.7 that main has never seen, and 2 on main that
  1.7 has never seen.
• On 1.7 this TypeError cannot occur. Both submitters there take cache: TokenCache | None
  (start_sound_request.py:84, stop_sound_request.py:88), alongside namespace, username,
  token, cache_get / cache_set and refresh_override. The same AST scan over 1.7
  reports zero mismatches.

So the patch is not redundant for the main audience, and it does not apply to the 1.7 line.

A third instance of the same error class on main

The same scan finds one more keyword/signature mismatch on main, which this PR does not touch:

# custom_components/googlefindmy/coordinator.py:1743
self._run_on_hass_loop(self.push_updated, device_ids, reset_baseline=reset_baseline)

# custom_components/googlefindmy/coordinator.py:351
def _run_on_hass_loop(self, func, *args) -> None:

Positional varargs only, no **kwargs, so this raises TypeError whenever push_updated is
invoked from a thread other than the HA event loop, i.e. on the push path.

One nit on the patch itself

Optional[any] uses the built-in function any, not typing.Any. Thanks to
from __future__ import annotations it does not fail at import time, so the patch works as you
tested it, but static type checkers and any runtime call to typing.get_type_hints() will
choke on it. In fairness, that form is already the house style on main: it appears in six
files there, including NovaApi/nova_request.py:651, which is the very function these two call
sites forward to, so the patch is consistent with its surroundings.