Furo Docs
OperateTelemetrie-API

Get Schedule

GET
/v1/schedule

Fetch the current plan for a system.

Furo re-optimizes hourly at 15-minute resolution, so pull once per interval — polling faster returns the same plan. Keep following the last plan you fetched if a pull fails.

status says what the response is: ok carries periods; no_plan means the system is provisioned but has no valid plan right now (keep following the last one until the watchdog expires); released means Furo has handed control back (go to your default mode now). Only an unknown device_id is a 404.

What comes back

Plan-level, once per response:

FieldMeaning
statusok, no_plan or released — see above
control_enabledfalse while the system runs in test mode: read along, do not act
valid_untilend of the last interval; past it the plan is stale
watchdog_timeout_secondsfall back to your default mode when no pull has succeeded for this long
allow_battery_to_gridwhether the site may discharge into the grid; no period commands it otherwise
device_idthe system UUID the plan was fetched for
plan_id, created_atthe optimization run behind the plan and when Furo computed it; null when status is not ok
resolution_minuteslength of one interval

Per quarter hour, in periods:

FieldMeaning
timestampstart of the interval, UTC
casethe energy-flow case the optimizer planned, e.g. grid_to_battery
battery_setpoint_kwsigned battery setpoint — positive charges, negative discharges, 0 holds; null = no setpoint, self-consume within the limits
battery_max_charge_kw, battery_max_discharge_kwcaps that always bind; 0 blocks that direction
nap_max_import_kw, nap_max_export_kwgrid limits for this interval; they take precedence over the setpoint
strategydirect_command (follow the setpoint), self_consumption or peak_shaving
battery_charge_kw, battery_discharge_kw, grid_import_kw, grid_export_kw, soc_percent, storage_fill_kwh, pv_curtailment_kwthe optimizer plan the values above were derived from

All power values are kW, 15-minute means, two non-negative directions except the signed setpoint. The caps and grid limits always bind, whatever the setpoint says.

Note the timestamps: a period's timestamp is the start of its interval, while a telemetry timestamp marks the end of the interval it measured.

Authorization

APIKeyHeader
X-API-Key<token>

In: header

Query Parameters

device_id*Device Id
Formatuuid

Response Body

application/json

application/json

curl -X GET "https://example.com/v1/schedule?device_id=497f6eca-6276-4993-bfeb-53cbbbba6f08"
{  "device_id": "3bafab7b-4400-4bcf-8e6e-09f954699940",  "status": "ok",  "control_enabled": true,  "plan_id": "string",  "created_at": "2019-08-24T14:15:22Z",  "valid_until": "2019-08-24T14:15:22Z",  "resolution_minutes": 0,  "watchdog_timeout_seconds": 0,  "allow_battery_to_grid": true,  "periods": []}