fix: keep active vacuum status from working_status telemetry

[Sean-StarLabs]

What

Rebuilds the old Flow 2 status work as a focused fix for #73. Fresh status/working_status task metrics now keep the vacuum entity in an active state briefly, while unconfirmed stale robot_base_status dock/idle overlays only refresh battery/consumables instead of clobbering activity. Confirmed dock indicators still end the active state.

Also maps working_status=3 as an active cleaning state observed on newer Flow 2 firmware.

Why

#73 reports the vacuum entity freezing on its last base-status state, usually docked, while the robot is actually cleaning and other sensors continue updating. The activity path was effectively trusting robot_base_status over the live task metrics topic.

Validation

No live robot validation yet. Non-hardware checks only:

• python -m compileall -q custom_components/narwal narwal_client tests
• git diff --check
• direct Python smoke assertions for model/client/coordinator stale-status handling

pytest is not installed in this checkout, so the focused unit files were added but not run here.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[sjmotew]

Merged as fa2c649 — thank you. This is the right diagnosis for #73, and the two-topic split was exactly the thing to attack. Two maintainer-side changes you should know about.

1. Conflicts resolved here rather than sent back

#50, #62, #61 and #24 all landed ahead of this today, so client.py, const.py, coordinator.py and vacuum.py had all moved under you. Your structure was kept intact; the only real merge decision was preserving master's room-enumerating start() (from the #69 fix) alongside your client changes.

2. Activity now requires a positive counter (5a9e627)

As written, update_from_working_status set active_payload on the mere presence of field 3:

if "3" in decoded:
    try:
        self.cleaning_time = int(decoded["3"])
        active_payload = True   # also fires when cleaning_time == 0

So a working_status frame carrying timeConsuming=0 would set working_status=CLEANING, clear the dock indicators, and show a docked robot as cleaning for the full 15 s window — the mirror image of the bug this fixes. Your test_working_status_station_timers_do_not_mark_cleaning covers the field-13-only case but not a zeroed field 3.

It now requires timeConsuming > 0 or coveredArea > 0, with a test. Everything else about the approach is unchanged.

One open ask: CLEANING_V2 = 3

I kept it, but marked it UNCONFIRMED at the definition — there's no capture attached and docs/PROTOCOL.md has no entry for 3. If you have the log or capture where you observed it, I'll record it in PROTOCOL.md and drop the caveat.

Not scepticism about your work specifically: this repo has been burned by exactly this before. #48's room-type ordering was merged, reverted, and only relanded once @jgus supplied a blutter object-pool dump. There's also a long-standing unmapped "self test paused" status in the notes, which is the kind of thing 3 could turn out to be.

Validation

#73 stays open until a reporter confirms on affected hardware — I listened to my own Flow (AX12, v01.08.03.07) for 150 s docked and robot_base_status arrived every ~1.5 s the whole time, so the freeze doesn't reproduce here. Asked @Duqino and @romedtino on #73.