https://app.airgradient.com/dashboard/about
I also have 4 orangeish/red LEDs at CO2 1095 which doesn’t line up with the expected pattern
1 Like
Thanks for reporting. We are checking this.
1 Like
Not sure it’s related, but I setup my brand new AirGradient One, I think it updated overnight and it either nuked the S8 and PMS sensors, or my unit died within the first 24 hours.
I don’t think it is related. Did you try and reboot the device?
If it is still a problem please contact our support team.
Already in contact, thanks Achim.
Î have the same, also 3.1.9 (yet m monitor is only weeks old, I have no experience with former Versions).
Also the graph in the dashboard is colored the same way: yellow above 800ppm, red above 1000ppm.
This has already been fixed in the code and will be rolled out in the next firmware update.
Our developers currently doing some in depth checks of the whole firmware code to see if there are other areas than need improvement.
3 Likes
Hi Achim,
I have 6 units of in-door monitor are working normally in the past few months.
Today, I observe that 2 units of in-door monitor as below do not display any value of PM 0.3, PM 1.0 and PM 10 on AirGardient dashboard, but it is showing the updating values on HomeAssistance dashboard.
AirGradient DIY-Basic (Generation 1) Monitor Serial Number: dc8e9e
AirGradient DIY Pro 3.7 Monitor Serial Number: 7a9ad4 firmware v3.7
The above units I have added HomeKit integration on it.
The others 4 units are working normally under AirGradient dashboard and Home Assistance dashboard.
3 units AirGradient ONE (Generation 9) with LED bar and OLED display firmware v3.1.9
1 unit is AirGradient DIY Pro 3.7 no LED bar with OLED display v3.1.9
Monitor Serial Number: 8caab50f49dd
Monitor Serial Number: 7a9ad4
Monitor Serial Number: 84fce60be460
Monitor Serial Number: 84fce60be444
Do you have any idea about the reported issues?
Can you explain what exact firmware version is running on the older DIY models?
Do you use the exact version from our website or did you do your own adjustments?
By the way I am pretty sure this is not related to the OTA firmware update because that OTA only supports newer generation of monitors.
Here is more details as below:
-
Monitor Serial Number: 7a9ad4 is DIY Basic kit 1st Gen PCB
It is running on firmware under the AirGradient Library 2.4.15 AirGradient DIY BASIC ino file
I have added the HomeKit portion on the orignial software with no modified of AirGradient portion. It has been running since May 2023 up to now with no such reported issues. -
Monitor Serial Number: 7a9ad4 is DIY Pro v3.7 PCB
It is running on firmware under the under the AirGradient Library 2.4.15 DIY_PTO_V3.7 into
I have added the HomeKit portion on the original software with no modified of AirGradient portion. It has been running since May 2023 up to now with no such reported issues. -
The HomeKit portion is copy modified the Co2 as a sensor with reference of user gohai under AirGradient Integrations on May 2023.
-
The above 2 monitors are running older firmware version so it cannot support OTA firmware updates. The actual firmware version I am not recalled.
All others monitors are The AirGradient ONE Air Quality Sensor (Presoldered-Version, PCB Version 9) PCB which are updated to v3.1.9 by OTA and they are working normally.
The reported issues I just recovered a few days ago, during checking I find there are latest firmware v3.1.9 is released and all my The AirGradient ONE Air Quality Sensor (Presoldered-Version, PCB Version 9) PCB are updated and running normally. So, I do not know what is the root cause of it.
Thanks fo r your attention. I attached some screen shots for your reference, it may be helpful.!
I cannot recall the firmware version since the ino file no version remark on it. I only can recall when and what AirGradient library version that I have modified.
Hello,
The firmware page tell to " 1. Push the button on the PCB and keep it pushed" to update the firmware but I just had to plug my airgradient on my computer and start the update.
I postponed for a long time to update because I didn’t have the time to open my monitor and search for a button on the PCB, so I woul advise to change the wording to be less intimidating
For some users, the button does need to be pressed when plugging in the USB to the computer. There is a small hole in the case next to the USB port that you can use a small screwdriver or piece of sturdy wire to press the button through the case without disassembling it.
But sounds like you are all set
This is probably related to all firmware versions, but I’m currently on 3.1.9.
The issue is that standalone mode uses the stored values for OLED and LED brightness. If those values are “0” (off), then when booting into standalone mode, both will remain off making the unit essentially useless. I suggest the behavior should be to set the brightness to whatever the default is (probably 100%) when in standalone mode.
This happened to me when my network went down. I had an automation to turn off the OLED and LEDs at night and turn them back on in the morning. My network went down in the middle of the night and remained down due to hurricane Milton. This rendered the unit useless in standalone mode.
This might be a fairly unusual scenario, but should be an easy change in code for future releases. Thanks!
- Bryce
There is a small hole in the case next to the USB port that you can use a small screwdriver or piece of sturdy wire to press the button through the case without disassembling it.
I see it now. it would be nice to add a picture in the page I think, because I guess I’m not alone to think that I need to dissamble the monitor
FYI, the LED colors are wrong because this PR changed them to be wrong:
The new value of RGB_COLOR_Y—255, 150, 0— is solid orange, nowhere close to yellow. And the new value of RGB_COLOR_O—255, 40, 0—is red with the tiniest hint of orange.
Got the Aigradient ONE(Kit, I-9PSL) monitor on september 11 2024, updated it to 3.1.4 at that time, the PM levels seemed ok, at the end of september the PM levels started going down to 0 consistently, which can be probably correlated to auto update to 3.1.9 .
@Vlapaj Thanks for sharing.
I looked up your city of residence from our order system and outdoor air quality got a lot better around Sep 27. So I think this has nothing to do with the firmware versions. Just a general improvement in air quality.
Outdoor Air Quality.
Please do not take this personally, but I have zero trust in your company not ever making a mistake so grave that I would have to manually reflash the device again (in the best case).
Please make an API to upgrade to version X of the device where X is only available when it (“it” meaning all data sources that were being used by Home Assistant in the past week) has been working great for at least N users on three different continents for at least T days using Home Assistant. Please also make it possible to do a rollback managed by the end users (i.e., me (read: systemd services controlled by me)). Potentially make this configuration also part of the device firmware.
The main problems with automatic updates are:
- they happen outside my planned maintenance window and some times are really, really bad. I can imagine it could cost me thousands of dollars when an update happens at the wrong moment.
- I don’t see the code so, I have no idea what it is doing and whether or not you did something against my interests
- you won’t fix it by taking a plane from Thailand doing the reflashing when the day comes that you break every device (this could happen, if one of the workstations of your developers gets hacked) in the world, right?
- poor security (you likely don’t spend a lot of money on security, right?)
- Hardware can also just randomly fail, even if your software is perfect. If it fails, I want it to happen when I have time to handle any potential issue.
- I don’t have an API call to do a self-test telling me that the device is working properly. Right now that test is “look at graph and see whether it correlates with my perception”, which is awful.
- I am not implying you are a bad company, but I am just saying that you are setting yourself up for a huge disaster by not displaying a little bit of humility in the way you want to control devices. It’s really just overestimating your technological abilities, nothing more.
- I remember you do have some precautions to not brick devices, but in general the philosophy that “you will handle things”, is just wishful thinking: It has never ever worked for any company. The sooner you realize that a mistake or a random error could happen, the more reliable the system as a whole would become.
For example, in some locations (for example, when I am within 10 feet of the device with a setup in which I can flash with a push of a button)), I might want to deploy a newer version more quickly than in other areas where I need to be more conservative. Additionally, for versions that only add features, I might not want to install those at all, until I am ready to look at what the features are about. For pure bug fixes, I might trust you to make things better, if you show some kind of CI-setup. I didn’t look at what you showed about that.
If you are not going to implement something like that, I would have to resort to adding extra infrastructure to actively block part of your device, since you would technically be deploying malware to my network then, which is not fun either. I’d hope that you document from which sub domain the OTA-updates exactly come from, because otherwise blocking would become annoyingly difficult.
I hope this helps guide your roadmap somewhat. If it doesn’t, I would have to toss these devices in the garbage at some point in the future when they will inevitably break due to human error, and find another way to implement what your device offers (which from my layman’s perspective, seems to meet my requirements).
Good luck in making airquality monitoring more reliable.
We do actually have that functionality already in place but it’s not exposed to the end user yet. So we can lock, up or downgrade specific monitors based on the serial number or for a whole place.
I discussed this recently with the team and I think it’s a good idea to add this functionality for the end users.
@Vlapaj this also happened to me (PM going to zero the majority of the time after upgrading to 3.19), but I also have a non-AG monitor and it’s also showing the same value. So I think the timing with upgrading to 3.19 is maybe just a co-incidence.