flexmeasures.api.v3_0.sensors

Classes

class flexmeasures.api.v3_0.sensors.SensorAPI

delete(id: int, sensor: Sensor)

Delete a sensor given its identifier.

This endpoint deletes an existing sensor, as well as all measurements recorded for it.

Reqheader Authorization:: The authentication token
Reqheader Content-Type:: application/json
Resheader Content-Type:: application/json
Status 204:: DELETED
Status 400:: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS
Status 401:: UNAUTHORIZED
Status 403:: INVALID_SENDER
Status 422:: UNPROCESSABLE_ENTITY

fetch_one(id, sensor)

Fetch a given sensor.

This endpoint gets a sensor.

Example response

{
    "name": "some gas sensor",
    "unit": "m³/h",
    "entity_address": "ea1.2023-08.localhost:fm1.1",
    "event_resolution": "PT10M",
    "generic_asset_id": 4,
    "timezone": "UTC",
    "id": 2
}

Reqheader Authorization:: The authentication token
Reqheader Content-Type:: application/json
Resheader Content-Type:: application/json
Status 200:: PROCESSED
Status 400:: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS
Status 401:: UNAUTHORIZED
Status 403:: INVALID_SENDER
Status 422:: UNPROCESSABLE_ENTITY

get_data(sensor_data_description: dict)

Get sensor data from FlexMeasures.

Example request

{
    "sensor": "ea1.2021-01.io.flexmeasures:fm1.1",
    "start": "2021-06-07T00:00:00+02:00",
    "duration": "PT1H",
    "resolution": "PT15M",
    "unit": "m³/h"
}

The unit has to be convertible from the sensor’s unit.

Optional fields

“resolution” (see Frequency and resolution)
“horizon” (see Tracking the recording time of beliefs)
“prior” (see Tracking the recording time of beliefs)
“source” (see Sources)

Reqheader Authorization:: The authentication token
Reqheader Content-Type:: application/json
Resheader Content-Type:: application/json
Status 200:: PROCESSED
Status 400:: INVALID_REQUEST
Status 401:: UNAUTHORIZED
Status 403:: INVALID_SENDER
Status 422:: UNPROCESSABLE_ENTITY

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

Get a schedule from FlexMeasures.

Optional fields

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

Example response

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

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

Reqheader Authorization:: The authentication token
Reqheader Content-Type:: application/json
Resheader Content-Type:: application/json
Status 200:: PROCESSED
Status 400:: INVALID_TIMEZONE, INVALID_DOMAIN, INVALID_UNIT, UNKNOWN_SCHEDULE, UNRECOGNIZED_CONNECTION_GROUP
Status 401:: UNAUTHORIZED
Status 403:: INVALID_SENDER
Status 405:: INVALID_METHOD
Status 422:: UNPROCESSABLE_ENTITY

index(account: Account)

API endpoint to list all sensors of an account.

This endpoint returns all accessible sensors. Accessible sensors are sensors in the same account as the current user. Only admins can use this endpoint to fetch sensors from a different account (by using the account_id query parameter).

Example response

An example of one sensor being returned:

[
    {
        "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
    }
]

Reqheader Authorization:: The authentication token
Reqheader Content-Type:: application/json
Resheader Content-Type:: application/json
Status 200:: PROCESSED
Status 400:: INVALID_REQUEST
Status 401:: UNAUTHORIZED
Status 403:: INVALID_SENDER
Status 422:: UNPROCESSABLE_ENTITY

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

Update a sensor given its identifier.

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.

Example request

{
    "name": "POWER",
}

Example response

The whole sensor is returned in the response:

{
    "name": "some gas sensor",
    "unit": "m³/h",
    "entity_address": "ea1.2023-08.localhost:fm1.1",
    "event_resolution": "PT10M",
    "generic_asset_id": 4,
    "timezone": "UTC",
    "id": 2
}

Reqheader Authorization:: The authentication token
Reqheader Content-Type:: application/json
Resheader Content-Type:: application/json
Status 200:: UPDATED
Status 400:: INVALID_REQUEST, REQUIRED_INFO_MISSING, UNEXPECTED_PARAMS
Status 401:: UNAUTHORIZED
Status 403:: INVALID_SENDER
Status 422:: UNPROCESSABLE_ENTITY

post(sensor_data: dict)

Create new asset.

This endpoint creates a new Sensor.

Example request

{
    "name": "power",
    "event_resolution": "PT1H",
    "unit": "kWh",
    "generic_asset_id": 1,
}

Example response

The whole sensor is returned in the response:

{
    "name": "power",
    "unit": "kWh",
    "entity_address": "ea1.2023-08.localhost:fm1.1",
    "event_resolution": "PT1H",
    "generic_asset_id": 1,
    "timezone": "UTC",
    "id": 2
}

Reqheader Authorization:: The authentication token
Reqheader Content-Type:: application/json
Resheader Content-Type:: application/json
Status 201:: CREATED
Status 400:: INVALID_REQUEST
Status 401:: UNAUTHORIZED
Status 403:: INVALID_SENDER
Status 422:: UNPROCESSABLE_ENTITY

post_data(bdf: BeliefsDataFrame)

Post sensor data to FlexMeasures.

Example request

{
    "sensor": "ea1.2021-01.io.flexmeasures:fm1.1",
    "values": [-11.28, -11.28, -11.28, -11.28],
    "start": "2021-06-07T00:00:00+02:00",
    "duration": "PT1H",
    "unit": "m³/h"
}

The above 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.

Reqheader Authorization:: The authentication token
Reqheader Content-Type:: application/json
Resheader Content-Type:: application/json
Status 200:: PROCESSED
Status 400:: INVALID_REQUEST
Status 401:: UNAUTHORIZED
Status 403:: INVALID_SENDER
Status 422:: UNPROCESSABLE_ENTITY

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, **kwargs)

Trigger FlexMeasures to create a schedule.

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 Describing flexibility. Below, we’ll also list some examples.

Note

This endpoint does not support to schedule an EMS with multiple flexible sensors at once. This will happen in another endpoint. See https://github.com/FlexMeasures/flexmeasures/issues/485. Until then, it is possible to call this endpoint for one flexible endpoint at a time (considering already scheduled sensors as inflexible).

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 max_planning_horizon_config, which defaults to 2520 steps of the sensor’s resolution. Targets that exceed the max planning horizon are not accepted.

The appropriate algorithm is chosen by FlexMeasures (based on asset type). It’s also possible to use custom schedulers and custom flexibility models, see Plugin Customizations.

If you have ideas for algorithms that should be part of FlexMeasures, let us know: https://flexmeasures.io/get-in-touch/

Example request A

This message triggers a schedule for a storage asset, starting at 10.00am, at which the state of charge (soc) is 12.1 kWh.

{
    "start": "2015-06-02T10:00:00+00:00",
    "flex-model": {
        "soc-at-start": 12.1,
        "soc-unit": "kWh"
    }
}

Example request B

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 and 15 (plus the flexible sensor being optimized, of course).

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

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

{
    "start": "2015-06-02T10:00:00+00:00",
    "duration": "PT24H",
    "flex-model": {
        "soc-at-start": 12.1,
        "soc-unit": "kWh",
        "soc-targets": [
            {
                "value": 25,
                "datetime": "2015-06-02T16:00:00+00:00"
            },
        ],
        "soc-minima": {"sensor" : 300},
        "soc-min": 10,
        "soc-max": 25,
        "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": "100kW",
        "site-production-capacity": "80kW",
        "site-consumption-capacity": {"sensor": 32}
    }
}

Example response

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>.

{
    "status": "PROCESSED",
    "schedule": "364bfd06-c1fa-430b-8d25-8f5a547651fb",
    "message": "Request has been processed."
}

Reqheader Authorization:: The authentication token
Reqheader Content-Type:: application/json
Resheader Content-Type:: application/json
Status 200:: PROCESSED
Status 400:: INVALID_DATA
Status 401:: UNAUTHORIZED
Status 403:: INVALID_SENDER
Status 405:: INVALID_METHOD
Status 422:: UNPROCESSABLE_ENTITY