flexmeasures.api.v3_0.sensors

Classes

class flexmeasures.api.v3_0.sensors.SensorAPI
check_forecasts(sensor: Sensor, job_id: str)

— get:

summary: Check forecast job status for a sensor and fetch results. description: |

Returns the status of a previously triggered forecasting job. When the job is completed successfully, this endpoint returns the generated forecast data.

responses:
200:

description: Forecast job status content:

application/json:
example:

status: “FINISHED” forecast:

sensor: 2092 values: […] start: “2025-10-15T00:00:00+01:00” end: “2025-10-16T00:00:00+01:00”

tags:

  • Sensors

delete(id: int, sensor: Sensor)

Delete a sensor given its identifier. .. :quickref: Sensors; Delete a sensor — delete:

summary: Delete a sensor description: This endpoint deletes an existing sensor, as well as all measurements recorded for it. security:

  • ApiKeyAuth: []

parameters:

  • in: path name: id description: ID of the sensor to delete. schema: SensorId

responses:
204:

description: DELETED

400:

description: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

delete_data(id: int, sensor: Sensor)

— delete:

summary: Delete sensor data description: This endpoint deletes all data for a sensor. security:

  • ApiKeyAuth: []

parameters:

  • name: id in: path description: ID of the sensor to delete data for. required: true schema: SensorId

responses:
204:

description: SENSOR_DATA_DELETED

400:

description: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

fetch_one(id, sensor: Sensor)

— get:

summary: Fetch a given sensor description: Fetch a given sensor by its ID. security:

  • ApiKeyAuth: []

parameters:

  • in: path name: id description: ID of the sensor to fetch. schema: SensorId

responses:
200:

description: One Sensor content:

application/json:

schema: SensorSchema examples:

price_sensor:

summary: A day-ahead price sensor recording 15-minute prices. description: |

A day-ahead price sensor recording the day-ahead electricity price in EUR/kWh with a 15-minute resolution. The sensor is assigned to asset 1. Data from this sensor will be shown with offsets corresponding to the Europe/Amsterdam timezone.

value:

id: 14 name: day-ahead electricity price unit: EUR/kWh timezone: Europe/Amsterdam event_resolution: PT15M entity_address: ea1.2021-01.io.flexmeasures:fm1.14 generic_asset_id: 1

power_sensor:

summary: A power sensor recording average consumption every 5 minutes. description: |

A power sensor recording average power flow in kW with a 5-minute resolution. The sensor records consumption as positive values. It is assigned to asset 1. Data from this sensor will be shown with offsets corresponding to the Europe/Amsterdam timezone.

value:

id: 5 name: power unit: kW timezone: Europe/Amsterdam event_resolution: PT5M entity_address: ea1.2021-01.io.flexmeasures:fm1.5 attributes:

consumption_is_positive: true

generic_asset_id: 1

400:

description: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

get_data(id: int, **sensor_data_description: dict)

— get:

summary: Get sensor data description: |

The unit has to be convertible from the sensor’s unit - e.g. you ask for kW, and the sensor’s unit is MW.

Optional parameters:

An example query to fetch data for sensor with ID=1, for one hour starting June 7th 2021 at midnight, in 15 minute intervals, in m³/h:

?start=2021-06-07T00:00:00+02:00&duration=PT1H&resolution=PT15M&unit=m³/h

(you will probably need to escape the + in the timezone offset, depending on your HTTP client, and other characters like here in the unit, as well).

> Note: This endpoint also accepts the query parameters as part of the JSON body. That is not conform to REST architecture, but it is easier for some developers.

security:

  • ApiKeyAuth: []

parameters:

  • name: id in: path required: true schema: SensorId

  • in: query schema: SensorDataTimingDescriptionSchema

responses:
200:

description: PROCESSED

400:

description: INVALID_REQUEST

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

get_schedule(sensor: Sensor, job_id: str, duration: timedelta, **kwargs)

— get:

summary: Get schedule for one device description: |

Get a schedule from FlexMeasures.

Optional fields:

  • “duration” (6 hours by default; can be increased to plan further into the future)

security:

  • ApiKeyAuth: []

parameters:

  • in: path name: id required: true description: ID of the sensor for which to retrieve the schedule. example: 5 schema:

    type: int

  • in: path name: uuid required: true description: UUID of the scheduling job, which was returned by the [Sensor scheduling endpoint](#/Sensors/post_api_v3_0_sensors__id__schedules_trigger) or the [Assets scheduling endpoint](#/Assets/post_api_v3_0_assets__id__schedules_trigger). example: 5d28df1b-9f16-4177-ae43-6e750d80fad3 schema:

    type: string

  • in: query name: duration required: false description: |

    Duration of the schedule to retrieve. If omitted, the default is 6 hours. The maximum allowed value is limited by the FLEXMEASURES_PLANNING_HORIZON configuration option (default: 48 hours). While a full-horizon schedule is available, it is usually not useful to fetch it entirely. A better approach is to request only the near-term part of the schedule, and to refresh the schedule as new information becomes relevant.

    example: PT24H schema:

    type: string

responses:
200:

description: PROCESSED content:

application/json:
schema:

type: object properties:

scheduler_info:

type: object description: Information about the scheduler that executed the job. additionalProperties: true

values:

type: array items:

type: number

description: The scheduled values as a list of floats.

start:

type: string format: date-time description: Start time of the schedule (ISO 8601).

duration:

type: string description: Duration covered by the schedule, expressed as an ISO 8601 duration.

unit:

type: string description: Unit of the schedule’s values.

status:

type: string enum: [“PROCESSED”] description: Processing status of the request.

message:

type: string description: Human-readable message about request processing.

examples:
schedule:

summary: Schedule response description: |

This message contains a schedule indicating to consume at various power rates from 10am UTC onward for a duration of 45 minutes.

value:

values: [2.15, 3, 2] start: “2015-06-02T10:00:00+00:00” duration: “PT45M” unit: “MW”

400:

description: INVALID_TIMEZONE, INVALID_DOMAIN, INVALID_UNIT, UNKNOWN_SCHEDULE, UNRECOGNIZED_CONNECTION_GROUP

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

405:

description: INVALID_METHOD

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

get_stats(id, sensor: Sensor, event_start_time: str, event_end_time: str, sort_keys: bool)

— get:

summary: Get sensor stats description: This endpoint fetches sensor stats for all the historical data. security:

  • ApiKeyAuth: []

parameters:

  • in: path name: id description: ID of the sensor to fetch stats for. schema: SensorId

  • in: query name: event_start_time description: Start of the period to fetch stats for, in ISO 8601 format. schema:

    type: string format: date-time

  • in: query name: event_end_time description: End of the period to fetch stats for, in ISO 8601 format. schema:

    type: string format: date-time

  • in: query name: sort_keys description: Whether to sort the stats by keys. schema:

    type: boolean

responses:
200:

description: PROCESSED content:

application/json:
examples:
successful_response:

summary: Successful response description: A successful response with sensor stats value:

“some data source”:

“First event start”: “2015-06-02T10:00:00+00:00” “Last event end”: “2015-10-02T10:00:00+00:00” “Last recorded”: “2015-10-02T10:01:12+00:00” “Min value”: 0.0 “Max value”: 100.0 “Mean value”: 50.0 “Sum over values”: 500.0 “Number of values”: 10

400:

description: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

get_status(id, sensor)

— get:

summary: Get sensor status description: |

This endpoint fetches the current status of data for the specified sensor. The status includes information about the sensor data’s status, staleness and resolution.

security:

  • ApiKeyAuth: []

parameters:

  • in: path name: id description: ID of the sensor to fetch status for. schema: SensorId

responses:
200:

description: PROCESSED content:

application/json:
examples:
successful_response:

summary: Successful response description: A successful response with sensor status data value:

  • staleness: “2 hours” stale: true staleness_since: “2024-01-15T14:30:00+00:00” reason: “data is outdated” source_type: “forecast” id: 64907 name: “temperature” resolution: “5 minutes” asset_name: “Building A” relation: “sensor belongs to this asset”

400:

description: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

404:

description: ASSET_NOT_FOUND

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

index(account: Account | None = None, asset: GenericAsset | None = None, include_consultancy_clients: bool = False, include_public_assets: bool = False, page: int | None = None, per_page: int | None = None, filter: list[str] | None = None, unit: str | None = None)

— get:

summary: Get list of sensors description: |

This endpoint returns all accessible sensors. By default, “accessible sensors” means all sensors in the same account as the current user (if they have read permission to the account).

You can also specify an account (an ID parameter), if the user has read access to that account. In this case, all assets under the specified account will be retrieved, and the sensors associated with these assets will be returned.

Alternatively, you can filter by asset hierarchy by providing the asset parameter (ID). When this is set, all sensors on the specified asset and its sub-assets are retrieved, provided the user has read access to the asset.

> Note: You can’t set both account and asset at the same time, you can only have one set. The only exception is if the asset being specified is > part of the account that was set, then we allow to see sensors under that asset but then ignore the account (account = None).

Finally, you can use the include_consultancy_clients parameter to include sensors from accounts for which the current user account is a consultant. This is only possible if the user has the role of a consultant.

Only admins can use this endpoint to fetch sensors from a different account (by using the account_id query parameter).

The filter parameter allows you to search for sensors by name or account name. The unit parameter allows you to filter by unit.

For the pagination of the sensor list, you can use the page and per_page query parameters, the page parameter is used to trigger pagination, and the per_page parameter is used to specify the number of records per page. The default value for page is 1 and for per_page is 10.

security:

  • ApiKeyAuth: []

parameters:

  • in: query schema: SensorKwargsSchema

responses:
200:

description: PROCESSED - List of sensors (paginated or direct list) content:

application/json:
schema:
oneOf:

  • type: array description: Direct list when no pagination requested items: Sensor

  • type: object description: Paginated response properties:

    data:

    type: array items: Sensor

    num-records:

    type: integer description: Total number of records in query result

    filtered-records:

    type: integer description: Total number of records after filtering and pagination

    required:

    • data

    • num-records

    • filtered-records

examples:
direct_list:

summary: Direct sensor list description: Example of direct response with one sensor value:

data:

  • entity_address: “ea1.2021-01.io.flexmeasures.company:fm1.42” event_resolution: “PT15M” generic_asset_id: 1 name: “Gas demand” timezone: “Europe/Amsterdam” unit: “m³/h” id: 2

paginated_response:

summary: Paginated sensor list description: Example of paginated response with one sensor value:

data:

  • entity_address: “ea1.2021-01.io.flexmeasures.company:fm1.42” event_resolution: “PT15M” generic_asset_id: 1 name: “Gas demand” timezone: “Europe/Amsterdam” unit: “m³/h” id: 2

num-records: 1 filtered-records: 1

400:

description: INVALID_REQUEST

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

patch(sensor_data: dict, id: int, sensor: Sensor)

— patch:

summary: Update a sensor description: |

This endpoint updates the descriptive data of an existing sensor.

Any subset of sensor fields can be sent. However, the following fields are not allowed to be updated: - id - generic_asset_id - entity_address

Only admin users have rights to update the sensor fields. Be aware that changing unit, event resolution and knowledge horizon should currently only be done on sensors without existing belief data (to avoid a serious mismatch), or if you really know what you are doing.

security:

  • ApiKeyAuth: []

parameters:

  • in: path name: id description: ID of the sensor to update. schema: SensorId

requestBody:
content:
application/json:

schema: SensorSchema examples:

update_sensor:

summary: Update sensor name description: Update the name of a sensor value:

“name”: “POWER”

responses:
200:

description: Updated Sensor content:

application/json:

schema: SensorSchema examples:

update_sensor:

summary: Update sensor name description: Update the name of a sensor value:

“name”: “POWER” “unit”: “m³/h” “entity_address”: “ea1.2023-08.localhost:fm1.1” “event_resolution”: “PT10M” “generic_asset_id”: 4 “timezone”: “UTC” “id”: 2

400:

description: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

post(sensor_data: dict)

— post:

summary: Create a new Sensor description: This endpoint creates a new sensor for a given asset. security:

  • ApiKeyAuth: []

requestBody:
content:
application/json:

schema: SensorSchema examples:

create_sensor:

summary: Create power sensor description: Create a power sensor for an asset value:

“name”: “power” “event_resolution”: “PT1H” “unit”: “kWh” “generic_asset_id”: 1

responses:
201:

description: New Sensor content:

application/json:

schema: SensorSchema examples:

create_sensor:

summary: Power sensor response description: The whole sensor is returned in the response value:

“name”: “power” “unit”: “kWh” “entity_address”: “ea1.2023-08.localhost:fm1.1” “event_resolution”: “PT1H” “generic_asset_id”: 1 “timezone”: “UTC” “id”: 2

400:

description: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

post_data(id: int, bdf: BeliefsDataFrame)

— post:

summary: Post sensor data description: |

Send data values via JSON, where the duration and number of values determine the resolution.

The example request posts four values for a duration of one hour, where the first event start is at the given start time, and subsequent events start in 15 minute intervals throughout the one hour duration.

The sensor is the one with ID=1. The unit has to be convertible to the sensor’s unit. The resolution of the data has to match the sensor’s required resolution, but FlexMeasures will attempt to upsample lower resolutions. The list of values may include null values.

security:

  • ApiAuthKey: []

parameters:

  • name: id in: path required: true schema: SensorId

requestBody:
content:
application/json:

schema: PostSensorDataSchema examples:

post_sensor:

summary: Post sensor data to FlexMeasures value:

“values”: [-11.28, -11.28, -11.28, -11.28] “start”: “2021-06-07T00:00:00+02:00” “duration”: “PT1H” “unit”: “m³/h”

responses:
200:

description: PROCESSED

400:

description: INVALID_REQUEST

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

trigger_forecast(sensor: Sensor)

— post:

summary: Trigger forecasting job for one sensor description: |

Launch a forecasting pipeline for the given sensor asynchronously. This reuses the same validation as the CLI command flexmeasures add forecasts.

Example: ``` {

“start_date”: “2026-01-01T00:00:00+01:00”, “start_predict_date”: “2026-01-15T00:00:00+01:00”, “end_date”: “2026-01-17T00:00:00+01:00”

responses:
200:

description: Forecasting job queued content:

application/json:
example:

status: “PROCESSED” forecast_jobs: [“b3d26a8a-7a43-4a9f-93e1-fc2a869ea97b”] message: “Forecasting job has been queued.”

tags:

  • Sensors

trigger_schedule(sensor: Sensor, start_of_schedule: datetime, duration: timedelta, belief_time: datetime | None = None, flex_model: dict | None = None, flex_context: dict | None = None, force_new_job_creation: bool | None = False, **kwargs)

— post:

summary: Trigger scheduling job for one device description: |

Trigger FlexMeasures to create a schedule for this sensor. The assumption is that this sensor is the power sensor on a flexible asset.

In this request, you can describe:

  • the schedule’s main features (when does it start, what unit should it report, prior to what time can we assume knowledge)

  • the flexibility model for the sensor (state and constraint variables, e.g. current state of charge of a battery, or connection capacity)

  • the flexibility context which the sensor operates in (other sensors under the same EMS which are relevant, e.g. prices)

For details on flexibility model and context, see the [documentation on describing flexibility](https://flexmeasures.readthedocs.io/latest/features/scheduling.html#describing-flexibility). The schemas we use in this endpoint documentation do not describe the full flexibility model and context (as the docs do), as these are very flexible (e.g. fixed values or sensors). The examples below illustrate how to describe a flexibility model and context.

> Note: To schedule an EMS with multiple flexible sensors at once, > use the [Assets scheduling endpoint](#/Assets/post_api_v3_0_assets__id__schedules_trigger) instead.

About the duration of the schedule and targets within the schedule:

  • The length of the schedule can be set explicitly through the ‘duration’ field.

  • Otherwise, it is set by the config setting FLEXMEASURES_PLANNING_HORIZON, which defaults to 48 hours.

  • If the flex-model contains targets that lie beyond the planning horizon, the length of the schedule is extended to accommodate them.

  • Finally, the schedule length is limited by the config setting FLEXMEASURES_MAX_PLANNING_HORIZON, which defaults to 2520 steps of the sensor’s resolution. Targets that exceed the max planning horizon are not accepted.

About the scheduling algorithm being used:

security:

  • ApiKeyAuth: []

parameters:

  • name: id in: path required: true schema: SensorId

requestBody:

required: true content:

application/json:

schema: TriggerScheduleKwargsSchema examples:

simple_schedule:

summary: Simple storage schedule description: |

This message triggers a schedule for a storage asset, starting at 10.00am, at which time the state of charge (soc) is 12.1 kWh. The asset is further limited by a maximum soc of 25 kWh. The optimization is done with reference to a fixed price for consumption.

This is close to the minimal set of information that needs to be provided to trigger a schedule. It requires no external data series, like dynamic prices in a sensor - look to the complex example for that. Obviously, the outcome of this scheduling problem will be as bland as the input.

value:

start: “2025-06-02T10:00:00+00:00” flex-context:

consumption-price: “.2 EUR/kWh”

flex-model:

soc-at-start: “12.1 kWh” soc-max: “25 kWh”

complex_schedule:

summary: Complex 24-hour schedule description: |

In this complex example, let’s really show off a lot of potential configurations.

This message triggers a 24-hour schedule for a storage asset, starting at 10.00am, at which the state of charge (soc) is 12.1 kWh, with a target state of charge of 25 kWh at 4.00pm.

The charging efficiency is constant (120%) and the discharging efficiency is determined by the contents of sensor with id 98. If just the roundtrip-efficiency is known, it can be described with its own field. The global minimum and maximum soc are set to 10 and 25 kWh, respectively.

To guarantee a minimum SOC in the period prior, the sensor with ID 300 contains beliefs at 2.00pm and 3.00pm, for 15kWh and 20kWh, respectively. Storage efficiency is set to 99.99%, denoting the state of charge left after each time step equal to the sensor’s resolution. Aggregate consumption (of all devices within this EMS) should be priced by sensor 9, and aggregate production should be priced by sensor 10, where the aggregate power flow in the EMS is described by the sum over sensors 13, 14, 15, and the power sensor of the flexible device being optimized (referenced in the endpoint URL).

The battery consumption power capacity is limited by sensor 42 and the production capacity is constant (30 kW).

Finally, the (contractual and physical) situation of the site is part of the flex-context. The site has a physical power capacity of 100 kVA, but the production capacity is limited to 80 kW, while the consumption capacity is limited by a dynamic capacity contract whose values are recorded under sensor 32. Breaching either capacity is penalized heavily in the optimization problem, with a price of 1000 EUR/kW. Finally, peaks over 50 kW in either direction are penalized with a price of 260 EUR/MW.

These penalties can be used to steer the schedule into a certain behavior (e.g. avoiding breaches and peaks), even if no direct financial impacts are expected at the given prices in the real world.

For example, site owners may be requested by their network operators to reduce stress on the grid, be it explicitly or under a social contract.

Note that, if forecasts for sensors 13, 14 and 15 are not available, a schedule cannot be computed.

value:

start: “2015-06-02T10:00:00+00:00” duration: “PT24H” flex-model:

soc-at-start: “12.1 kWh” state-of-charge:

sensor: 24

soc-targets:

  • value: “25 kWh” datetime: “2015-06-02T16:00:00+00:00”

soc-minima:

sensor: 300

soc-min: “10 kWh” soc-max: “25 kWh” charging-efficiency: “120%” discharging-efficiency:

sensor: 98

storage-efficiency: 0.9999 power-capacity: “25kW” consumption-capacity:

sensor: 42

production-capacity: “30 kW”

flex-context:
consumption-price:

sensor: 9

production-price:

sensor: 10

inflexible-device-sensors: [13, 14, 15] site-power-capacity: “100 kVA” site-production-capacity: “80 kW” site-consumption-capacity:

sensor: 32

site-production-breach-price: “1000 EUR/kW” site-consumption-breach-price: “1000 EUR/kW” site-peak-consumption: “50 kW” site-peak-production: “50 kW” site-peak-consumption-price: “260 EUR/MW” site-peak-production-price: “260 EUR/MW”

responses:
200:

description: PROCESSED content:

application/json:
schema:

type: object

examples:
schedule_created:

summary: Schedule response description: |

This message indicates that the scheduling request has been processed without any error. A scheduling job has been created with some Universally Unique Identifier (UUID), which will be picked up by a worker. The given UUID may be used to obtain the resulting schedule: see /sensors/<id>/schedules/<uuid>.

value:

status: “PROCESSED” schedule: “364bfd06-c1fa-430b-8d25-8f5a547651fb” message: “Request has been processed.”

400:

description: INVALID_DATA

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

405:

description: INVALID_METHOD

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

upload_data(data: list[BeliefsDataFrame], filenames: list[str], **kwargs)

— post:

summary: Upload sensor data by file description: |

The file should have columns for a timestamp (event_start) and a value (event_value). The timestamp should be in ISO 8601 format. The value should be a numeric value.

The unit has to be convertible to the sensor’s unit. The resolution of the data has to match the sensor’s required resolution, but FlexMeasures will attempt to upsample lower resolutions. The list of values may include null values.

security:

  • ApiKeyAuth: []

parameters:

  • name: id in: path required: true schema: SensorId

requestBody:
content:
multipart/form-data:

schema: SensorDataFileDescriptionSchema encoding:

uploaded-files:

contentType: application/octet-stream

responses:
200:

description: PROCESSED content:

application/json:
schema:

type: object

examples:
new_data:

summary: New data description: |

If the data sent is new and is not already processed by FlexMeasures, the response will be as above.

value:

message: “Request has been processed.” status: “PROCESSED”

processed_previously_received:

summary: Previously received data description: |

If some of the data sent was already received and successfully processed by FlexMeasures, the response will be as above. Note that in this case, the data is still processed, but the already received data points are ignored.

value:

message: “Some of the data has already been received and successfully processed.” results: “PROCESSED” status: “ALREADY_RECEIVED_AND_SUCCESSFULLY_PROCESSED”

returned_graph_data:

summary: Returned graph data description: |

Example of how the processed data may be returned.

value:
data:

  • ts: 1759669200000 sid: 3 val: 12.4 sf: 1.0 src: 1 bh: -427962881

sensors:
“3”:

name: “TempSensor_A1X” unit: “°C” description: “TempSensor_A1X (toy-account)” asset_id: 1 asset_description: “toy-account”

sources:
“1”:

name: “toy-user” model: “” type: “other” description: “toy-user”

400:

description: INVALID_REQUEST

401:

description: UNAUTHORIZED

403:

description: INVALID_SENDER

422:

description: UNPROCESSABLE_ENTITY

tags:

  • Sensors

class flexmeasures.api.v3_0.sensors.SensorKwargsSchema(*, only: types.StrSequenceOrSet | None = None, exclude: types.StrSequenceOrSet = (), many: bool | None = None, context: dict | None = None, load_only: types.StrSequenceOrSet = (), dump_only: types.StrSequenceOrSet = (), partial: bool | types.StrSequenceOrSet | None = None, unknown: str | None = None)
class flexmeasures.api.v3_0.sensors.TriggerScheduleKwargsSchema(*, only: types.StrSequenceOrSet | None = None, exclude: types.StrSequenceOrSet = (), many: bool | None = None, context: dict | None = None, load_only: types.StrSequenceOrSet = (), dump_only: types.StrSequenceOrSet = (), partial: bool | types.StrSequenceOrSet | None = None, unknown: str | None = None)