Skip to content

Commit

Permalink
Issue 389 publish sensor data api documentation (#390)
Browse files Browse the repository at this point in the history 
Start API v3. Implement v3_0 endpoints /sensors [GET], /sensors/data [GET] and refactor an existing dev endpoint to become /sensors/data [POST], using modern authorization and marshmallow schemas. Also update tutorials for getting started and for posting sensor data, as well as the API introduction for v3_0 of the API.


* Move sensor data API from dev to v2 and use flask-classful

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Publish dev API

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add quickrefs

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add type annotations

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Refactor use of auth_required in SensorAPI

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add type annotations

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add more quickrefs

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Indentation

Signed-off-by: F.N. Claessen <felix@seita.nl>

* valid JSON, rather than a python dict

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Move import to its preferred position

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Rename and add type annotation

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Allow AssetIdField and SensorIdField to be used for API requests, too, besides for CLI scripts

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update tutorial for posting data

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Implement [GET] sensorData

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add example GET request

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update docstring for unit conversion

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Respect the passed horizon and prior fields

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Convert NaN to null (otherwise invalid JSON)

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Pass event resolution to enable additional unit conversions

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Smarter unit conversion for BeliefsSeries

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Revert to auth_token_required instead of login_required

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Deserialize to BeliefsDataFrame using post_load decorator, and run through post_load decorators in a specific sequence

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Move serialization logic to schema

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Fix tutorial for posting data

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Introduce util function to check for a valid price unit

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Comment out tutorial sections on posting data for multiple connections at once

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update tutorial for posting data: change connection to sensor and stop mentioning separate endpoints for postMeterData and postPrognosis

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add validation based on POST message type

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Publish documentation for SensorDataAPI

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add validation based on GET message type

Signed-off-by: F.N. Claessen <felix@seita.nl>

* mypy

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update getting-started.rst

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Undoc old endpoints

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Rename with_appcontext_if_needed

Signed-off-by: F.N. Claessen <felix@seita.nl>

* refactor auth logic - separate checking access from the permission_required_for_context decorator

Signed-off-by: Nicolas Höning <nicolas@seita.nl>

* add modern auth for sensor data get & post, remove checking account role auth

Signed-off-by: Nicolas Höning <nicolas@seita.nl>

* more freedom to create inside accounts: allow all account members to create on generic assets and sensors

Signed-off-by: Nicolas Höning <nicolas@seita.nl>

* use  a user from the same account as the sensor for sensor data tests

Signed-off-by: Nicolas Höning <nicolas@seita.nl>

* adapt asset tests w.r.t. to a change in dev api conftest

Signed-off-by: Nicolas Höning <nicolas@seita.nl>

* Remove unneeded import

Signed-off-by: F.N. Claessen <felix@seita.nl>

* GET endpoints work for logged-in users when tried in the browser with auth_required but not with auth_token_required

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add docstring

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Make type a required field

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Move @route to top

Signed-off-by: F.N. Claessen <felix@seita.nl>

* SensorDataDescriptionSchema doesn't need the `type` field

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Revert "Undoc old endpoints"

This reverts commit 852bee8.

* Move sensor data API documentation to v3

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Move sensor data API to v3

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Move user API to class for v3

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Move user UI to v3

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update user API tests

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Move user API tests to v3 module

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Separate view for user index

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Fix test

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update documentation tutorials to v3

Signed-off-by: F.N. Claessen <felix@seita.nl>

* No trailing slash

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Make `type` field in v3

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add v3 to API index

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update introduction

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Fix comment about where to request auth token

Signed-off-by: F.N. Claessen <felix@seita.nl>

* flake8

Signed-off-by: F.N. Claessen <felix@seita.nl>

* black

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Revert some documentation changes that are ahead of code changes

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Use one common base route

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Prefer plural base route

Signed-off-by: F.N. Claessen <felix@seita.nl>

* different shade of black

Signed-off-by: F.N. Claessen <felix@seita.nl>

* typos

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Transition SensorDataAPI:post to SensorAPI:post_data and SensorDataAPI:get to SensorAPI:get_data

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Rename module

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update documentation for moving from SensorDataAPI:post to SensorAPI:post_data

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update introduction

Signed-off-by: F.N. Claessen <felix@seita.nl>

* API changelog entry

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Implement /sensors [GET] to replace getConnection

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Complete docstring

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add extra tips to API changelog on how to upgrade from v2 to v3

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Fix check for belief timing against message type

Signed-off-by: F.N. Claessen <felix@seita.nl>

* No need to use implementations folder anymore

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Contain endpoint logic within SensorAPI class

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Contain endpoint logic within UserAPI class

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Fix mock email and type annotations

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Initialize schemas within SensorAPI and UserAPI class

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Typos

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Fix 404 error message

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Remove unused variable declaration

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Clarify use of headers in test

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Concerning patching user ids and user account ids, set dump_only for these fields instead of ignoring them

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add test cases for unexpected fields

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Also move patch endpoint logic into UserAPI class; this one was a bit more tricky, because the 'id' fields was being passed to the function twice somehow; use_kwargs instead of use_args was needed to avoid this

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Move test utils from dev to v3_0

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Finish moving sensor data tests from dev to v3_0

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Fix asset tests in dev API by moving back some conftest logic

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Instantiate schemas outside of endpoint logic to minimize response time

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Add mentions of http status to docstrings

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Undocument getService from the API introduction

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Undocument USEF roles in introduction

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Use "sensor" instead of "connection" in introduction

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Undocument group notation in introduction

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update API changelog for rewrite of introduction

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Update API changelog entry date

Signed-off-by: F.N. Claessen <felix@seita.nl>

Co-authored-by: Nicolas Höning <nicolas@seita.nl>
  • Loading branch information
@Flix6x @nhoening
Flix6x and nhoening committed Mar 22, 2022
1 parent f24c82d commit 5a3e592
Show file tree
Hide file tree
Showing 49 changed files with 1,149 additions and 526 deletions.
33 changes: 29 additions & 4 deletions documentation/api/change_log.rst
View file
Expand Up @@ -6,6 +6,31 @@ API change log
.. note:: The FlexMeasures API follows its own versioning scheme. This is also reflected in the URL, allowing developers to upgrade at their own pace.


v3.0-0 | 2022-03-22
"""""""""""""""""""

- Added REST endpoint for listing sensors: `/sensors` (GET).
- Added REST endpoint for managing sensor data: `/sensors/data` (GET, POST).
- [**Breaking change**] Switched to plural resource names for REST endpoints: `/users/<id>` (GET, PATCH) and `/users/<id>/password-reset` (PATCH).
- [**Breaking change**] Deprecated the following endpoints:

- *getConnection* -> use `/sensors` (GET) instead
- *getMeterData* -> use `/sensors/data` (GET) instead, replacing the "connection" field with "sensor"
- *getPrognosis* -> use `/sensors/data` (GET) instead, replacing the "connection" field with "sensor"
- *getService*
- *postMeterData* -> use `/sensors/data` (POST) instead, replacing the "connection" field with "sensor"
- *postPriceData* -> use `/sensors/data` (POST) instead, replacing the "market" field with "sensor"
- *postPrognosis* -> use `/sensors/data` (POST) instead, replacing the "connection" field with "sensor"
- *postWeatherData* -> use `/sensors/data` (POST) instead
- *restoreData*

- Changed the Introduction section:

- Rewrote the section on service listing for API versions to refer to the public documentation.
- Rewrote the section on entity addresses to refer to *sensors* instead of *connections*.
- Rewrote the sections on roles and sources into a combined section that refers to account roles rather than USEF roles.
- Deprecated the section on group notation.

v2.0-4 | 2022-01-04
"""""""""""""""""""

Expand Down Expand Up @@ -42,12 +67,12 @@ v2.0-2 | 2021-04-02
v2.0-1 | 2021-02-19
"""""""""""""""""""

- REST endpoints for managing users: `/users/` (GET), `/user/<id>` (GET, PATCH) and `/user/<id>/password-reset` (PATCH).
- Added REST endpoints for managing users: `/users/` (GET), `/user/<id>` (GET, PATCH) and `/user/<id>/password-reset` (PATCH).

v2.0-0 | 2020-11-14
"""""""""""""""""""

- REST endpoints for managing assets: `/assets/` (GET, POST) and `/asset/<id>` (GET, PATCH, DELETE).
- Added REST endpoints for managing assets: `/assets/` (GET, POST) and `/asset/<id>` (GET, PATCH, DELETE).


v1.3-11 | 2022-01-05
Expand Down Expand Up @@ -80,7 +105,7 @@ v1.3-8 | 2020-04-02

*Affects all versions since v1.0*.

- [**Breaking change**, partially reverted in v1.3-9] Deprecated the automatic inference of horizons for *postMeterData*, *postPrognosis*, *postPriceData* and *postWeatherData* endpoints for API version below v2.0.
- [**Breaking change**, partially reverted in v1.3-9] Deprecated the automatic inference of horizons for *postMeterData*, *postPrognosis*, *postPriceData* and *postWeatherData* endpoints for API versions below v2.0.

v1.3-7 | 2020-12-16
"""""""""""""""""""
Expand All @@ -107,7 +132,7 @@ v1.3-5 | 2020-10-29
- Endpoints to POST meter data will now check incoming data to see if the required asset's resolution is being used ― upsampling is done if possible.
These endpoints can now return the REQUIRED_INFO_MISSING status 400 response.
- Endpoints to GET meter data will return data in the asset's resolution ― downsampling to the "resolution" field is done if possible.
- As they need to determine the asset, all of the mentioned POST and GET endpoints can now return the UNRECOGNIZED_ASSET status 4000 response.
- As they need to determine the asset, all of the mentioned POST and GET endpoints can now return the UNRECOGNIZED_ASSET status 400 response.

v1.3-4 | 2020-06-18
"""""""""""""""""""
Expand Down
22 changes: 22 additions & 0 deletions documentation/api/dev.rst
View file
@@ -0,0 +1,22 @@
.. _dev:

Developer API
=============

These endpoints are still under development and are subject to change in new releases.

Summary
-------

.. qrefflask:: flexmeasures.app:create(env="documentation")
:modules: flexmeasures.api.dev.assets, flexmeasures.api.dev.sensors
:order: path
:include-empty-docstring:

API Details
-----------

.. autoflask:: flexmeasures.app:create(env="documentation")
:modules: flexmeasures.api.dev.assets, flexmeasures.api.dev.sensors
:order: path
:include-empty-docstring:
161 changes: 30 additions & 131 deletions documentation/api/introduction.rst
View file
Expand Up @@ -23,13 +23,13 @@ So if you are running FlexMeasures on your computer, it would be:

https://localhost:5000/api

At Seita, we run servers for our clients at:
Let's assume we are running a server for a client at:

.. code-block:: html

https://company.flexmeasures.io/api

where `company` is a hosting customer of ours. All their accounts' data lives on that server.
where `company` is a client of ours. All their accounts' data lives on that server.

We assume in this document that the FlexMeasures instance you want to connect to is hosted at https://company.flexmeasures.io.

Expand All @@ -40,50 +40,20 @@ Let's see what the ``/api`` endpoint returns:
>>> import requests
>>> res = requests.get("https://company.flexmeasures.io/api")
>>> res.json()
{'flexmeasures_version': '0.4.0',
'message': 'For these API versions a public endpoint is available, listing its service. For example: /api/v1/getService and /api/v1_1/getService. An authentication token can be requested at: /api/requestAuthToken',
{'flexmeasures_version': '0.9.0',
'message': 'For these API versions endpoints are available. An authentication token can be requested at: /api/requestAuthToken. For a list of services, see https://flexmeasures.readthedocs.io',
'status': 200,
'versions': ['v1', 'v1_1', 'v1_2', 'v1_3', 'v2_0']
'versions': ['v1', 'v1_1', 'v1_2', 'v1_3', 'v2_0', 'v3_0']
}
So this tells us which API versions exist. For instance, we know that the latest API version is available at
So this tells us which API versions exist. For instance, we know that the latest API version is available at:

.. code-block:: html

https://company.flexmeasures.io/api/v2_0
https://company.flexmeasures.io/api/v3_0


Also, we can see that a list of endpoints which are available at (a version of) the FlexMeasures web service can be obtained by sending a ``getService`` request. An optional field "access" can be used to specify a user role for which to obtain only the relevant services.

**Example request**

Let's ask which endpoints are available for meter data companies (MDC):

.. code-block:: html

https://company.flexmeasures.io/api/v2_0/getService?access=MDC


**Example response**

.. code-block:: json
{
"type": "GetServiceResponse",
"version": "1.0",
"services": [
{
"name": "getMeterData",
"access": ["Aggregator", "Supplier", "MDC", "DSO", "Prosumer", "ESCo"],
"description": "Request meter reading"
},
{
"name": "postMeterData",
"access": ["MDC"],
"description": "Send meter reading"
}
]
}
Also, we can see that a list of endpoints is available on https://flexmeasures.readthedocs.io for each of these versions.

.. _api_auth:

Expand Down Expand Up @@ -131,28 +101,13 @@ which gives a response like this if the credentials are correct:
.. note:: Each access token has a limited lifetime, see :ref:`auth`.


Roles
-----

We distinguish the following roles with different access rights to the individual services. Capitalised roles are defined by USEF:

- public
- user
- admin
- Aggregator
- Supplier: an energy retailer (see :ref:`supplier`)
- Prosumer: owner of a grid connection (see :ref:`prosumer`)
- ESCo: an energy service company (see :ref:`esco`)
- MDC: a meter data company (see :ref:`mdc`)
- DSO: a distribution system operator (see :ref:`dso`)

.. _sources:

Sources
-------

Requests for data may limit the data selection by specifying a source, for example, a specific user.
USEF roles are also valid source selectors.
Account roles are also valid source selectors.
For example, to obtain data originating from either a meter data company or user 42, include the following:

.. code-block:: json
Expand All @@ -161,6 +116,8 @@ For example, to obtain data originating from either a meter data company or user
"sources": ["MDC", "42"],
}
Here, "MDC" is the name of the account role for meter data companies.

Notation
--------
All requests and responses to and from the web service should be valid JSON messages.
Expand All @@ -179,27 +136,26 @@ Throughout this document, keys are written in singular if a single value is list
The API, however, does not distinguish between singular and plural key notation.

Connections and entity addresses
Sensors and entity addresses
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A connection represents an end point of the grid, at which an electricity sensor (power meter) is located.
Connections should be identified with an entity address following the EA1 addressing scheme prescribed by USEF[1],
which is mostly taken from IETF RFC 3720 [2]:
All sensors are identified with an entity address following the EA1 addressing scheme prescribed by USEF[1],
which is mostly taken from IETF RFC 3720 [2].

This is the complete structure of an EA1 address:

.. code-block:: json
{
"connection": "ea1.{date code}.{reversed domain name}:{locally unique string}"
"sensor": "ea1.{date code}.{reversed domain name}:{locally unique string}"
}
Here is a full example for a FlexMeasures connection address:
Here is a full example for an entity address of a sensor in FlexMeasures:

.. code-block:: json
{
"connection": "ea1.2021-02.io.flexmeasures.company:fm1.73"
"sensor": "ea1.2021-02.io.flexmeasures.company:fm1.73"
}
where FlexMeasures runs at `company.flexmeasures.io` (which the current domain owner started using in February 2021), and the locally unique string uses the `fm1` scheme (see below) to identify sensor ID 73.
Expand Down Expand Up @@ -254,7 +210,7 @@ It uses the fact that all FlexMeasures sensors have unique IDs.
.. todo:: UDI events are not yet modelled in the fm1 scheme

The ``fm0`` scheme is the original scheme.
It identified different types of sensors (such as connections, weather sensors and markets) in different ways.
It identified different types of sensors (such as grid connections, weather sensors and markets) in different ways.
The ``fm0`` scheme has been deprecated for the most part and is no longer supported officially.
Only UDI events still need to be sent using the fm0 scheme.

Expand All @@ -264,69 +220,6 @@ Only UDI events still need to be sent using the fm0 scheme.
ea1.2021-01.io.flexmeasures:fm0.<owner_id>:<sensor_id>:<event_id>:<event_type>
Groups
^^^^^^

Data such as measurements, load prognoses and tariffs are usually stated per group of connections.
When the attributes "start", "duration" and "unit" are stated outside of "groups" they are inherited by each of the individual groups. For example:

.. code-block:: json
{
"groups": [
{
"connections": [
"ea1.2021-02.io.flexmeasures.company:fm1.71",
"ea1.2021-02.io.flexmeasures.company:fm1.72"
],
"values": [
306.66,
306.66,
0,
0,
306.66,
306.66
]
},
{
"connection": "ea1.2021-02.io.flexmeasures.company:fm1.73"
"values": [
306.66,
0,
0,
0,
306.66,
306.66
]
}
],
"start": "2016-05-01T12:45:00Z",
"duration": "PT1H30M",
"unit": "MW"
}
In case of a single group of connections, the message may be flattened to:

.. code-block:: json
{
"connections": [
"ea1.2021-02.io.flexmeasures.company:fm1.71",
"ea1.2021-02.io.flexmeasures.company:fm1.72"
],
"values": [
306.66,
306.66,
0,
0,
306.66,
306.66
],
"start": "2016-05-01T12:45:00Z",
"duration": "PT1H30M",
"unit": "MW"
}
Timeseries
^^^^^^^^^^

Expand Down Expand Up @@ -374,10 +267,10 @@ Technically, this is equal to:
This intuitive convention allows us to reduce communication by sending univariate timeseries as arrays.

Notation for v1
"""""""""""""""
Notation for v1, v2 and v3
""""""""""""""""""""""""""

For version 1 and 2 of the API, only equidistant timeseries data is expected to be communicated. Therefore:
For version 1, 2 and 3 of the API, only equidistant timeseries data is expected to be communicated. Therefore:

- only the array notation should be used (first notation from above),
- "start" should be a timestamp on the hour or a multiple of the sensor resolution thereafter (e.g. "16:10" works if the resolution is 5 minutes), and
Expand Down Expand Up @@ -496,19 +389,25 @@ Resolutions

Specifying a resolution is redundant for POST requests that contain both "values" and a "duration" ― FlexMeasures computes the resolution by dividing the duration by the number of values.

When POSTing data, FlexMeasures checks this computed resolution against the required resolution of the assets which are posted to. If these can't be matched (through upsampling), an error will occur.
When POSTing data, FlexMeasures checks this computed resolution against the required resolution of the sensors which are posted to. If these can't be matched (through upsampling), an error will occur.

GET requests (such as *getMeterData*) return data in the resolution which the sensor is configured for.
A "resolution" may be specified explicitly to obtain the data in downsampled form,
which can be very beneficial for download speed. The specified resolution needs to be a multiple
of the asset's resolution, e.g. hourly or daily values if the asset's resolution is 15 minutes.
of the sensor's resolution, e.g. hourly or daily values if the sensor's resolution is 15 minutes.

.. _units:

Units
^^^^^

Valid units for timeseries data in version 1 of the API are "MW" only.
From API version 3 onwards, we are much more flexible with sent units.
A valid unit for timeseries data is any unit that is convertible to the configured sensor unit registered in FlexMeasures.
So, for example, you can send timeseries data with "W" unit to a "kW" sensor.
And if you wish to do so, you can even send a timeseries with "kWh" unit to a "kW" sensor.
In this case, FlexMeasures will convert the data using the resolution of the timeseries.

For API versions 1 and 2, the unit sent needs to be an exact match with the sensor unit, and only "MW" is allowed for power sensors.

.. _signs:

Expand Down
20 changes: 20 additions & 0 deletions documentation/api/v3_0.rst
View file
@@ -0,0 +1,20 @@
.. _v3_0:

Version 3.0
===========

Summary
-------

.. qrefflask:: flexmeasures.app:create(env="documentation")
:modules: flexmeasures.api.v3_0.implementations.sensors, flexmeasures.api.v3_0.implementations.users
:order: path
:include-empty-docstring:

API Details
-----------

.. autoflask:: flexmeasures.app:create(env="documentation")
:modules: flexmeasures.api.v3_0.implementations.sensors, flexmeasures.api.v3_0.implementations.users
:order: path
:include-empty-docstring:
2 changes: 1 addition & 1 deletion documentation/getting-started.rst
View file
Expand Up @@ -195,7 +195,7 @@ First, you can load in data from a file (CSV or Excel) via the ``flexmeasures``
This assumes you have a file `my-data.csv` with measurements, which was exported from some legacy database, and that the data is about our sensor with ID 1. This command has many options, so do use its ``--help`` function.

Second, you can use the `POST /api/v2_0/postMeterData <api/v2_0.html#post--api-v2_0-postMeterData>`_ endpoint in the FlexMeasures API to send meter data.
Second, you can use the `POST /api/v3_0/sensors/data <api/v3_0.html#post--api-v3_0-sensors-data>`_ endpoint in the FlexMeasures API to send meter data.

Finally, you can tell FlexMeasures to create forecasts for your meter data with the ``flexmeasures add forecasts`` command, here is an example:

Expand Down
2 changes: 2 additions & 0 deletions documentation/index.rst
View file
Expand Up @@ -128,11 +128,13 @@ The platform operator of FlexMeasures can be an Aggregator.
:maxdepth: 1

api/introduction
api/v3_0
api/v2_0
api/v1_3
api/v1_2
api/v1_1
api/v1
api/dev
api/change_log

.. toctree::
Expand Down

0 comments on commit 5a3e592

Please sign in to comment.