Work-time queries count any two matching notifications instead of one response of each type

[Bjorkan]

TL;DR

A schedule query needs one start-time packet and one duration packet. The code stops after any two packets whose command is either type, so two duplicate start packets can make it stop before the duration packet arrives and incorrectly report failure.

Problem

async_get_work_times() asks the multi-step executor to collect two notifications matching the set {0x84, 0x85}. The executor loops exactly twice and accepts either command on each iteration.

Relevant code:

• Work-time query requests two responses from a set of two command values
• The executor counts accepted messages, not distinct command values
• Work-time verification uses the same two-message collection approach

Why it happens

collect_count=2 expresses only a quantity. It cannot express the actual protocol requirement: “wait until one valid DAYE_RESPONSE_WORK_TIME_START and one valid DAYE_RESPONSE_WORK_TIME_DURATION have both been received.”

A notification sequence such as this is mishandled:

0x84, 0x84, 0x85

The first two messages satisfy the count. The method then combines them, finds no durations, and raises an error while the required 0x85 may already be on its way.

Duplicates can result from mower behavior, queued notifications, firmware retransmission, or an edge case around a weak/moving BLE connection.

Current behavior

• Duplicate responses consume collection slots.
• The first two matching packets end the wait even when they represent the same data type.
• The later required response is not considered.
• Query and write-verification paths can fail nondeterministically.

Expected behavior

For schedule operations, wait for a set of distinct required response commands:

required = {DAYE_RESPONSE_WORK_TIME_START, DAYE_RESPONSE_WORK_TIME_DURATION}
received = {}
while required - received.keys():
    message = await wait_for_next_valid_message(...)
    received[message["cmd"]] = message

Duplicates should be ignored or replace the earlier packet without satisfying another requirement. The whole operation should use one overall deadline so duplicate traffic cannot extend the wait indefinitely.

Impact

A user may see intermittent “missing start times or durations” errors even though the mower sent both packets. On a marginal Bluetooth link, this makes schedule reads and verification less reliable and can encourage unnecessary rewrites.

Suggested direction

Extend the multi-step response specification to support explicit required command sets rather than overloading expected_cmd plus collect_count.

Also drain or phase-tag stale messages before each request and validate complete frame structure before adding a response to the distinct-command map.

Acceptance criteria

• Sequences 0x84, 0x84, 0x85 and 0x85, 0x85, 0x84 both succeed.
• The first duplicate does not satisfy the missing response type.
• Responses may arrive in either order.
• A missing distinct response times out against one overall deadline.
• Query and write-verification paths share the corrected behavior.
• Tests include duplicates, stale packets, malformed packets, and reversed ordering.