Join the early list

Environmental sensors for VAHA: wiring, how readings reach the app, and two TVOC data-integrity gaps

· Ritesh Bonthalakoti

  • Sensing
  • TRL 3
Read the paper Download

PDF, 17 pages, 2.7 MB · v1.0

The paper's cover: Environmental sensors for VAHA: wiring, how readings reach the app, and two TVOC data-integrity gaps

Summary

Describes how VAHA's three sensors are wired to the Arduino UNO Q and how a reading reaches every capture and the app's live view, and checks whether a bad reading can pass as a good one. DHT22 failures are handled (sent as nan, stored as no value). TVOC has two gaps: a failed I2C read returns 7777 or 8888 + error code, which both Linux-side parsers store as a reading (confirmed against the device server's API); and replies are decoded without the AGS02MA's CRC and with its status byte in the value, so a set status flag adds 16,777,216 ppb and a damaged reply can give a plausible wrong value (calculated from the datasheet's reply format). No sensor accuracy or delivery latency has been measured. TRL 3; the path to TRL 4 is limits, the TVOC fix tested with a fault induced on the device, reference comparisons for each sensor, and measured latency.

Key findings

  • TVOC failures stored as readings. A failed read returns 7777 or 8888 + error code, stored and served as a real ppb value. The DHT22 path in the same function reports failure correctly.
  • TVOC decoded without its checksum. The status byte is kept in the value and the CRC is never checked, so a set status flag or a corrupted reply gives a wrong reading with no sign of it.
  • Two parsers. A capture's sensor snapshot is parsed in main.py; the live readings in sensor_service.py. Neither checks the TVOC value.
  • Not measured yet. Sensor accuracy, delivery latency, and the TVOC failure on real hardware.

Inside the paper

4 of the paper's 6 figures. Open any of them full size to zoom in.

Figure 2: Sensor wiring, from the README's pin table and the pin definitions in sketch.ino.Wiring diagram. Three sensors connect to the microcontroller side of the Arduino UNO Q (ABX00087). DHT22, temperature and humidity over a single-wire digital line: VCC 5V, DATA D2, GND, with D2 as a digital input. Water-flow sensor, hall-effect, 7.5 pulses per L/min, rising-edge pulses: VCC 5V, SIG D3, GND, with D3 as an interrupt. AGS02MA, TVOC, I2C address 0x1A: VCC 3.3V, SDA A4, SCL A5, GND, with the I2C clock at 20 kHz. SENSOR WIRING, AS BUILT Arduino UNO Q ABX00087, MCU side DHT22 Temperature and humidity single-wire digital VCC 5V · DATA D2 · GND D2 digital input Water flow sensor Hall-effect, 7.5 pulses/L/min rising-edge pulses VCC 5V · SIG D3 · GND D3 interrupt AGS02MA TVOC, I2C address 0x1A 20 kHz I2C clock VCC 3.3V · SDA A4 · SCL A5 · GND A4 SDA, A5 SCL I2C, 20 kHz
Figure 2 Sensor wiring, from the README's pin table and the pin definitions in sketch.ino.
Figure 3: From sensor to app, as the code runs it. The two Linux-side paths parse the same string in the same way.Flow diagram. The DHT22, the AGS02MA and the flow sensor feed sensors_get() in sketch.ino on the microcontroller, which reads all three and returns one string, T:..:H:..:F:..:L:..:V:... A DHT22 failure is sent as nan. A TVOC failure is sent as 7777 or 8888 plus an error code, a plain number (Gap 1), and the TVOC status byte is kept in the value (Gap 2). The string crosses the router bridge, Bridge.call('sensors_get'), to two Linux-side paths. At each capture, get_sensors() in main.py parses it and save_capture() stores it with the note, which is synced to the app. Every 30 s, sensor_service.py parses the same string and keeps the last 100 readings, about 50 minutes, for the live readings API and WebSocket. Neither parser checks the TVOC value: each takes int() of whatever the microcontroller sent. FROM SENSOR TO APP: TWO PATHS ON THE LINUX SIDE DHT22 temperature, humidity AGS02MA TVOC, I2C 0x1A Flow sensor hall-effect pulses MCU: sketch.ino sensors_get() reads all three and returns one string: T:..:H:..:F:..:L:..:V:.. DHT22 failure: "nan" TVOC failure: 7777 or 8888 + err, a plain number (Gap 1) TVOC status byte kept (Gap 2) Router bridge Bridge.call( 'sensors_get') At each capture: main.py get_sensors() parses the string; save_capture() stores it with the note; synced to the app Every 30 s: sensor_service.py Parses the same string; keeps the last 100 readings (~50 min); live readings API and WebSocket Neither Linux-side parser checks the TVOC value: int() of whatever the MCU sent
Figure 3 From sensor to app, as the code runs it. The two Linux-side paths parse the same string in the same way.
Figure 4: Where this work sits on the EU Horizon TRL scale.Technology readiness ladder from TRL 1 to TRL 9. TRL 1 to 3 are filled in; TRL 3, experimental proof of concept, is marked as this work. TRL 4, technology validated in lab, is marked as next. TECHNOLOGY READINESS: WHERE THIS WORK SITS TRL 1 Basic principles observed TRL 2 Technology concept formulated TRL 3 Experimental proof of concept TRL 4 Technology validated in lab TRL 5 Validated in relevant environment TRL 6 Demonstrated in relevant environment TRL 7 Prototype in operational environment TRL 8 System complete and qualified TRL 9 Proven in operational environment This work Next
Figure 4 Where this work sits on the EU Horizon TRL scale.
Figure 5: Path from this work to TRL 4, one row per requirement in priority order: its status today, the change to the build, the test that shows it is met, and the data the test leaves.Step 1: set the limits first, accuracy for each sensor and delivery latency, written down before any test. Then one row per requirement. R3, failures and corrupt reads flagged, not met: readTVOC() reports a failure as a flag, as the DHT22 does with nan, checks the CRC and keeps only the 24-bit value; tested by disconnecting SDA during reads on the device and corrupting the CRC byte, with no number reaching a capture; evidence ags02ma_fault_test.csv. R2, readings represent the room, not measured: no change beyond the R3 fix; each sensor tested against a reference, a thermometer and hygrometer, a VOC source and a measured volume of water; evidence dht22_accuracy.csv, ags02ma_accuracy.csv and flow_calibration.csv. R1, readings delivered quickly, not measured: timestamp each reading on the microcontroller and when it reaches the app; delivery latency over several sessions, p50, p95 and p99 with n; evidence bridge_latency_log.csv. TRL 4 when every row passes against the limits set in step 1. Then a test in a bathroom, with shower humidity, fan noise and cleaning products (TRL 5). PATH FROM THIS WORK TO TRL 4 1 Set the limits first: accuracy for each sensor and delivery latency, written down before any test REQUIREMENT, TODAY CHANGE TO THE BUILD TEST THAT PROVES IT EVIDENCE IN DATA/RAW R3 Failures and corrupt reads flagged NOT MET readTVOC() reports a failure as a flag, as the DHT22 does with nan; check the CRC; keep only the 24-bit value SDA disconnected during reads on the device; a corrupted CRC byte: no number reaches a capture ags02ma_fault_test.csv R2 Readings represent the room NOT MEASURED No change beyond the R3 fix Each sensor against a reference: thermometer and hygrometer, a VOC source, a measured volume of water dht22_accuracy.csv ags02ma_accuracy.csv flow_calibration.csv R1 Readings delivered quickly NOT MEASURED Timestamp each reading on the MCU and when it reaches the app Delivery latency over several sessions: p50, p95, p99 with n bridge_latency_log.csv TRL 4: every row passes against the limits set in step 1 Then: test in a bathroom, with shower humidity, fan noise and cleaning products (TRL 5)
Figure 5 Path from this work to TRL 4, one row per requirement in priority order: its status today, the change to the build, the test that shows it is met, and the data the test leaves.

About this paper

Version
v1.0, published 22 October 2026
Written by
Ritesh Bonthalakoti
Reviewed by
Bharat Meda
Readiness
TRL 3: experimental proof of concept
Tested on
VAHA's sensor path as of 2026-08-17: an Arduino UNO Q with a DHT22, an AGS02MA and a hall-effect water-flow sensor, read from the code and the AGS02MA datasheet; the device server's code run on a development computer with TVOC failure values
Standards
ISO 16290 for the readiness level only; no sensor compared with a reference instrument yet; no accredited testing
The paper
17 pages, 2.7 MB, PDF

The full paper has the method, every table, the defects found along the way and what is still needed for the next readiness level.

Read the paper

Related reading