Good idea. We will implement this.
1 Like
Mine did the same thing. I put the 2nd PM sensor back until the firmware is fixed.
Maybe a note in the documentation is in order?
We have this already fixed in the firmware and will roll it out in the next few days.
New firmware is available.
https://www.airgradient.com/documentation/firmwares/
Version 3.0.7:
- fixed problems on Open Air without SGP41
- now broadcasts mDNS service as “_airgradient”
- ‘add to dashboard’ also now shows serial number
- improved log messages
It still needs to be reconnected to WiFi after flashing even if “erase” is not checked. I don’t know why this happens. If anybody has an idea, let me know.
1 Like
I’ve noticed that http://airgradient_[serial].local/measures/current only publishes PM data for the first few minutes and then those values are dropped completely … not sure why
{“wifi”:-57,“serialno”:“serial”,“rco2”:542,“tvoc_index”:101,“tvoc_raw”:31502,“nox_index”:1,“nox_raw”:16676,“atmp”:30.31,“rhum”:33,“boot”:11}
edit: looks like they come and go. if the values are too low to read could we just publish them as 0 if that’s what’s happening? having them disappear from the data feed is weird.
We are investigating this issue.
1 Like
I tried out the mDNS Service Discovery, but it didn’t quite work. With these changes it works: Fix MDNS Service Discovery: by austvik · Pull Request #79 · airgradienthq/arduino · GitHub
This removes the http service announcement from the same port as the _airgradient service announcement. It might be the correct thing to do unless you want to host web pages on it. I am not able to get _airgradient._tcp.local. discovery to work with http on the same port, but I am not sure if that is a bug in the library I am (inderectly) using or it is dictated by the protocol.
In addition to my suggestion to making tvoc all capital letters, I also noticed that the CO2 column feels cramped when 4 digits are needed. When the final number was a 5 it looked even more like it was touching the vertical line.
I haven’t had a 3 digit PM2.5 value yet, but it seems like it would also be cramped
There is plenty of empty space on the far right next to TVOC so it all could be slid over to the right to give a bit more space
I found some additional inconsistencies which it is probably easier to align before there are too many users:
This adds the possibility to read ledMode. I have also started to play with the possibility to change configuration locally (for e.g. ledMode), this is harder than it sounds, because the setting from the cloud API overwrites it. If one wants to support configuration locally one might need to define that the sensor is the “master copy” of the configuration and change the way the configuration flows between the sensors and the cloud API, so that it is the sensor that uploads the configuration to the cloud API instead of how it is now where the sensor downloads the configuration from the cloud API.
And here is one for triggering Co2 calibration locally:
Thank you @Jorgen_Austvik . We are also currently working on a local HA integration which would then also need to allow local setting of configuration like CO2 calibration and LED mode. There are different ways to achieve it. It probably makes sense to have that discussion on GitHub directly.
1 Like
Is this a typo? the latest firmware on the page is still 3.0.6
Absolutely. Here is what I have if we want something to discuss on:
New Firmware 3.0.8 is available here.
- Fixed -1 readings on PM module
- Disabled reboots in offline mode
- Fixed mDNS double broadcast
- Various small bug fixes
Not (yet) included is endpoint on how to make configurations to monitor locally. We need to see what is the best approach for this (pull from monitor or push to monitor).
This update should fix the issue when people got “-” instead of PM values. Please feedback if you notice anything.
Next big thing in the pipeline is OTA capability.
1 Like
Hello,
I am bit confused. My OpenAir kit just arrived and when commissioned to the Dashboard it seems to have fw 0.4.0. This fw is not listed in the Beta Firmwares at all.
Monitor Maker: AirGradient
Linked Location: Home
Firmware Version: 0.4.0
Model: O-1PS
Monitor Commissioning Date: Mar 20, 2024
It also seem that I am having issues with MQTT - I did set MQTT in the Dashboard into:
mqtt://user:pass@192.168.1.1:1883
But I do not see any connection in the tcpdump on my MQTT server originated from the sensor (except of the arp requests for itself).
Please flash the latest firmware by following the steps below.
https://www.airgradient.com/documentation/open-air-pst-kit-1-3/#firmware
This will support MQTT.
Yep, you are completely right. I was confused by fw versions, thought that 0.4.0 is 4.0.0. Seems that units are shipped with some old fw versions. Anyway flashed, fixed, MQTT is working, thank you.
Hi there, I got the DIY BASIC kit in June of 2023, soldered it, flashed it, and have been using the airgradient dashboard with it. I didn’t update it since then, until today, when I tried flashing with version 3.0.8 - I prefer not to use Chrome, I build and flash with the Arduino IDE.
Long story short, I needed this change for the device to work with the airgradient dashboard service:
--- a/examples/BASIC/BASIC.ino
+++ b/examples/BASIC/BASIC.ino
@@ -723,7 +723,9 @@ static void dispHandler() {
displayShowText(ln1, ln2, ln3);
}
-static String getDevId(void) { return getNormalizedMac(); }
+static String getDevId(void) {
+ return getNormalizedMac().substring(7,12);
+}
/**
* @brief WiFi reconnect handler
This is because when I registered by DIY BASIC monitor last year, it took the last 5 hex chars of the mac-address as the device ID. But now (the example sketch for the DIY Basic from) firmware 3.0.8 is using the full 12-char mac address as the ID. So … are devices registered now with the full 12-char ID, or is this a bug in the DIY BASIC monitor sketch example in version 3.0.8?
How I figured this out, was seeing this in the serial output:
Post payload: {"wifi":-36,"boot":0}
Post response failed code: 400
Device id: d8f15b084ea4
(I’m gonna go ahead and not worry about the security implications of revealing my device mac addr, but I do realize that this ID from the mac addr is a kinda important though fairly weak secret, maybe that’s why it was increased to full 12 chars?)
… and testing this url from the code with curl:
String uri = "http://hw.airgradient.com/sensors/airgradient:" + id + "/one/config";
… showed that the short 5-char ID I’m familiar with worked, while the long one resulted in 400 “sensor is not configured”.
If it’s not just a bug in the sketch example and/or distributed binary firmware, perhaps the server should check if there’s a registered short ID that happens to match the end of the long ID, and then auto-migrate the short-ID.
1 Like
Yes that’s a good point. I will discuss it with our developers.
1 Like
I have encountered an issue with reconnecting to WiFi after turning off the router for some time. After turning it on, Airgradient One with firmware 3.0.9 can’t connect to WiFi until I turn it off (unplug and plug it back in). This issue has likely been occurring since version 3.0.8.
Example: At 09:00, WiFi is disabled, and AirGradient One loses connection. At 11:00, WiFi is enabled again, but AG One can’t reconnect until I turn it off and then back on.