Triggered tasks

Some upkeep isn't periodic — it's a reaction to a condition: a battery dropping low, a water sensor going wet, a filter past its pressure threshold. A triggered task models exactly that. It has no schedule; an owning integration (for batteries, the companion Battery Notes glue) arms it when the condition becomes true and clears it when resolved.

• While armed, it reads as due now everywhere — the to-do list, the device's overdue sensor, the panel — with a "Managed by …" chip showing who owns it.
• When you replace/fix the thing (from either side), the task records the event and goes dormant: it leaves the to-do list and calendar and tucks into a collapsed "Monitored" section until it's next needed.
• Because the task persists across cycles, its completion history accumulates — so you learn the real cadence ("you replace this smoke-detector battery every ~13 months") instead of losing it on every replacement.

Integration-provided metadata chips (task_chips)

Integrations that push tasks into Home Keeper can attach metadata chips — compact labels with an optional icon and link — to communicate task-specific context at a glance. A battery integration, for example, attaches a chip like "2× AAA" to each replace-battery task so you know exactly what to buy before you open a drawer.

• What it solves: surface structured, integration-owned facts (battery type, filter model, part number, reorder link) directly on the task row and detail page, without cluttering the task notes or requiring the user to look elsewhere.
• How it works: the owning integration sets task_chips when calling home_keeper.add_task or home_keeper.update_task. Chips are shown in both the sidebar panel task list and the dashboard card. Users can't edit them — the integration owns them.
• Schema: each chip is {label, icon?, url?}. The icon must be an mdi: name; the URL must be http(s)://. An empty label is silently dropped.

Sync problem binary sensors as tasks

Lots of integrations already expose a binary_sensor with the problem device class — a leak detector, an appliance fault, a UPS on battery, a printer error. Turn on Sync problem sensors (Settings → Devices & services → Home Keeper → Configure) and Home Keeper automatically mirrors every one of them as a triggered task, so a real-world problem becomes a visible, trackable to-do without writing an automation.

• What it solves: one place that surfaces "something is wrong" across every integration — on the to-do list, the calendar, and the offending device's own page — instead of a problem sensor quietly flipping on where nobody looks.
• How it works: the task is armed while the sensor reports a problem and clears itself the moment the originating integration resolves it (the sensor goes back to OK). Because of that, these tasks can't be completed in Home Keeper — the problem has to be fixed for real — so the Done button is shown disabled, and tapping it pops up the reason (the detail page also explains how it clears). Each task inherits the sensor's device and area.
• Scope it: syncing is off by default; once on, exclude specific entities, devices, areas, or labels — from the panel's Settings tab (below) or the options flow. Excluding a device leaves out every problem sensor that belongs to it.
• Leave yourself a note for next time. These tasks don't map to a device you model, so there's a dedicated place to jot the fix: open the task and use Add a note to record what you want to remember the next time this problem fires — the steps that cleared it last time, a part number, where the shut-off valve is. The note sticks with the sensor: it survives the task clearing and re-arming, and even survives the mirror being removed and recreated (toggling problem-sensor sync off and on, or temporarily excluding the sensor), so it's waiting for you the next time the same problem goes off.

Tapping the disabled Done explains why it can't be completed here:

Add a durable note that reappears the next time the problem fires: