DYM mower-settings parser treats an unconfirmed reserved byte as the LED setting

[Bjorkan]

TL;DR

The library says byte 11 of a DYM settings response is the mower LED switch, but the repository's own captured DYM protocol documents bytes 10–18 as reserved. Home Assistant can therefore show a made-up LED value, usually “off,” from a byte that has not been proven to represent LED state.

Problem

The DYM 0x89 parser unconditionally maps payload[11] == 1 to mower_settings["led"]:

• Current DYM mower-settings parser
• The test suite locks in the unconfirmed LED field

However, the project's captured DYM protocol documentation defines only bytes 4–9 and records bytes 10–18 as reserved:

• Captured DYM 0x09/0x19/0x89 layout

The LED mapping exists in the APK-derived BlueKey response parser, where byte 12 is interpreted as LED. That does not prove that the DYM 0x89 reserved byte has the same meaning.

Why it happens

Fields from the APK's BlueKey settings layout appear to have been transferred to the HCI-confirmed DYM parser even though the two response layouts are separately documented and have different evidence levels.

Because captured DYM packets contain zero in the reserved range, the parser usually emits led=False. That looks like a valid confirmed value rather than “unknown.”

Current behavior

• Every valid-enough DYM 0x89 response contains a boolean led field.
• A zero reserved byte is presented as “LED off.”
• Home Assistant exposes this as a normal LED binary sensor.
• The value can be consumed by automations despite lacking protocol evidence.
• Tests verify the assumption instead of verifying the captured layout.

Expected behavior

DYM parsing should expose only fields confirmed for DYM packets.

Until a real hardware capture proves the LED byte:

• omit led from DYM 0x89 typed output;
• keep any reserved bytes available only as clearly named raw/reserved diagnostics;
• retain the LED field only in the BlueKey research parser where its evidence is documented;
• mark the Home Assistant LED entity unavailable or remove it for DYM devices.

If a capture later confirms the field, document the exact byte, values, firmware/model scope, and read/write behavior before reintroducing it.

Impact

Users may believe the integration can read or control a setting that has not actually been decoded. Automations can make decisions from a false False value, and future firmware use of the reserved byte could be misinterpreted as LED state.

Suggested direction

Separate protocol-confidence levels in the typed model. Confirmed DYM fields should not be inferred from APK-only BlueKey layouts. Add captured packet fixtures with provenance for every promoted setting.

Acceptance criteria

• DYM 0x89 responses no longer expose led without confirmed capture evidence.
• BlueKey parsing may continue to expose its separately documented LED field.
• Home Assistant does not show a false LED state for DYM responses.
• Tests distinguish DYM-confirmed fields from APK-derived research fields.
• Any future LED implementation includes a real read capture and, if writable, a matching write capture.