HTTP JSON Sensor Data - Versionsgeschichte

Ps am 23. Juni 2025 um 12:43 Uhr

2025-06-23T12:43:50Z

2025-06-23T12:41:29Z

2022-11-16T07:36:31Z

Getting data by HTTP

2022-02-11T13:57:12Z

Common sensor type IDs

2021-11-29T15:54:29Z

2021-11-17T11:55:25Z

2021-05-25T11:58:43Z

Getting data by HTTP

2021-04-06T16:35:18Z

Expert Power Control 8291

2021-04-06T16:29:47Z

show CGI-Get / JSON Data

2021-04-06T16:18:07Z

Preface

@@ Zeile 94: / Zeile 94: @@
   Bender RCMB Module
-−
   Line power meter                  (only 3-Phase EPC 87-3300)
   Neutral Current                   (only 3-Phase EPC 87-3300)
-−
   DC outlet measurement             (only EPC 8291-2 R2 PDUs)

@@ Zeile 94: / Zeile 94: @@
   Bender RCMB Module
   System Data (sensor group)
@@ Zeile 101: / Zeile 106: @@
   Temperature/Humidity/AirPressure Sensor
-  Bank (eFuses Port-groups) Sensor  (e.g. used at 8291 PDUs)
+  Bank (eFuses Port-groups) Sensor  (only EPC 8291 PDUs)
-  (DC) Power Sources                (e.g. used at 8291 PDUs)
+  (DC) Power Sources                (only EPC 8291 PDUs)
 = check_gude.py in action =

@@ Zeile 23: / Zeile 23: @@
 *HTTP-Get '''status.json?components=8470528'''
 **for more info about status.json components flags, refer to [[EPC HTTP Interface]]
-**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 (more complex) sensor groups
+**8470528 sums up '''sensor_values''' (16384 aka 0x4000) plus '''sensor_descr''' (65536 aka 0x10000), plus the ‘'''extended'''’ marker (8388608 aka 0x800000) to get both simple sensors and (more complex) sensor groups
 **8470528 = 0x814000 = 0x4000 + 0x10000 + 0x800000

@@ Zeile 225: / Zeile 225: @@
 .0.0.2.1  <font color="blue">0.4</font> W power
          '''C4''' Cylinder4
-.0.0.4.0 <font color="blue">4.5</font> milli-brown flux
+.0.0.3.0 <font color="blue">4.5</font> milli-brown flux
-.0.0.4.1 <font color="blue">1.5</font> W power
+.0.0.3.1 <font color="blue">1.5</font> W power
          '''T1''' Temperature1
 .0.1.0.0 <font color="blue">83.9</font> C Temperature

@@ Zeile 16: / Zeile 16: @@
 This empowers you to '''write small code supporting all products and all sensors in one single future-proof approach''', without the need for sensor specific knowledge.
-So your software is already prepared for new gude-devices, and prepared for new sensor Add-Ons.
+So your software is already prepared for new Gude-devices, and prepared for new sensor Add-Ons.
 To give an example, this documentation will highly depend on [https://github.com/gudesystems/check_gude.py check_gude.py], our HTTP sensor data swiss-knife tool.

@@ Zeile 245: / Zeile 245: @@
 **The device has two banks, A and B
 **Bank A has two outlets (A1, A2) with one power sensors S1.
-**Bank B has one outlets (B1) with one power sensors S2
+**Bank B has one outlet (B1) with one power sensors S2

@@ Zeile 115: / Zeile 115: @@
 ==show CGI-Get / JSON Data ==
-when using --verbose [https://github.com/gudesystems/check_gude.py check_gude.py] will print out the full URL and the JSON return data:
+when using --verbose, [https://github.com/gudesystems/check_gude.py check_gude.py] will print out the full URL and the JSON return data:
 [[Bild:Check gude py 2.png]]

@@ Zeile 11: / Zeile 11: @@
 *sensor_values carries all measured sensor values, matching the description explained above, in the same order
 *It's common practice to get sensor_descr+sensor_values once, and '''poll sensor_values only''' subsequently with much less payload
-**(it's perfectly legit to always get sensor_values alone and rely on sensor type specific knowledge coded within your application's source)
+**(while it's perfectly legit to always get sensor_values alone and rely on sensor type specific knowledge coded within your application's source)