Thank you everyone for the input. I’ll let our engineer know about these.
Please feel free to add any information you want to share that might be listed on the questionnaires.
Again, in the meantime. For those who want to revert to the previous firmware, you can follow the guide I mentioned in the post. Let us know if you need help.
Thanks!
HA supports flashing them with updates directly.
Just as another datapoint, today I briefly disconnected one of my APs from power and then reconnected it. As a result, two of my AirGradients went offline and stayed offline, never reconnecting until manually power cycled (the indoor units.)
I’m not sure why I’m not having the same issue as others. My ONE is upgraded to 3.6.0, I have 2 Unifi access points hardwired. 2.4 Ghz + 5 Ghz on a single SSID.
I even manually rebooted each AP and haven’t experienced the connection loss of others.
Very odd
I am using multiple AP’s, but NOT using “fast roam” (the AG WiFi appears to hate it . …) although the one that consistently had died every time can only “hear” viable signal from one of them . . . That’s all that I can think that might differ here, since a single AP restart doesn’t cause an issue (the devices will migrate) but a full outage does.
Not sure on timing when I blew them both out . . . I had been working another issue, and had made a number of changes, so may have been offline longer than a single restart. (I’ve not specifically retested, but that was all that I had done when I noted that both were down).
http://airgradient_d83bda1a320c.local/config
{“country”:“IT”,“pmStandard”:“ugm3”,“ledBarMode”:“co2”,“abcDays”:30,“tvocLearningOffset”:12,“noxLearningOffset”:12,“mqttBrokerUrl”:"",“httpDomain”:"",“temperatureUnit”:“c”,“disableCloudConnection”:false,“configurationControl”:“both”,“postDataToAirGradient”:true,“ledBarBrightness”:0,“displayBrightness”:0,“offlineMode”:false,“monitorDisplayCompensatedValues”:false,“model”:“I-9PSL-DE”,“extendedPmMeasures”:false}
http://airgradient_d83bda1c6268.local/config
{“country”:“IT”,“pmStandard”:“ugm3”,“ledBarMode”:“co2”,“abcDays”:30,“tvocLearningOffset”:12,“noxLearningOffset”:12,“mqttBrokerUrl”:"",“temperatureUnit”:“c”,“configurationControl”:“both”,“postDataToAirGradient”:true,“ledBarBrightness”:0,“displayBrightness”:0,“offlineMode”:false,“monitorDisplayCompensatedValues”:false,“httpDomain”:"",“disableCloudConnection”:false,“extendedPmMeasures”:false,“model”:“O-1PST”,“corrections”:{“atmp”:{“correctionAlgorithm”:“ag_pms5003t_2024”,“slr”:null},“rhum”:{“correctionAlgorithm”:“ag_pms5003t_2024”,“slr”:null}}}
6. My Wi-Fi uses a unified band, without separating 2.4GHz and 5GHz
7. My Wi-Fi has no multiple access points and I don’t use Wi-Fi extenders
8. My Wi-Fi DHCP is not configured for static IP addresses
9. Both monitors are connected to an AirGradient dashboard
10. I have no HomeAssistant nor other platforms
11. I’ve not yet downgraded to 3.4.1. I hope in a new firmware that solves the problem without downgrading
@MallocArray Yes, that’s what we have to investigate why it happens randomly and some users don’t experience the issue at all.
I have been trying to reproduce the issue with my routers (all-in-one router+AP) which are Xiaomi AX3200 and TP-Link Archer MR202. I haven’t seen the issue so far.
Our engineering team is capturing logs and letting the monitors run. Hopefully, we’ll find something out soon.
Is Eng using a debug build, or ???
And does logging persist after a power cycle?
I seem to have 100% predictability on generating this issue, and would be glad to try to capture logs/info if helpful.
(I also have the AG code from GIT here, and buildable. I don’t run that, but it’s available as well . . . I’ve looked at this a bit, but not yet deciphered the convoluted path that some of the wireless stuff take, and have not found where a number of the ESP wireless library stuff is set yet . . .
If you use this link: AirGradient ONE (I-9PSL), Open Air (O-1PST) and Open Air Max (O-M-1PPST...) Firmware Versions
You have the option to display logs instead of installing the firmware after clicking “Flash Now”
You could do that and then generate the issue and collect any logs displayed for support.
It does not keep logs stored in the device or after a reboot, so you have to copy it from your screen.
Hi @tadawson ,
Since you already able to build the codebase and your monitor has the issue, could you try flash your monitor using patch on this branch?
Really appreciated!
Let me give that a go. I’m not sure if I can get it on my outdoor (over 3 feet of snow right now, so can’t get it down or acess buttons, but let me verify that I can trigger my indoor and then try to load that.
If there is a way to OTA load this, I could likely get it on the outdoor as well (I haven’t looked . . . )
Chiming in here…looks like a bug for sure with 3.6.0. Both my AG (indoor and outdoor) units disconnected 3 times in the last 10 days requiring a manual reboot to restore connectivity.
OK, some information here . . .
I just went back to 3.6.0 to confirm that I can wedge it, and have the Indoor on the Arduino IDE, watching the serial output, and dumped both my AP’s (full signal loss). The unit DID go red, and did not reconnect.
I’m trying to upload the text file of the log, but the site won’t let me . . . for unknown reasons, a text file is forbidden . . .
If the team would like the full log output, please provide me a means to send it, and I’ll get it on the way. It’s only about 82K, so will mail (or whatever) easily.
It’s odd, that after the initial error, it seemed to take some time before the RSSI report vanished (even though the AP’s were down). I see nothing that looks like a network loss/retry.
The only error I see is this:
Custom correction applied
Custom correction applied
WiFi RSSI -52
[AgWifiClient] Info: Post measures to
https://hw.airgradient.com/sensors/airgradient:d83bda1b8570/measures
[680634][E][ssl_client.cpp:37] _handle_error():
[start_ssl_client():273]: (-78) UNKNOWN ERROR CODE (004E)
[680745][E][WiFiClientSecure.cpp:144] connect(): start_ssl_client: -78
[AgWifiClient] Error: Failed post measures to server with response code -1
Online mode and isPostToAirGradient = true
Free heap: 155336
Custom correction applied
CO2 = 1418.33 ppm
Temperature = 22.18 C
Relative Humidity = 33.35
TVOC Index = 101.7
After this, the normal processing loop seems to keep running, with no errors logged, but no RSSI either.
(Cleaned up prior “diatribe” . . .)
Looks like there may be an issue with the code in the git repo, beyond 3.4.1. If I checkout 3.4.1, I can build and install fine. If I select 3.6.0, the default 3.6.1, or the fix/wifi… branch, it builds cleanly and uploads OK, but will not start - the display stays at a black screen, and the serial monitor shows the bootloader looping. In this state, if I checkout 3.4.1 again, all works. I’ve dumped the IDE cache between builds, so that should be clean, and have the specified version of NimBLE in play, and no other external libraries.
Please advise, and I’ll make another go at loading the test code.
Hi @tadawson ,
Could you send the log to support and say forward it to me? https://www.airgradient.com/support
Thank you for your time helping.
Done!
Any insights why 3.6.0 and above won’t boot, when 3.4.1 will from the same repo?
3x I-9PSL (Kit) 1x O-1PST (Kit)
Regular Wifi disconnects since the 3.6.0 update. somtimes after ~30mins since last reboot, sometimes after 12h+. It seems to happen more frequent to my O-1PST (Kit) sensor compared to the indoor units - might be releated to my Wifi Mesh setup and that the chances are higher that the outdoor unit will use a repeater rather than the router itself.
the LED on the left is always red, the display shows the “Wifi” disconnected" symbol but the sensors values are constantly updated on the display. My sensors don’t recover from that state, only disconnecting the power helps.
Fritzbox 7590 AX as main router, 2x Fritzbox 1200 AX repeater connected via Ethernet to the router, 1x Fritzbox 1200 repeater operating as Wifi Bridge without Ethernet connection. All running in a Mesh setup with seperate SSIDs for 2.4GHz and 5.0GHz Wifi.
{
"country":"DE",
"pmStandard":"ugm3",
"ledBarMode":"co2",
"abcDays":8,
"tvocLearningOffset":12,
"noxLearningOffset":12,
"mqttBrokerUrl":"",
"temperatureUnit":"c",
"configurationControl":"local",
"postDataToAirGradient":true,
"ledBarBrightness":20,
"displayBrightness":20,
"offlineMode":false,
"httpDomain":"",
"disableCloudConnection":false,
"monitorDisplayCompensatedValues":false,
"model":"O-1PST",
"corrections":{
"pm02":{
"correctionAlgorithm":"epa_2021",
"slr":null
},
"atmp":{
"correctionAlgorithm":"ag_pms5003t_2024",
"slr":null
},
"rhum":{
"correctionAlgorithm":"ag_pms5003t_2024",
"slr":null
}
},
"extendedPmMeasures":false
}
{
"country":"DE",
"pmStandard":"ugm3",
"ledBarMode":"co2",
"abcDays":8,
"tvocLearningOffset":12,
"noxLearningOffset":12,
"mqttBrokerUrl":"",
"httpDomain":"",
"temperatureUnit":"c",
"disableCloudConnection":false,
"configurationControl":"local",
"postDataToAirGradient":true,
"ledBarBrightness":20,
"displayBrightness":20,
"offlineMode":false,
"monitorDisplayCompensatedValues":false,
"model":"I-9PSL-DE",
"corrections":{
"pm02":{
"correctionAlgorithm":"epa_2021",
"slr":null
}
},
"extendedPmMeasures":false
}
{
"country":"DE",
"pmStandard":"ugm3",
"ledBarMode":"co2",
"abcDays":8,
"tvocLearningOffset":12,
"noxLearningOffset":12,
"mqttBrokerUrl":"",
"temperatureUnit":"c",
"configurationControl":"local",
"postDataToAirGradient":true,
"ledBarBrightness":20,
"displayBrightness":20,
"offlineMode":false,
"httpDomain":"",
"disableCloudConnection":false,
"monitorDisplayCompensatedValues":false,
"model":"I-9PSL-DE",
"corrections":{
"pm02":{
"correctionAlgorithm":"epa_2021",
"slr":null
}
},
"extendedPmMeasures":false
}
{
"country":"DE",
"pmStandard":"ugm3",
"ledBarMode":"co2",
"abcDays":8,
"tvocLearningOffset":12,
"noxLearningOffset":12,
"mqttBrokerUrl":"",
"httpDomain":"",
"temperatureUnit":"c",
"disableCloudConnection":false,
"configurationControl":"local",
"postDataToAirGradient":true,
"ledBarBrightness":20,
"displayBrightness":20,
"offlineMode":false,
"monitorDisplayCompensatedValues":false,
"model":"I-9PSL-DE",
"corrections":{
"pm02":{
"correctionAlgorithm":"epa_2021",
"slr":null
}
},
"extendedPmMeasures":false
}
I’m running a FritzBox Mesh with separated SSIDs for the 2.4GHz and 5GHz bands.
FritzBox Mesh setup: Fritzbox 7590 AX as main router, 2x Fritzbox 1200 AX repeater connected via Ethernet to the router, 1x Fritzbox 1200 repeater operating as Wifi Bridge without Ethernet connection.
I use static IPs assigned via the DHCP server of my FritzBox router for some WiFi network devices. I tried static and dynamic IP addresses for my Airgradient sensors and the disconnects do happen for both scenarios.
All of my four sensors are connected to the AirGradient dashboard, which regularly report them as offline via email.
All four sensors are connected to my HA instance. All are using a local configuration source as per default setting of the HA integration. I also tried to switch them to cloud configuration but this didn’t result in any changes regarding the WiFi disconnect issue.
Downgrading the firmware to 3.4.1 via the AirGradient Dashboard fixes the disconnect issues.
Also on a sidenote: I had a I-9PSL (Kit) sensor connected to my PC running the Online Debug Tool for about ~12h per day for three days total. While the Online Debug Tool was running no WiFi disconnects did occour - when my PC was in standby and did only deliver power via USB to the sensor the disconnects did happen again.
About a week ago, I was having persistent offline errors after I turned on my ASUS RT_AX86U wireless router’s WiFi Agile Multiband feature. More often on the outdoor, O-1PST, than the I-9PSL-DE. I attributed the difference with the sub-freezing temperatures in the Chicago region at the time. Both are firmware 3.6.0.
Neither has gone offline since I turned WiFi Agile Multiband off.
Hi everyone who has experienced the issue of the 3.6.0 @gis @tadawson @jmaguire @tom_shell @gianfranco.bottini @MarKusTech @pret79 @ynoterdep ,
We are testing FW 3.6.2 which potentially fixes the issue of 3.6.0.
We would appreciate it if you could help us test the 3.6.2 to see if the issue persists or is completely fixed.
If you are interested, please let us know your ‘Place ID’ via our support form: https://www.airgradient.com/support
Please also refer to this reply in your support ticket.
How to see your Place ID?: Go to your AirGradient Dashboard > General Settings > Place [as shown in the below image]
We will enable the 3.6.2 on your AirGradient Dashboard, so you can select and update your monitors to 3.6.2.
For those who don’t use the AirGradient Dashboard, please feel free to contact us via the support form mentioned above and request the firmware file so you can flash it to your monitors.
Thank you!
Sent, and I am also working with Samuel with another test build. Forgot to mention this discussion though. It entered as ticket 27890.
Thank you, @tadawson. I really appreciate your help.
Please don’t worry about mentioning this discussion.
I am currently conducting a preliminary test of the basic functionalities of the FW 3.6.2 to make sure it works properly and does not pose any other new issues. Then we will roll out 3.6.2 to you (and those who would like to test this with us).
Thank you.
