Sensor-based tasks

Some maintenance isn't measured in time but in use: oil every 15,000 km, a service every 500 running hours, descale after 50 cycles — or it's a reaction to a reading crossing a limit: replace the filter when airflow drops below 60 %, check coolant when temperature climbs above 90 °C. A sensor-based task binds a task to an existing numeric Home Assistant entity and lets Home Keeper arm it for you — no automation to wire up.

Pick Based on a sensor on the task form, choose the sensor, and pick a mode:

• Usage / meter — set a target. Home Keeper records the reading when you create the task (its baseline, again each time you complete it), and the task becomes due once the meter has advanced by target units since then. The target counts usage from the current reading — not from zero — so it doesn't matter that your sensor is already partway up. Example: your printer's run-hours sensor reads 660 h and you set a target of 100; Home Keeper anchors at 660, so the task first becomes due at 760 h, and the detail reads "0 of 100 used" until then. Completing it "resets the counter" (re-anchors at whatever the sensor reads at that moment) just like a floating task resets its clock — so the next one is due 100 h later again. If the meter is reset or the part is replaced (the reading drops below the baseline), Home Keeper re-anchors automatically so it never gets stuck. Great for odometers, runtime-hours, and cycle counters.

  Where the numbers show up. As you fill in the form, a live hint reads your chosen sensor and spells this out — "This sensor reads 660 h now. The task becomes due at 760 h, then every 100 h after each completion." — and a ? by the form title links here. So you can see exactly when the task will first come due before you save it.

• Threshold — set a comparison (≥ ≤ > < = ≠) and a value, with an optional hold (the reading must stay across the line that many seconds, to debounce noise) and an optional attribute (read e.g. a climate entity's current_temperature instead of its state). The task arms on the crossing and stays due until you complete it — a filter you need to replace doesn't un-need replacing if airflow briefly recovers — then re-arms only on a fresh crossing.

A sensor task behaves like any other once armed: it shows on the to-do list and calendar, lights the device's overdue sensor, and fires the home_keeper_task_overdue event. While waiting it reads as Monitored, and the task detail shows live progress ("12,300 of 15,000 used" for a meter, or the current reading vs. the limit). You can also create one from automations/scripts with the home_keeper.add_task service by passing a sensor mapping.

Link a task to a consumable (auto-reorder)

A maintenance task often uses up a spare you keep on hand — a fridge water filter, an HVAC filter, a brita cartridge. Home Keeper lets you link any task to an appliance consumable so that marking the task done draws down one spare from that part's stock, and — when stock crosses the reorder-at threshold — fires a home_keeper_part_low_stock event so an automation can add it to your shopping list. The link is independent of the auto-generated wear-part tasks, so the task stays a normal, fully-editable task.

This is what makes the "there's no schedule — my fridge tells me when the filter is spent" case work end to end: create a sensor-based task bound to the fridge's filter-life (or water-usage) entity, then link it to the filter consumable. The fridge arms the task; when you swap the filter and mark it done, Home Keeper subtracts a spare and tells you to buy more once you're low.

Pick the consumable from the Linked consumable dropdown on the task form. It's scoped to the appliance the task is attached to (via Attach to device) — so you only see that appliance's spares, not every consumable in the house. (Attach the task to the appliance first; if the appliance has no consumables, the picker doesn't appear.) Or use the home_keeper.set_task_consumable service (omit the ids to unlink). The task detail then shows the linked part and its current stock.