sensor data influenced by other sensor?

[jojo]

@Felix-Bayer Yes, I'm aware. On the other side, some days ago the timestamps of the last calibration were quite old, 4 values were from mid january, 1 from November, and only 2 from recent dates (mid/end of february).

I use the correction suggestion from sugo. These values seem much more accurate, when comparing them to the values delivered nativly by airq.

If I think that the Zero-line has shifted and thus a new calibration value is required, I put the airq for around 2 hours outside, and check the values of official measurements. Using them for calibration , it seems.accurate. (anybody without a official station nearby could use https://db.eurad.uni-koeln.de/de/vorhersage/eurad-im.php to get a rough impression for any european location).

Jojo

[sugo]

From
https://sensirion.com/media/documents/984E0DD5/61644B8B/Sensirion_Gas_Sensors_Datasheet_SGP30.pdf

"The SGP30 features an on-chip humidity compensation for the air quality signals (CO2eq and TVOC) and sensor raw signals
(H2 signal and Ethanol signal). To use the on-chip humidity compensation an absolute humidity value from an external humidity
sensor like the SHTxx is required. Using the “sgp30_set_absolute_humidity” command, a new humidity value can be written to
the SGP30 by sending 2 data bytes (MSB first) and 1 CRC byte."

I have the strong feeling this is not applied, can you please confirm?

[Mario [air-Q]]

@sugo sorry for the late answer. the mailing system of the forum was down - nobody noticed. I will check this.

[sugo]

@Mario-air-Q
Do you have some news?

I currently use this formula, for integrated correction would be for sure far better

• platform: statistics
  name: "min T"
  entity_id: sensor.airq_temperature
  state_characteristic: value_min
  max_age:
  minutes: 2000
  sampling_size: 2000

state: "{{ states('sensor.airq_voc') | float * ( 2 / states('sensor.airq_absolute_humidity') | float ) ** 0.8 - 11 * ( states('sensor.airq_temperature') | float - states('sensor.min_t') | float ) }}"

[Felix [air-Q]]

@sugo
thank you for participating and sharing this informations. I linked this forum post and the one from home assistant to our Devs so they can look over it and decide if/how to integrate this in our code, i think we also need a decision wether this should be implemented on FW- oder App-Level.

[Felix [air-Q]]

@sugo
In general, there is also the fact that a volume concentration (%, ppm or ppb) does not change with temperature or pressure, but the mass concentration (µg/m3 or mg/m3) does. Therefore, the lower the temperature falls while the volume concentration remains constant, the higher the mass concentration per cubic meter becomes, since the air then becomes increasingly dense.

[sugo]

About CO I think your statement that "normal" outdoor values is like 1mg/mc is wrong, it's more like 0.1mg/mc, in fact outdoor CO in not anymore an issue since years. The reported value is good enough for detection of fire, which I guess it's the main target, still I don't like to have a value which could be wrong by a factor of 10.

https://earthobservatory.nasa.gov/global-maps/MOP_CO_M

[Mario [air-Q]]

@sugo die value ist noch wrong by a "factor" (this would mean if air-Q CO sensor show 5 mg, real value would be 45 mg - which is not true).
It is "wrong" by 0,9 mg in absolute values. If you dont like the baseline which we calibrated, please recalibrate. You can do this in the App (settings - sensors - calibration)

[sugo]

@Mario-air-Q : yeah, it's probably just the offset, but in "normal" conditions, meaning I have 0.15 mg that you should use as a baseline as default, and I see 1 mg, because you choose that as a normal co value. That was probably correct 30 years ago.
Anyway, somewhere you stated that "normal" outdoor values is like 1mg/mc, this is just wrong