Update details of a user's electric vehicle
Modify the data of an electric vehicle related to a specific user under a specific organization, with a JSON payload.
Authorizations
Path Parameters
Body
How an EV's HEMS start/stop thresholds are determined (SC-137).
The preset modes derive the surplus start/stop band at session start from the
household PV size (kWp) and the actuation floor — see
core_app.services.smart_charging.thresholds.derive_preset_thresholds. The
stored raw threshold columns on ElectricVehicle are read only in CUSTOM
mode (or as fallback when no usable kWp is known).
EAGER - start on a small surplus fraction of kWp; tolerate more import. BALANCED - the default middle ground. CONSERVATIVE - start only on a large surplus; stop early on import. CUSTOM - the user/operator set the raw threshold columns explicitly.
eager, balanced, conservative, custom 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.
Response
OK
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