sensor data influenced by other sensor?

sugo

Hi,

I just got my Air-Q Science a week ago, and playing around a bit.

Before giving my feedback I have to understand well some stuff.

Are the value retrieved via HTTP GET /data modified in some way, except calibration and average stuff? I mean:

is there some fix done using other sensors, like NO2 used to fix cross sensitivity of the O3 sensor?
is the RH and/or temperature correction done in the app or is this already "included" in the value got via HTTP get?
is there any way to get raw data, with no calibration and such?

Thanks a lot

sugo

well, it sucks a bit that nobody answered, anyway, I assume none of this is applied

is there some fix done using other sensors, like NO2 used to fix cross sensitivity of the O3 sensor?
is the RH and/or temperature correction done in the app or is this already "included" in the value got via HTTP get?

I am trying to do a good calibration inside home assistant since autocalibration it's completely useless. I understand the need to have it, for the average user who don't want to bother about tuning and still want some numbers to read, but, in particular for O3 / NO2 this does not work

sugo

https://community.home-assistant.io/t/air-q-device-any-good/512254/5

Mario [air-Q]

sorry for the late answer. I did miss the mail-reminder obviously.

I will answer your questions gladly:
is there some fix done using other sensors, like NO2 used to fix cross sensitivity of the O3 sensor?
--> no. we dont correct for cross sensitivities at the moment. We have aresearch project on this and hope we will be able to do so in the future (actually our research focuses on measuring NEW additional sensor values)

is the RH and/or temperature correction done in the app or is this already "included" in the value got via HTTP get?
--> done in the air-Q device

is there any way to get raw data, with no calibration and such?
--> hm. you could deduct the baseline calibration value from the data. reverse the temperature correction seems impossible.

"autocalibration it's completely useless."
Why do you think so?
without the autocalibration the values would drift over time and could even "jump" permanently when "climatic shocks" occur.

Mario [air-Q]

@sugo ping

sugo

"no. we don't correct for cross sensitivities at the moment. We have research project on this and hope we will be able to do so in the future (actually our research focuses on measuring NEW additional sensor values)"

Well, this is quite important considering the 1:1 sensitivity of O3 to NO2, and since we got a NO2 sensor, looks like obvious to use it, probably better fixing the current stuff than implementing new sensors

"done in the air-Q device"

after some analisys, see my review on the link above, in the HA forum, I am not sure this is done accurately, it would be nice to have the raw values and/or the formulas you use

"Why do you think so?
without the autocalibration the values would drift over time and could even "jump" permanently when "climatic shocks" occur"

because a simple correction of the zero value is not enough, I had tried a climatic shock, from outdoor 0 °C to indoor 20 °C and with the compensation I did, it looks everithing works fine, I still have to fix/fine tuning something, but what I mean is: we have a very good device with good sensors, we can and we should achieve better measurement of what we currently receive. Sensors are factory calibrated, which is a damn good stuff, we probably just need a good temperature/humidity/pressure compensation, and a fix of cross sensitivity is a must. Anyway I will go on with my review on HA forum (which BTW is a positive review) providing graph and stuff, at the end I will provide the exact formulas I used for compensation, which seems to work just fine

just my $ .02

sugo

@Mario-air-Q : at least for the science options you should provide raw value when possible, I reverse engineered %RH but I am not convinced if there's some additional daleay added for some reasons, or what's wrong, maybe I did a mistake in the math

since it say 3.8 for calibration

"temperature": {
  "Unit": {
    "humidity": "%",
    "temperature": "degC",
    "dewpt": "degC",
    "humidity_abs": "g/m^3"
  },
  "Part Number": "HDC1080",
  "Manufacturer": "Texas Instruments",
  "Description": "Temperature and Humidity Sensor",
  "Offset": {
    "temperature": -3.8
  },

I did (in home assistant but should be easy to understand)

  - sensor:
    - name: "AirQ Temperature Original"
      state: "{{states('sensor.airq_temperature') | float + 3.8 }}"  
  - sensor:
    - name: "AirQ Internal Saturated Vapour Pressure"
      state: "{{  610.94 * 2.7182818 ** ( 17.625 * states('sensor.airq_temperature_original') | float / ( 243.04 + states('sensor.airq_temperature_original') | float) ) }}"  
  - sensor:
    - name: "AirQ RH original"
      unit_of_measurement: "%"
      state: "{{  0.4615 * ( 273.16 + states('sensor.airq_temperature_original') | float) *  states('sensor.airq_absolute_humidity') | float * 100 / states('sensor.airq_internal_saturated_vapour_pressure') | float }}"

Mario [air-Q]

why should you reverse engineere RH? This value is strongly connected to Temperature, meaning they are paired and only are correct if both are corrected

sugo

@Mario-air-Q
I would like to make the temperature correction by myself, not using an hardcoded constant value as a drift, isn't science option supposed to be available for a lab? I would like to have the raw RH value since I want to apply temperature correction using a non constant value, but depending from the temperature (and wind eventually). Having original RH value is useful to calculate absolute humidity, like you already do internally in the device.

jojo

@Mario-air-Q
I'd like to support the request for the ability to obtain the raw values. My reasoning behind is that sensor-data are always influenced.

Some corrections (such as static offset) can be applied in realtime by the device.
Other correction data is simply not available at that timepoint (just look for "negative values" ) . These derivations are sometimes severe - my SO2-Values change usually daily between -200 and +400 and take several hours to get reasonable again. Corrections for such things as temperature-shocks can - from my viewpoint - only corrected for the past (depending of the change or shock: some minutes or even several hours). But for this I do require the uncorrected values.
I've worked with many sensor-types in the past years ; nearly none has a absolut linear response. When the value of the air- e.g. for SO2 should be in the range between 0 and 350ug (1 hour limitation for EU) has a calibration-correction value of currently over +1800 , I expect non-linearity in the response. A real change from 0 to 30 may not result in the same output-value as a change from 1800 to 1830.
Sensors have always cross-sensitivies. As the effects are sometimes massive (H2S is creates a effect of around 6 for SO2), the calibration is even more important.

Long text short, It would be great if there is option to extract the real sensor values- at least to the science version. This would allow me to be able to create own dashboards, reports and corrections.