Get an Organisation's Devices
Get the list of all devices for the specified organization ID. By default returns ALL devices with ALL fields.
Optional parameters:
- device_type: Filter by specific device type (hp_atw, hp_wtw, inv, ev, wb)
- device_steering: Only devices that are steered (
on) or not (off) - manufacturer: Only devices whose model carries this manufacturer
- status: Only devices in one of these health tones (good, warning, critical, not_steered;
repeatable, unioned). Tones grade the connection/monitoring/steering trio, the same tones
…/devices/summarycounts — a device with a pending partner action is filtered under its trio’s tone while its owntonefield readsaction_required. - fields: Comma-separated list of specific fields (e.g., “id,owner.email,device_model.manufacturer”)
- page: Enable pagination by providing page number (1-based)
- page_size: Items per page when pagination is enabled (default: 100)
- sort: Order the whole fleet by
support,health,last_data(oldest first),owner,created_at(oldest first) ordevice(manufacturer and model);orderflips it. Unsorted, devices come back device type by device type.sort=supportranks the most pendingattention_requiredcues first;sort=healthranksunhealthy, thenunknown, first. - support: Only devices holding a pending cue of one of these Support categories (repeatable,
unioned;
none= of no category). - health: Only live devices with one of these service-health verdicts (repeatable, unioned).
Field examples:
- fields=id,owner.email,device_model.manufacturer
- fields=id,connection_status,monitoring_status,battery_level
Restricted to support and admins, plus Console Support agents reading across organisations.
Authorizations
Query Parameters
Response
One object per device, each matching its device type's schema (anyOf of the four). When the fields query parameter is set, every object is a partial projection carrying only the requested (dot-nested) fields.
- ElectricVehicleOutput
- HeatPumpOutput
- InverterOutput
- WallboxOutput
The device's console health tone, and the only verdict a client should render: action_required when a partner-resolvable action is pending, else the worst of connection and monitoring, with not_steered for a healthy device nobody optimizes. Do not re-derive it from connection_status/monitoring_status/steering_status — those three are cue-blind and would report a device asking for reauthentication as healthy. The status filter on GET /org/{org_id}/devices and the tone counts on …/devices/summary grade the three statuses only, so a device with a pending action reads action_required here while being counted and filtered under its status tone.
good, warning, critical, not_steered The device's service-health verdict: unhealthy when any component reads no, else healthy when any reads yes, else unknown. As of the last hourly sweep for heat pumps and electric vehicles; unknown until a new device is first swept; null when soft-deleted.
unhealthy, unknown, healthy What is happening with the vehicle now, as one value from a closed set. Render it as it is: the server decides it from the plug, the charge, the open session, its plan, whether HEMS drives the charge, the boost and pending owner actions, so a client must not re-derive it from other fields. The first value whose condition holds is served:
action_required: the owner must act before steering can work — the same condition astone = action_required.unknown: no reading says whether the cable is in.unplugged: the cable is not in.plugged_in: the cable is in and no charging session is open, or no other value applies.away_from_home: the open session is not at the home location, so it is not steered.smart_charging_off: the vehicle's current mode steers neither on prices nor on solar.boosting: a boost is requested, running or stopping (boost_state).solar_charging: HEMS drives the charge from surplus and the charge is observed. A solar top-up of a car already at its target reads this too.target_reached: the car is at its charge target and nothing in the session will charge it further. An owner who allows charging past the target lets a solar top-up or the car's own charge continue, so then this value is served only while neither can happen.waiting_for_solar: solar is steered, no charge is observed, and HEMS holds the charge or no price plan decides it.waiting_for_prices: the plan waits for the day-ahead prices it needs.planning: the session is open and its plan is not made yet.charging_planned: the plan charges later.smart_charging: the plan charges now and the charge is observed.starting: the plan charges now and no charge is observed yet.charging: the charge is observed and no plan decides it. The plan values (waiting_for_pricestostarting) are served while a price plan decides the charge. A live plan is served whatever the current mode says, because a running engine keeps the mode it started with until the vehicle is unplugged;planningis served only while the mode steers on prices. Switching steering off showssmart_charging_offat once. With both price and solar steering, a plan that still decides the charge wins over waiting for solar, except between two plan segments while HEMS holds the charge. A charge is observed when the vehicle reports it, or the wallbox its session is routed through does.nullfor a soft-deleted vehicle, which has no live state. The value is computed when it is read and is never stored. A client must map a value it does not know to the raw plug state.
action_required, unknown, unplugged, plugged_in, away_from_home, smart_charging_off, boosting, target_reached, solar_charging, waiting_for_solar, waiting_for_prices, planning, charging_planned, smart_charging, starting, charging Whether the platform is doing what it should for this vehicle, component by component, and where the problem starts when it is not. Every cell is a reading of state the evaluators already recorded, so a cell nothing has observed reads not_measured rather than a guess.
Deprecated — use GET /org/{org_id}/notifications/status for per-device-type counts, or GET /org/{org_id}/notifications/actions?device_id=… for the specifics. True when at least one action is pending against this device and the partner must take that action before the device can resume normal operation.
Event time of the last accepted canonical plug-state write, from any source (Smartcar telemetry, OCPP wire). The arbitration watermark: a claim whose evidence time is not newer than this is stale and does not write. NULL = no claim yet, so anything wins.
Pure boost lifecycle, shared by EVs and wallboxes (SC-154). Describes only the boost, not whether the device is charging — normal optimizer-driven charging is AVAILABLE (boostable), not ONGOING.
available, requested, unavailable, ongoing, stopping 