Add Gardena mower protocol features

[AlirezaT]

This ports the generic Automower/Gardena BLE protocol work from the Home Assistant Gardena BLE integration back into the Python library.

Included:

• safer command response helpers that expose mower response results
• serialized locked command flow for multi-step commands
• keep-alive task cleanup on disconnect
• schedule transaction helpers for reading, replacing, and clearing weekly tasks
• Gardena-compatible SpotCut flow: prepare SpotCut, start timed override, then trigger start
• additional protocol definitions for battery diagnostics, SensorControl/frost sensor, drive-past-wire, starting points, reversing distance, SpotCut, realtime sensor data, signal quality, firmware/hardware identity, and production info
• parser support for signed 16-bit values and variable trailing integer fields, so GetTask works with both existing upstream fixtures and Gardena responses

Notes:

• The new commands were tested from the Home Assistant integration against a Gardena Sileno mower and cross-checked with Gardena app BLE/HCI observations where available.
• Some commands are model-dependent and may return NOT_AVAILABLE, INVALID_ID, or NOT_ALLOWED on mowers that do not expose that feature.

Validation:

• python -m unittest discover
• python -m compileall automower_ble tests
• git diff --check

[alistair23]

Sorry about the long delay!

Overall this looks good. It does need a rebase and the ruff CI tests need to pass.

It would be great (although not required) if you could split the PR up into some smaller independent PRs. That way if something breaks it's easy to figure out exactly what change causes the breakage.

I'm also not clear on why we need

safer command response helpers that expose mower response results
serialized locked command flow for multi-step commands

Can you provide a few more details?

[AlirezaT]

Thanks! I rebased the branch on current main and fixed the ruff issues.

Locally I now have:

• python -m ruff check .: passing
• python -m ruff format --check .: passing
• python -m pytest: 24 passed

About the command response helpers: these are mainly to let callers distinguish protocol-level mower response results such as OK, NOT_AVAILABLE, NOT_ALLOWED, OUT_OF_RANGE, DEVICE_BUSY, etc. The existing command helper is convenient when a command succeeds, but integrations also need to know when a mower model explicitly does not support a command or temporarily rejects it. That allows unsupported features to be disabled or skipped cleanly instead of repeatedly polling them and only seeing None/log noise.

About the locked command flow: the mower replies through one shared BLE notification queue. If two commands are allowed to overlap, one caller can consume the response intended for another command. The lock keeps command/request/response ordering serialized.

The locked helper is for higher-level multi-step flows that already hold the command lock and need to send several commands without another command interleaving between them. This is useful for transaction-style operations such as schedule updates, where the sequence needs to remain ordered.

[alistair23]

Still a ruff format issue

[AlirezaT]

Thanks for pointing this out. I rebased the PR branch on the current upstream main and resolved the conflict in automower_ble/protocol.py by keeping the newer upstream disconnect behavior.

Current status from GitHub is now:

• mergeable: MERGEABLE
• reviewDecision: APPROVED
• the remaining workflow runs are action_required, so they just need maintainer approval to run again

I also reran the checks locally after the rebase:

• ruff 0.12.4 format --check --no-cache .: passed
• ruff 0.12.4 check --no-cache .: passed
• python -m mypy .: passed
• python -m pytest: 24 passed

Could you please trigger/approve the workflows again when you have a moment?

[gruijter]

@alistair23 hope this is merged soon so I can finalize my Homey app this weekend 🙏.