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.