HTTP JSON Sensor Data
Version vom 1. April 2021, 12:53 Uhr von Mb (Diskussion | Beiträge)
Preface
- all Sensor data is available in a generic JSON Object presentet by status.json
- there are two relevant sub-objects: sensor_values and sensor_descr
- sensor_descr can tell:
- what sensor types are actually relevent
- what is type-specifiv sensor-field descripton
- how many sensors of each type are actually present
- what are the names of each of those sensors
- sensor_values tells you about the sensor values, matching the description explained above
- it's common practice to get sensor_descr+sensor_values once, and poll sensor_values only subsequently
This might look complicated at first glance, but this empowerers you to write small code handling all Prodzuts and all Sensors in one single approach, without the need for sensor specific knowlege. So your software is already prepared for new Gude-Devices, and prepared for new Sensor Add-Ons. As example, this documentation will highly depend on check_gude.py, our HTTP sensor data swiss-knife tool.
- HTTP-Get status.json?components=8470528
- here, 8470528 sums up sensor_values (16384 aka 0x10000) plus sensor_descr (65536 aka 0x4000), plus the ‘extended’ marker (0x800000) to get both simple sensors and complex sensor groups
- 0x4000 + 0x10000 + 0x800000 = 8470528
A sensor description might look like this:
[ { "type": 664, "num": 2, "fields": [ {"name": "Voltage", "unit": "V", "decPrecision": 3}, {"name": "Current", "unit": "A", "decPrecision": 1} ] "properties": [ { "id": "L1", "name": "Meter1", "state": 1}, { "id": "L2", "name": "Meter2", "state": 1}, ] }, { "type": 665, "num": 1, "fields": [ {"name": "Temperature", "unit": "C", "decPrecision": 1}, {"name": "Humidity", "unit": "%", "decPrecision": 1} ] "properties": [ { "id": "6102", "name": "Server-Rack", "state": 1} ] } ]