Care Portal Task Lists: Incomplete Count and Item Status

Care Portal Task Lists can display a compact number while retaining a much richer collection of items. In Home Assistant, that number has a documented meaning: it counts incomplete entries. It is not a count of all historical entries, visits by staff, or actions performed by a physical care robot. This article reads a hypothetical household support dashboard appendix. It accesses no account, changes no task, and makes no claim about a person's care or a machine's activity.

Read the entity state as an incomplete count

The official To-do list integration documentation says that the state of a to-do list entity is the number of incomplete items in the list. The same page identifies unavailable and unknown states separately. A reviewer should retain those labels instead of replacing a missing or unavailable value with a count of zero.

Consider a hypothetical appendix showing zero incomplete entries. This establishes what the submitted state label means, assuming its source is correctly identified. It does not establish that the stored collection has no completed entries. Nor does it show how an item became completed. The dashboard number alone cannot distinguish an empty collection from one containing only completed items.

Keep each item's status separate from its text

The official developer documentation for to-do entities describes a list of TodoItem objects. Each returned item needs an identifier, summary, and status. Its status vocabulary includes NEEDS_ACTION and COMPLETED. The summary names the entry; it is not a substitute for the status field. A sentence phrased in the past tense should not be counted as completed merely because it sounds finished.

For example, a fictional item called “robot supply check” might remain open even if someone rewrote its summary. Conversely, marking an item completed does not supply evidence that a physical inspection occurred. Those are questions about the workflow and its evidence. The entity vocabulary records a software list state, not an independent observation of household activity.

Unknown collection information has its own meaning

The developer page says that todo_items can be None when the list is not known, and that the entity state is unknown in that situation. This matters when an exported attachment leaves out the list contents. A missing collection should not silently become an empty list in the review narrative. Preserve whether the contributor actually supplied items or only a compact state.

A hypothetical handover may therefore contain two differently scoped attachments: an entity-state excerpt and an item-level export. Ask which source produced each and whether their capture times match. A count from one moment and item statuses from another need not describe the same collection. This article does not reconcile a real export or infer why a particular source is unavailable.

Separate supported list features from performed work

The developer documentation defines supported-feature flags for creating, deleting, updating, and moving entries, as well as optional due-date and description features. It also notes that a list without supported modification features is read only. A feature description concerns what an integration exposes. It is not evidence that a contributor used it or that an associated robot carried out the text of an entry.

That distinction is useful in a care-portal procurement appendix. If a supplier says the system can update tasks, ask which integration and feature declaration the statement refers to. If it says a task was completed, ask for the actual item record and the separately agreed evidence for that activity. Capability and occurrence should have distinct source references.

A clear review note can identify the entity, source integration, capture time, incomplete count, and available item-level records. It can then describe unresolved differences without declaring that all support work has been delivered. Changing the presentation of the count does not change the historical evidence. A later item update should retain its own time context rather than being read back into an earlier screenshot.

Due information is another independent part of the item. The developer page allows a due date or a timezone-aware due datetime, and a separate completed datetime describes when it was last marked completed. These fields should retain their documented identities. A due date does not establish that a task was done on that date, and a completion marker does not establish when a person received assistance. No real dates or personal schedules are evaluated here.

The two original illustrations show a conceptual reading sequence and the different scopes of a count and an item record. They contain no household data or actual completion figures. Continue through the care device documentation section and related resources section. The practical result is a more precise question: what does this list record say, and what separate material supports the real activity named by its entries?