AirGradient Forum

Bad software experience for non-cloud users

#1

I’d like to start by saying that this is a lovely product! Thank you for making air monitoring accessible.

However, as someone who didn’t want the dashboard and only wanted polling the device over HTTP WiFi, the first-time experience was very, very confusing.

1. I could not find any information on what the different display readings mean (CO2, PM2.5)

Only after watching some YouTube videos I learned that this type of documentation is only available after logging in to the dashboard and pairing the device. It should be available in the regular documentation for everyone, even those who haven’t bought the product yet. I had to make an account only to be able to see the documentation.

2. Airgradient insists on connecting to the server

On first WiFi setup, the air gradient offers you the option of preventing cloud connection. This option is ignored as of firmware 3.1.21 I-9PSL , and whenever the device connects to WiFi, it will also connect to the server.

3. Configuration options unavailable without the dashboard

I couldn’t find documentation on how to adjust the settings (LED settings, pm2.5 correction formula, etc) without the cloud dashboard.

4. Update without permisssion

After giving up and connecting to the dashboard, for the sole purpose of seeing the docs and adjusting the settings, the device immediately updated from 3.1.13 to 3.1.21, a version not even available in the changelog. I panicked and thought I was being hacked, until I read in the forums this version is real but not yet in the changelog.

5. http routes are poorly documented

After finally setting it all up, I couldn’t find any mention of how to poll the sensor data. I eventually found the /measures/current route in the changelog. And it made me wonder what other routes have I missed. I wish there was a route for adjusting the settings.

All in all, great hardware, great software, but the non-dashboard experience looks like an afterthought, and there’s lots of low hanging fruit you can do to make it a lot better with very little effort. Thanks!

1 Like
#2

Thank you for pointing these out. I am on my phone, so just some quick answers:

  1. Good point. We will put something directly on our website
  2. This is an unfortunate bug that we already fixed and will be rolled out in the next release.
  3. This is part of the GitHub documentation. See arduino/docs/local-server.md at master · airgradienthq/arduino · GitHub
  4. The firmware can be fixed on the dashboard under Place Administration.
  5. I believe also documented in arduino/docs/local-server.md at master · airgradienthq/arduino · GitHub

I hope that helps.

2 Likes
#3

Does this help with what the different readings mean?
AirGradient Cheatsheet

2 Likes
#4

Thank you! The GitHub documentation is great, but as someone who scanned the barcode that came with the product, followed the build instructions, and looked in the “documentation” tab in the website, I did not know it exists!

Proposal: Add two “entry points” to the Github doc:

  1. In the integrations page, add a “HTTP API” section.

  2. In the build instructions, right after the dashboard section, create a “Other integrations / server options” section, which links to the Integrations page.

Sample text for #2

Other than the cloud dashboard, air gradient supports various other integrations such as OpenHab, Home Assistant, an HTTP API, and more. See the integrations page for more information.

Rationale:
The dashboard section in the build instructions is exactly where my confusion started. I was expecting non cloud abilities but couldn’t find an HTTP API in and the dashboard was the focus. Then I looked in the integrations but it didn’t help.

2 Likes
#5

Regarding (4), maybe add a cloudAutoUpdate boolean to /config?

Rationale: Without this, a non-cloud user who decides to enable the cloud (whether permanently or temporarily for testing) might get an unexpected firmware update.

#6

More good news for you:

  1. You are not the only one who wants these improvements
  2. It looks like the ticket from last June about not being able to compile will soon be fixed, which (in combination with the fix to not phone home to AirGradient’s servers) will make it possible for me to do development work without setting up an entirely separate WiFi network without any internet access

So it does look like help is coming in the foreseeable future.

1 Like
#7

Note regarding docs:

After a second look, the build instructions already has a link to the web server API.

However, it’s under the section “Home Assistant & Local Server”. I had completely overlooked that section because I thought it’s something specific to home assistant. I think a very minor re-write similar to what’s proposed in my previous comment can better direct people who are looking for using the local server.

1 Like
#8

Here’s an update/how-to-guide for those who Do not want to use any cloud / Home Assistant features and are evaluating the Airgradient for such a use case. Relevant use cases:

  • You just want to see the physical displays.
  • You just want a local HTTP API you can query

Brief Summary: The product is more than capable of working in the above modes! These things are mostly documented. My problem was only with the onboarding/discoverability of the docs (see the start of this thread) which the Airgradient team seem to be working on improving.

How-to guide:

If you just want to look at the displays in completely offline mode:

When the Airgradient starts up, you have a brief opportunity to press the button on the back and switch to completely offline mode (the display will indicate that it’s waiting for such a press). You don’t have to use WiFi at all.

If you want a local HTTP Server on the airgradient

The Airgradient creates its own access point for 3 minutes. (Password is “cleanair”), When connecting to the AP, you are greeted with a web page which can configure:

  • Which WiFi access point the Airgradient connects to.
  • Whether the airgradient should ever connect to the cloud.
    • This option had a bug which was fixed in Firmware 3.2.0.

Once configured, the airgradient will no longer create an access point and instead connects to the existing WiFi as configured. You can then query it using the local server API . You can also change most config from there.

Changing the access point

The only way to re-trigger the greeting screen and to make the Airgradient re-create its own access point, is to turn on the Airgradient out of reach of its host AP. E.g. you can turn off your router and re-start the Airgradient.

Changing connect-to-cloud toggle (Internally called disableCloud)

See “Changing the access point”. You have the opportunity to also adjust the checkbox responsible for this. You cannot change this setting from /config

1 Like
#9

I’ve submitted a merge request for that aforementioned bug. Help with testing would be appreciated.

#10

Hello! I’m about 80% sure i’ll be getting an airgradient monitor this year but i’m uninterested in cloud operation on personal philosophy grounds. I don’t have any domestic automation set up either though and OLED+LED operation only is insufficient. My preferred way of interacting with similar equipment is local web-based UI but i’ve been struggling to find information whether one is present at all or what its features are. Also, is there any onboard logging functionality or does that have to be done in cloud or DA as well? I’ve seen it mentioned that local HTTP API offers control over most settings- which settings are available through cloud only?

Thanks a lot in advance!

#11

I’m not aware of a local web-based GUI, although someone recently asked in the forums if there was interest in something like it. But when pointed to HomeAssistant and it’s local integration, you can get access to all of the configuration in the HA GUI, plus graphs, automations, etc.

So I don’t think something exists now, and I don’t know that AirGradient would invest resources into making/maintaining one at this time, since there are multiple other options out there.

No onboard logging due to limited memory, so you need something that can collect the current metrics and store them separately.

I can’t think of something the local API can’t configure at this time, other than firmware updates.

1 Like
#12

Thanks, bummer about the web UI. I’ve come to take them for granted with ESPs. I’ve considered getting HASS running at one point either on a Pi or our beast of a router but it seems too resource hungry for what would be a logger, then for ATC/Mithermometer units, now one air quality sensor.

The omission of an SD slot or similar makes sense in a cloud-first device though in an open source design i’d hope the dashboard server code would then also be deployable locally to not have to spin up a whole domestic automation server…

Is there a middle of the road option i’m missing, a lightweight external readout/ logger or perhaps an alternative FW that adds some of that functionality?

#13

I guess it all comes down to your expectations. With HA it can easily run on a Pi and can do all of your graphing as well as do automations if you have any other devices it can integrate with, such as turning on a smart plug or activating your HVAC fans. It is worth it in my opinion. I have temperature probes on my HVAC in and out ducts to get the temperature changes overtime.

I haven’t seen many ESPs that have an SD slots in their most basic config, and even if not being cloud first, normally the device would either be queried or it would push metrics to something external, even a local Graphana/Prometheus setup so you could get graphs another way, but now you are back to running several external things.

There is an ESPHome firmware that could be ran on the ONE device and you could enable the web server to get access to some of the value, but still no graphing over time, just a real-time view and control over the features like the LED bar or display contrast, etc. But you are doing more to get that installed as well, so might as well just do HA.

#14

Only justification i’ve come up for HA in our leased flat is to aggregate various measurements but with the way our utilities are metered all interfaces would have to be long range wireless and battery powered, hassle not worth me while to date. We do have WLED-based moodlights that are super nice on a schedule and thanks to syncgroups and onboard macros they automate themselves and each other perfectly, no need for 10W of Pi and a kernel running. Same thing with the temp/humi sensors, they log onboard, i download them one by one once or twice a year or after making a change and graph them. Yearly X-Y temp-humi heatmaps show interesting patterns.

ETA also apparently polling the BLE thermos directly from Pi kills SD cards since BlueZ always reads and writes tiny snippets, adding another device, an ESPhome based BLE-MQTT gateway iirc, making the endeavour feel even less reasonable. The AG might tip the balance going forward but still.

One thing i absolutely would run to gather the AQ data would be a nice weather station setup, could be the final straw that gets me to build one. I’ve seen RemoteWeather mentioned on this forum, that doesn’t seem to be open source (yet), i’ll be looking in the weather direction.

#15

Come to think of it my foremost motivator for local-first equipment is portability. My intention with the AG ONE is to have it spend some time in my office, in different rooms of our home, and understand how those spaces ventilate, how often they get very unhealthy etc., and readjust behaviours. Albeit it’s not a sensor platform, the WLED shows a good UX example in that at home the devices connect to wifi and are all integrated, UI of one links to UIs of other WLED devices in the network so the experience is very seamless, but if i take one light with me to a party, it’ll expose its AP offering the same functionality without needing any existing network at all. Just the same as i carry the Mi thermo on a backpack for hike weather logs that work the same way home logs do.

I wonder how common this preference might be.

I’ll probably end up paying for the cloud because AG folk seem distinctly unlike google, amazon and the like and the crowdsourced AQ aspect seems like an endeavour worthy of support but i would like to make the case for robust local operation here in describing the way i have been building my digital ecosystems-

loosely wound networks of robustly autonomous nodes as opposed to centralised and stationary automation setups or internet-requiring cloud-first devices.