AirGradient Forum

Whatever could be causing NOx index to be spiking like this?

#1

As of couple weeks ago I have started seeing NOx Index on my outdoors sensor spike in a weird short-lived pattern as seen in the graph herein:

NOx Index spikes
NOx Index spikes3087×1108 249 KB

I’m living on the outskirts of a city and there isn’t/shouldn’t be much vehicle traffic nearby. There isn’t any significant industrial activity within some 20km radius of me either. Each event lasts less than an hour. Here’s one example zoomed in:

single spike
single spike3069×1113 140 KB

Spikes like these don’t appear to have any particular time-based pattern – some events happen at 2am, some at noon, some around the time the work day wraps up.

The spikes appear to correlate with the VOC index:

voc correlation
voc correlation3085×1167 316 KB

Has anybody ever seen anything like this? Any thoughts what could be the cause here? Sensor gone faulty, some weird natural phenomenon or perhaps it is indeed wind bringing something from some industrial thing from far away?

(Likely not relevant but I’m using ESPHome-based firmware, but it hasn’t seen updates for quite some time.)

#2

Do you have a gas dryer with a vent that may be nearby, or a gas furnace/water heater that could be blowing toward the sensor in certain conditions?

#3

Nothing gas related in my property, everythings’ electric. The sensor is situated somewhat near an inlet of a HRV unit though. That one runs at ~constant airflow.

I have been investigating this tonight and turns out these spikes also correlate to the uptime going to 0… For some reason the ESP32 is crashing/restarting periodically…

#4

Are you using HomeAssistant as well? If so, you can view the Uptime sensor to see a history of how often it has been rebooting.

When ESPHome restarts the VOC sensor will reset to 100 as a baseline, so it shouldn’t result in spikes over 100, if anything, it would hang close to 100 if constantly rebooting.

Similarly, the NOx should reset to 1 on a reboot, so shouldn’t result in spikes.

I’ve seen some odd NOx spikes at night that I can’t account for

#5

@nagisa Can you compare the data with temperature and humidity and see of there is a correlation. Sometimes these MOx sensors are having cross sensitivities.

#6

I don’t use HA, but I do have the uptime sensor in my influx.

image
image1920×773 127 KB

Yeah, it is very interesting that NOx (and apparently VOC) goes up like that. I definitely remember it being “well behaved” in the past, but it certainly seems to be present in ESPHome 2025.4.1 and

substitutions:
  voc_learning_time_offset_hours: '360'
  nox_learning_time_offset_hours: '360'
sensor:
  - platform: sgp4x
    # SGP41 https://esphome.io/components/sensor/sgp4x.html
    update_interval: 60s
    voc:
      name: "VOC Index"
      id: voc
      algorithm_tuning:
        learning_time_offset_hours: $voc_learning_time_offset_hours
    nox:
      name: "NOx Index"
      id: nox
      algorithm_tuning:
        learning_time_offset_hours: $nox_learning_time_offset_hours
    compensation:
      temperature_source: temperature
      humidity_source: humidity

I guess I’ll try bisecting esphome and see what comes out. There haven’t been many changes to sgp4x sensor over time.

No clear correlation between the spikes, restarts & temperature/humidity, but at this point it is pretty clear that this issue has something to do with how ESPHome initializes the sensor, so I’ll be looking at that (as well as to investigate why my ESP32 keeps rebooting.)

#7

I’m not seeing spikes like you are describing using ESPHome 2025.3.2 but I just upgraded to the latest to see if I start encountering it.

Your learning time offset is higher than what I have defaulted in my ESPHome config of 12 hours, so a minor difference there.
I also have the temperature_source set to temp where yours is temperature so you have a different overall base than what I have in my git repo, since it has been named temp for the last year and a half.

If you think it is ESPHome specific, you could try using my config and see if you get any different behavior.

Sometimes my devices will reboot frequently with no real cause I can find. I have 2 wireless access points in my house and if I restart 1 or both of them, I can often solve the regular reboot situation. I want to say it has to do with it trying to connect to the weaker one for where the AG is located and a reboot forces it to pick the other, but I don’t have enough evidence to know that for sure. But something to try is just rebooting your wireless equipment, even if everything else in your house is working as expected.

1 Like
#8

My config is heavily based on your project but I have custom sensors (e.g. barometric pressure) inside of mine that I had to add and eventually I ended up merging what I need into a single file so I don’t get as lost in my directory of all ESPHome configs.

Specifically on temp ID: I always find it confusing that MQTT node is named after the name field and not the id field, so I always make a note to have them both be the same so that I don’t need to question myself.

Ya, I similarly didn’t see anything of the sort until very recently. For me it’ll be easier to bisect ESPHome itself than to try different configs.

That said, as a stop-gap I set mqtt.log_topic: null and the firmware currently seems relatively stable. I need more time to monitor to know for sure, though. I wouldn’t be surprised if the crashes were due to the device disconnecting from WiFi briefly and then its RAM filling up with queued logs to send over MQTT before it had time to reconnect. But that of course still does not explain why I saw NOx spike on startup…

#9

Is this an uptime sensor for the AG monitor. Is it a monitor entity?. If so, I can’t find anything for either the One or OUT monitors in HA. This is something that I could find useful to access in Home Assistant.

#10

@Rog Are you using the ESPHome firmware with HomeAssistant or the stock firmware with the HA Integration? My statement only applies if using ESPHome which exposes an Uptime sensor

#11

The stock firmware with the HA integration. So that’s why I can’t see it :slight_smile:
Thanks

#12

Crashes appear to have gone away after setting mqtt.log_topic: null. Using MQTT logging would probably not be a big deal either way if the pmsx003 integration wasn’t so chatty in my configuration, but at the same time it seems like ESPHome itself could make logs over MQTT more resilient.

You probably are right that this is probably related in some way to WiFi as well, especially seeing as I have multiple APs in range. I probably should configure wifi.networks.N.bssid to pick the outdoors AP, but that has an unfortunate effect of making it difficult to bring the ESP to my workstation if I need to work on it, as the outdoor AP doesn’t reach there…

Still no idea why NOx spikes up on reboot (it happens on a regular boot as well, not just after a crash,) but I won’t have time to investigate this for quite some time.