4 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	ecc59cc882	feat(homeassistant): a scheduled OS update reboots the machine and is done once the new version runs (#6755) ... Home Assistant writes an OS update and leaves the reboot to someone, so a scheduled one never finished unattended. The schedule now asks for the reboot once, follows it through Home Assistant going away, and counts it done when the Supervisor reports a different version with nothing pending. A machine that doesn't come back or falls back to the old version fails after 20 minutes, which ends the slot and raises update_failed. Install on the page and through MCP still leave the reboot to the person. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-01 19:15:03 -05:00
bvandeusenandClaude Opus 5.5	f7a856cb90	feat(homeassistant): it shows system problems and installs updates on a weekly slot, and leaves device readings alone (#6748, #6749, #6747) ... The connection's job is keeping Home Assistant running. Each poll now reads open repairs, Supervisor health, disk, recovery mode and add-ons that should be running over its websocket, for the page, the overview and the problems_open, disk_free_pct and update_failed metrics. That needs a websocket client, so websockets joins the dependencies. A weekly slot, set on the page or through MCP and off until then, installs add-ons, then Core, then the OS, each after its own confirmed backup, ending at the first failure. The slot arithmetic moves from the host agent's cadence to steward.core.weekly so both share it. The device scrape goes: the page's Metrics section and a target's token_from from 4c9ed02 are removed, and a migration deletes targets using it, as they'd otherwise ask with no token. A refused token still stops a scrape. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-01 14:16:42 -05:00
bvandeusenandClaude Opus 5.5	0aed863c67	feat(homeassistant): an admin signs in to Home Assistant, with nothing added to it (#6355) ... Replaces the read-only token and the webhook automation, which every install would have had to paste into its own Home Assistant. Connect now goes to Home Assistant's own sign-in page, and Steward keeps the refresh token that comes back, encrypted, and calls backup.create_automatic and update.install directly. The connection page warns that the stored credential has the same access as the user who signed in, and recommends a service account so Steward's actions are easy to tell apart in Home Assistant's logs. A user who isn't an administrator gets the status page and no Install. Those actions answer only when finished, so a request cut off once sent counts as sent and the outcome is read from the entities. Removing the connection, or signing in again, ends the old sign-in on Home Assistant. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-31 12:14:34 -04:00
bvandeusenandClaude Opus 5.5	b2a6e92ed3	feat(homeassistant): waiting updates, backup age, and updates installed after a confirmed backup (#6355) ... A new plugin reads Home Assistant with a read-only token every 5 minutes and shows which Core, OS and add-on updates are waiting and how old the last backup is. Install takes a backup through a local-only webhook, confirms Home Assistant's last-backup time moved, installs, and follows the update to its end, through Home Assistant's and Steward's own restarts. One runs at a time. Each ends as one timeline entry. Steward holds nothing that can act on the house: the webhook's automation can only take a backup or install an allowed update (System 231's ruling). A refused token stops polling, as Home Assistant bans an address after a few refusals. Milestone 576 steps 1 to 5. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-30 23:09:27 -04:00