Steps to reproduce
Use the openSenseMap API to get all boxes with certain criteria using the /boxes endpoint. Example:
https://api.opensensemap.org/boxes?bbox=7.4,51.85,7.82,52.05
Now, look, at the sensors of a senseBox.
Expected result
Like the /boxes/:boxId endpoint, the sensors should contain the fields lastMeasurement.createdAt and lastMeasurement.value.
Actual result
The sensors all contain only the lastMeasurement field with an arbitrary string attached to them. Example: "lastMeasurement":"5636a41ab3de1fe005eb170f"
Discussion
It is not clear to me whether this behaviour is intentional. While there are possible reasons to not return sensor values (e.g. heavy server load), it is not mentioned anywhere in the documentation.
Also, this is not a severe problem, since the sensor values can still be accessed by making individual requests to each box. However, this increases the load on the client by requiring hundreds of requests to the individual boxes.
Steps to reproduce
Use the openSenseMap API to get all boxes with certain criteria using the
/boxesendpoint. Example:https://api.opensensemap.org/boxes?bbox=7.4,51.85,7.82,52.05Now, look, at the sensors of a senseBox.
Expected result
Like the
/boxes/:boxIdendpoint, the sensors should contain the fieldslastMeasurement.createdAtandlastMeasurement.value.Actual result
The sensors all contain only the
lastMeasurementfield with an arbitrary string attached to them. Example:"lastMeasurement":"5636a41ab3de1fe005eb170f"Discussion
It is not clear to me whether this behaviour is intentional. While there are possible reasons to not return sensor values (e.g. heavy server load), it is not mentioned anywhere in the documentation.
Also, this is not a severe problem, since the sensor values can still be accessed by making individual requests to each box. However, this increases the load on the client by requiring hundreds of requests to the individual boxes.