- 1 Connect
- 2 Request
- 3 Over time
- 4 Map the fields
Where the readings come from
The model knows where room 150 is. This is the service that knows what the temperature in it was at four o'clock.
What will be sent
What to ask it
Two requests are made: everything known about a room, and the readings
for one datapoint. {version} in a path is tried against
each version below until one answers.
On the metadata request
Every parameter it carries: the name this backend uses, and a value.
A value is sent as written, or carries {rooms} or
{language} to be filled in per request.
On the data request
The same, for one datapoint over a period.
A value is sent as written, or carries {id},
{from}, {to}, {fn},
{interval} or {unit}. One of them has to be
{id}, or every datapoint is asked for as the same one.
Where the rows are
What will be sent
One row, as it came back
Asking for a period
The map is one moment; the slider and the charts are a whole period, sampled. Same path, more to say — and every backend says it differently.
What it calls an aggregate
What it calls the units of the step
Try it
What will be sent
A placeholder still standing there is what varies: {id}
becomes each datapoint in turn, one request per datapoint. Name one
above and it appears here as it will be sent.
One reading, as it came back
Which field is which
The part no amount of guessing gets right. NEST puts the room number in
location_roomnr; the next API puts it somewhere else, and
only you know where. Anything left unmapped is simply absent.
In the model: which part of a space is the room number
By convention Name is the number and LongName
is what people call the room — A09 and Technik
HLKS. Plenty of files have it the other way round, and then asking
this backend for "Bedroom" finds nothing while room 111 sits there with
eighteen datapoints on it.