Hi @everyone
Just want to make sure, do you using prometheus monitoring to fetch from /metrics local server? If it is, it might relate to this issue: I-9PSL unit reset itself when calling /metrics endpoint · Issue #309 · airgradienthq/arduino · GitHub
We’ll create the official release to fix this very soon.
Thanks! Yes, I am using Prometheus monitoring of /metrics
So am I.
I think it should be this commit that introduced prometheus
3e4e2affa828eff0eb44de0380602be5d9ea706c
The fix has been posted, see PR #310 on github.
No reboots here (at least I haven’t noticed any), just saw this issue in the forum and checked my devices and noticed the one that wasn’t upgraded at the same time as the other two.
Is the fix also addressing connection error (console readout):
[5776534][E][ssl_client.cpp:37] _handle_error(): [start_ssl_client():273]: (-80) UNKNOWN ERROR CODE (0050)
[5776647][E][WiFiClientSecure.cpp:144] connect(): start_ssl_client: -80
Posted here: Repeatedly failing OTA update - #15 by Evv
Today my Airgradient(KIT) which is connected to my Homeassistnat suddenly also started rebooting/firmware updating 3.3.6 in circles…
I blocked internet access on my paloalto Firewall for the Airgradient, which (temporarily) stopped it updating in circles now and working fine and showing data in Homeassistant also. I just cannot access it via browser via http or https but not sure if this should work.
From my homeassistant history the issue started tonight at 2:55AM UTC Time.
Once i unblock it on firewall and reboot it, the circle starts again…
Why is this happening and how can this be fixed permanently? - i still see 3.3.6 is the last version on github.
We have rolled out a backend change today that lets devices that are not configured in the AG backend update. Somehow some end up in an update loop. We will revert the change temporarily and this should stop the loop.
Unfortunately this doesn’t seem to help. Devices running 3.3.6 continue to loop, now probably faster compared to before. We need to further investigate what has changed in the firmware.
Ok thanks for the update, please keep us posted here.
I have 3 I-9PSL-DE sensors. Should we downgrade to 3.2.0 ? My CO2 readings went dead this morning and have not come back. The display reads “CO2: —”
I had that happen soon after I got the sensor. A soft reboot (reboot via the same tool that does software upgrades and shows logs) didn’t resolve it. I had to fully unplug and re-plug to get the CO2 sensor working again.
In my case I had to downgrade to 3.2.0 in the dashboard and then stop prometheus polling the sensors http endpoint (to stop crashing in the middle of downgrade). So far 3.2.0 has been fine, seems like the team is still working through a few bugs.
I am also experiencing the same issue, just a few hours ago on 5/9/2025 ~10PM EST, my airgradient decided to start a firmware update automatically and has been stuck in an infinite reboot-reupdate loop for the past hour.
What is that latest info about this issue?
Both my devices (I-9PSL and O-1PP) are stuck in the update loop. What I have tried so far is only with the indoor unit as it is at my desk which is convenient, the outdoor unit is mounted outside…
I have tried reflashing with 3.3.6, on the serial console I could see the panic and it rebooting and going into the firmware update. After reflashing and erasing data the panic appears to have stopped, but it is still in the update loop.
I flashed it with 3.1.13 but the first thing it does after booting is update itself to 3.3.6.
I don’t use the dashboard, just locally get the stats into home assistant, so when I setup the wifi after flashing I select the option to not send data and not get updates, but it still does the update…
I don’t have the tooling set up to build firmware from source, so am relying on binaries of the firmware.
Issue of boot-loop started today (May 10, 2025) on my AirGradientOne.
Part of the log that seems interesting is shown below. I use it indoor, so values are not shared and I have no account (hence the 400, which was always the case).
You can see HA asking for info and from that answer (payload) you can see that firmware is already on 3.3.6
[WifiConnector] Info: Wait for configure portal
[WifiConnector] Info: WiFi Connected: WLAN IP: [redacted]
[LocalServer] Info: Init: airgradient_744dbdcb5648.local
MQTT is not configured, skipping initialization of MQTT client
[AgWifiClient] Info: Post measures to [redacted to prevent link block]hw_airgradient_com/sensors/airgradient:744dbdcb5648/measures
[AgWifiClient] Error: Failed post measures to server with response code 400
[AgWifiClient] Info: Fetch configuration from [redacted to prevent link block]hw_airgradient_com/sensors/airgradient:744dbdcb5648/one/config
[AgWifiClient] Error: Failed fetch configuration from server with return code 400
Display brightness: 10
Success create networking task
Firmware update starting…
[OTAWifi] Info: Image size 1727616 bytes
OTA progress: 2
OTA progress: 5
OTA progress: 8
OTA progress: 11
Having the same issue.
Rebooted / Re flashed and issue still exists.
Ok in offline mode.
Exactly the same situation and questions as above post from flipside…
Hesitant to turn the thing off if it’s constantly updating firmware.
It corrected itself soon after I posted, thanks 
Thanks, that has fixed the loop in my airgradient one. Can the auto update be disabled? I am using HA integration
I had configured my airgradient one not to communicate with remote servers, which the configuration page implies would not allow for any automatic firmware updates. That seems to not have been the case (unless the Home Assistant integration will automatically update the firmware that I’m not aware of). Upon seemingly automatically updating to 3.3.6, the unit would repeatedly boot, check for firmware updates, the hw.airgradient API call would always return a new firmware (regardless of what was passed in as the current firmware version) and then the unit would flash and reboot. Wash, rinse, repeat. I’m using past-tense here because I flashed the ESPHome firmware in the meantime in order to restore functionality to the unit. I’m not thrilled that, even though I had it configured to not talk to remote servers, a bug in a remote server endpoint seems to have been able to effectively brick (I guess technically bootloop) my device.