Get applied-mode history for a heat pump
The mode changes one heat pump was actually put into over a window, oldest first — the measured companion of the planned /schedules, drawn instead from the steering workflow’s own record of what it sent and what the manufacturer accepted. Each item is one change: the time it took effect, the mode, the channel it steered, and how much of it landed. Modes use the same four-value vocabulary as state on /schedules, so the two series can be read against each other over one window. A change is listed once the manufacturer accepted at least one of the writes behind it, and delivery says whether it accepted all of them; a command that landed nothing is not listed. Acceptance is not proof the pump moved — physical compliance is judged separately against telemetry. A repeated mode is the workflow re-asserting a lever that expires, not a new change. The window is half-open, both bounds are required, and it may span at most 31 days. History reaches back 30 days: the steering log this is read from drops older rows, so a window further back returns fewer changes than the pump had. Applied modes are recorded for the manufacturers steered by the Temporal workflows; an empty response means no change was recorded, never that the pump refused one.
Authorizations
The access token received from the authorization server in the OAuth 2.0 flow.
Path Parameters
The organization ID
The user ID the heat pump belongs to
The heat pump ID
Query Parameters
Inclusive lower bound on the effect time (ISO 8601, UTC)
Exclusive upper bound on the effect time (ISO 8601, UTC)
