Work-time writes use 30 ms spacing although the official app waits about 300 ms

[Bjorkan]

TL;DR

The official mower app waits about 300 ms between the two schedule writes. pyGrouw waits only 30 ms, which can make the mower miss the second half of the schedule or return old values when the connection is slow.

Problem

Writing a weekly schedule requires two DYM commands:

1. 0x04 for start times;
2. 0x05 for durations.

The repository's own reverse-engineering notes state that the official app waits approximately 300 ms between these writes:

• Observed official-app timing

The implementation instead uses the global DEFAULT_CHUNK_DELAY, which is 30 ms:

• DEFAULT_CHUNK_DELAY = 0.03
• The 0x04, 0x05, and verification query steps all use that 30 ms delay
• The multi-step executor sleeps only the supplied delay before each write

Why it happens

A generic delay constant is reused for several protocol phases even though the captured app behavior shows that schedule writes have a much longer timing requirement.

With a local adapter, 30 ms may occasionally work. Through ESPHome Bluetooth proxies, the BLE operation also crosses Wi-Fi and Home Assistant before reaching the mower. More importantly, the mower firmware may need time to persist or process 0x04 before it accepts 0x05.

Current behavior

• pyGrouw waits 30 ms before the start-time write.
• It waits only another 30 ms before the duration write.
• It waits only 30 ms before querying the schedule for verification.
• If the mower has not committed both writes, verification can fail or return a mixture of old and new data.

Expected behavior

The implementation should follow the observed protocol timing rather than a generic chunk delay.

At minimum:

• wait approximately 300 ms between 0x04 and 0x05;
• use a separately named, protocol-specific settling delay before the verification query;
• document the timing and make it testable;
• avoid reducing the observed delay without hardware evidence.

Impact

Possible user-visible results include:

• start times update but durations do not;
• one day or one half of the schedule remains unchanged;
• the service raises “verification failed” even though a later query shows the write eventually completed;
• unreliable behavior varies by proxy, signal strength, and mower load.

Suggested direction

Create explicit constants such as:

DAYE_WORK_TIME_INTER_WRITE_DELAY = 0.3
DAYE_SETTINGS_VERIFY_DELAY = ...

Use monotonic timing in tests and keep the generic 30 ms delay only for phases where it has been validated.

Acceptance criteria

• A unit test verifies at least 300 ms spacing between the 0x04 and 0x05 writes.
• Verification is not sent until the configured settling period has elapsed.
• Schedule writes are tested through the same multi-step path used in production.
• The protocol documentation and implementation use the same timing values.