feat(ambient): emit recovery_failing health signal for the core alert - #42
Merged
Conversation
…re alert When auto-recovery is armed, the health JSON now carries recovery_failing, failed_reboot_count, device_dark_since (ISO), and last_reboot_error so the Genesis core can alert when the device has been dark past the escalation threshold AND the reboot attempts couldn't restore it. Restart-safe: the since-seen counter + last-seen are persisted (survives a bridge restart mid-wedge). last_reboot_error is a SANITIZED classification (exception class name / fixed phrase) — the device IP/PSK is logged locally only, never emitted. reboot_device now returns (ok, error); adds recovery_escalation_dark_s (4h) and recovery_escalation_min_reboots (1) knobs. Keys are absent when recovery is disabled, so installs without recovery are unchanged. Refs: e6e68d70 (ambient silent-dark escalation) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
When device auto-recovery is armed, the ambient bridge now emits a
recovery_failingverdict intoambient_health.jsonso the Genesis core can alertwhen auto-recovery has engaged but still can't restore the capture device.
New health-JSON keys (present only when recovery is armed — absent otherwise, so
installs without recovery are byte-unchanged):
recovery_failing(bool) — True once the device has been dark ≥recovery_escalation_dark_s(default 4h, comfortably past the reboot window sorecovery has definitively stopped trying) and ≥
recovery_escalation_min_rebootsreboot attempts since it was last seen failed to bring it back.
failed_reboot_count,device_dark_since(ISO),last_reboot_error.Details
RecoveryStatetracks a persistedreboots_since_seencounter + last error,reset on reconnect (
mark_seen) — so the signal is restart-safe (survives abridge restart mid-wedge; keyed off the persisted last-seen, not the in-process
connection timer).
reboot_devicenow returns(ok, error). The error is a sanitizedclassification (a fixed phrase or the exception class name) — the device IP and
the noise PSK are logged locally only and never placed on the health JSON, which
is surfaced onward to the dashboard.
AMBIENT_RECOVERY_ESCALATION_DARK_S(14400),AMBIENT_RECOVERY_ESCALATION_MIN_REBOOTS(1). State files written before thischange load with sane defaults (0 / None).
Tests
test_esphome_recovery.pyextended: the(ok, error)contract + sanitized-errorassertions (no IP in the returned reason), the
recovery_statustruth table,counter reset/persistence across a restart, and back-compat loading. Full file
green; ruff clean.
🤖 Generated with Claude Code