We should implement the concept of Station in which we define a Station and relate to it Name, Location and credentials, so we can send readings from several sensors even using different devices, or just from one, depending on how we can implement each sensor.

We can also reduce the amount of data sent, as we wouldn't need to send the name and the location for each reading.

Also, we can send readings at different time windows.

See https://python-rq.org/ this would hugely improve how we can scale to more sensors.

The new /stats endpoint should also include these for all the other elements we measure.

Ideas:

• https://microservices.io/patterns/observability/health-check-api.html
• https://neo4j.com/docs/operations-manual/current/monitoring/causal-cluster/http-endpoints/#causal-clustering-http-endpoints-status

So that, by default, it won't dump the whole DB (by default).

See https://rald-dev.greenbeep.com/docs#/default/get_api_v1_measurements_get

Please join https://t.me/AireLibrePy so we can discuss how.

https://github.com/hrbonz/python-aqi

e.g. provide graphics similar to tools/plot.py via endpoints.

An endpoint with classic stats:

• N-days averages.
• N-days maximum.
• N-days minimum.
• etc.

The backend should be able to receive and store values for:

• Humidity: range from 0% to 100% (unsigned 3 digits)
• Temperature: -10 to 100 degree Celcius (estimated, signed float(3.2))
• Pressure: range 980 to 1030 hPa (unsigned 4 digits)

We're currently building the container locally before updating on prod, it would be better for us and others using linka, to publish the container to a registry.

We should (?) maintain a table (not necessarily a DB one) with the list of sensors we "support". Only so that we keep that list healthy (e.g. no different names for the exact same model), for later (e.g. queries).

The best way to do this would be to do it at schema level (see Measurement.sensor definition in app/schemas.py):

1. It will enforce the list at the API level, even before it reaches the DB, and it will give meaningful error to the client, basically for free because that is how FastAPI/Pydantic works.

2. It will automatically include that information in the autogenerated docs.

We could maintain a json file in data with the list of sensors, so we don't mix it with code, and simply load the list from schemas.py.