Summary
After removing a device and re-pairing it in the same Shellbee session, the device's row showed greyed out, "Offline" with a red dot — and stayed that way until the app was force-quit and relaunched, at which point MQTT's retained <name>/availability message replayed and the row rendered correctly.
Root cause
AppStore.deviceAvailability[name] defaults to false when there's no entry, and DeviceRowView reads that value to decide between the offline badge and the live battery / LQI labels. After a successful interview, the only thing that could flip the entry to true was the <name>/availability MQTT publish — and on a remove + re-pair, that publish either lagged the interview-success event by several seconds or, on Z2M setups without availability tracking enabled, never arrived at all in the same session.
After app restart, MQTT replayed the retained "online" message on subscribe and the row corrected itself.
Fix (commit on dev)
In the device_interview event handler, when status is "successful" we also set deviceAvailability[friendlyName] = true. A successful interview means the device responded to Z2M, so it is online by definition at that moment. A later real <name>/availability publish still wins (true or false) and overrides the optimistic value.
Acceptance criteria
Summary
After removing a device and re-pairing it in the same Shellbee session, the device's row showed greyed out, "Offline" with a red dot — and stayed that way until the app was force-quit and relaunched, at which point MQTT's retained
<name>/availabilitymessage replayed and the row rendered correctly.Root cause
AppStore.deviceAvailability[name]defaults tofalsewhen there's no entry, andDeviceRowViewreads that value to decide between the offline badge and the live battery / LQI labels. After a successful interview, the only thing that could flip the entry totruewas the<name>/availabilityMQTT publish — and on a remove + re-pair, that publish either lagged the interview-success event by several seconds or, on Z2M setups without availability tracking enabled, never arrived at all in the same session.After app restart, MQTT replayed the retained "online" message on subscribe and the row corrected itself.
Fix (commit on
dev)In the
device_interviewevent handler, when status is"successful"we also setdeviceAvailability[friendlyName] = true. A successful interview means the device responded to Z2M, so it is online by definition at that moment. A later real<name>/availabilitypublish still wins (true or false) and overrides the optimistic value.Acceptance criteria
<name>/availabilitywithstate: "offline"overrides and the row goes red.