AirGradient Forum

Feature Request: API IP Address Information/Static IPs

Just received my AirGradient ONE today and so far I am very happy with it!
Very easy to setup out of the box, didn’t run into any issues.

Accessing local information is easy and straight forward a la arduino/docs/local-server.md at master · airgradienthq/arduino · GitHub using the mDNS name.

But I noticed an interesting design choice or oversight in reporting. In both the AirGradient Cloud App and locally using the API, the actual IP address information isn’t published. I wouldn’t have even questioned this, but the API actually reports wifi signal strength out of the box?
e.g.

{
  "pm01": 0,
  "pm02": 0,
  "pm10": 0,
  "pm01Standard": 0,
  "pm02Standard": 0,
  "pm10Standard": 0,
  "pm003Count": 44.5,
  "pm005Count": 22.17,
  "pm01Count": 0,
  "pm02Count": 0,
  "pm50Count": 0,
  "pm10Count": 0,
  "atmp": 22.51,
  "atmpCompensated": 22.51,
  "rhum": 32.59,
  "rhumCompensated": 32.59,
  "pm02Compensated": 0,
  "rco2": 619,
  "tvocIndex": 131,
  "tvocRaw": 31484.5,
  "noxIndex": 1,
  "noxRaw": 16953.33,
  "boot": 159,
  "bootCount": 159,
  "wifi": -59,
  "ledMode": "co2",
  "serialno": "744dbdcf7b30",
  "firmware": "3.1.21",
  "model": "I-9PSL"
}

I’m an IT professional, so getting this information from my network infrastructure was trivial for me, but may be more challenging for some. Althought I suppose the mDNS name sorta solves this problem, but then you are relying on mDNS working. For home use thats fine, but in an Enterprise world with multiple VLANs and routing domains, at scale mDNS can be challenging.

{
  "pm01": 0,
  "pm02": 0,
  "pm10": 0,
  "pm01Standard": 0,
  "pm02Standard": 0,
  "pm10Standard": 0,
  "pm003Count": 44.5,
  "pm005Count": 22.17,
  "pm01Count": 0,
  "pm02Count": 0,
  "pm50Count": 0,
  "pm10Count": 0,
  "atmp": 22.51,
  "atmpCompensated": 22.51,
  "rhum": 32.59,
  "rhumCompensated": 32.59,
  "pm02Compensated": 0,
  "rco2": 619,
  "tvocIndex": 131,
  "tvocRaw": 31484.5,
  "noxIndex": 1,
  "noxRaw": 16953.33,
  "boot": 159,
  "bootCount": 159,
  "wifi": -59,
  "ledMode": "co2",
  "serialno": "744dbdcf7b30",
  "firmware": "3.1.21",
  "model": "I-9PSL"
}

Secondarily, I was looking to see if I could set the IP address to a static address. For a whole host of reasons, any appliance like device of which I would consider this sensor, I prefer to keep a local static address assigned to it. This doesn’t seem to be available in /config e.g.

{
  "country": "US",
  "pmStandard": "ugm3",
  "ledBarMode": "co2",
  "abcDays": 8,
  "tvocLearningOffset": 12,
  "noxLearningOffset": 12,
  "mqttBrokerUrl": "",
  "temperatureUnit": "f",
  "configurationControl": "both",
  "postDataToAirGradient": true,
  "ledBarBrightness": 10,
  "displayBrightness": 20,
  "offlineMode": false,
  "monitorDisplayCompensatedValues": false,
  "model": "I-9PSL-DE",
  "corrections": {
    "pm02": {
      "correctionAlgorithm": "epa_2021",
      "slr": null
    }
  }
}

I’ll probably end up connecting to the serial port and dig around, but I really would prefer not to. Having the API safety belt is always preferable. As an example, is there a “reset” button for the WiFi, and would setting a static IP from the console break this functionality?

In any case, I’m planning on using Uptime Kuma as I do with all of my other random devices to give me an alert when particular sensor values get way too out of whack.

Having “http://airgradient_744dbdcf7b30.local/measures/current” just dump some JSON to parse is a fantastic design choice and makes integrations like this simple.

I can use Uptime Kuma to parse the JSON key for “rco2” and alert me on all of my devices when it goes above 1000, as an example.

Hi @nickf1227

Sorry for this, but i don’t understand your first question, is it why we’re reporting wifi signal?

I think about static IP, you can set it from your router by using the device mac address. The serial number of the device is actually a wifi mac address (aabbccddeeffaa:bb:cc:dd:ee:ff)

1 Like

Sorry that I was not clear. All I meant to say was that I found it odd that the API has a function to report wifi signal strength, but it does not report what it’s current IP address is. These two pieces of information are equally important, but for differant reasons.

I will appologize upfront, I am not a programmer and I have zero practical knowledge of C++. What limited coding I have done has been primarily Python.

But I would love to see this variable “DEBUG_WM(WiFi.localIP());”

Available here:

So that it looks similar to this:

{
  "pm01": 0,
  "pm02": 0,
  "pm10": 0,
  "pm01Standard": 0,
  "pm02Standard": 0,
  "pm10Standard": 0,
  "pm003Count": 44.5,
  "pm005Count": 22.17,
  "pm01Count": 0,
  "pm02Count": 0,
  "pm50Count": 0,
  "pm10Count": 0,
  "atmp": 22.51,
  "atmpCompensated": 22.51,
  "rhum": 32.59,
  "rhumCompensated": 32.59,
  "pm02Compensated": 0,
  "rco2": 619,
  "tvocIndex": 131,
  "tvocRaw": 31484.5,
  "noxIndex": 1,
  "noxRaw": 16953.33,
  "boot": 159,
  "bootCount": 159,
  "wifi": -59,
 "ip_address": 10.69.10.92
  "ledMode": "co2",
  "serialno": "744dbdcf7b30",
  "firmware": "3.1.21",
  "model": "I-9PSL"
}

This isn’t the same thing. The wifi module in the Arduino is set to DHCP. If you make a DHCP reservation on your router, it is true that your router will reply back with the same IP address the arduino had before. But this requires your router to have a DHCP server running to function. In large non-home environments, it is very common to have subnets and VLANs that do not have a DHCP server running in them.

I’m asking that this function:

Be available here:

So that it looks more like this:

{
  "country": "US",
  "pmStandard": "ugm3",
  "ledBarMode": "co2",
  "abcDays": 8,
  "tvocLearningOffset": 12,
  "noxLearningOffset": 12,
  "mqttBrokerUrl": "",
  "temperatureUnit": "f",
  "configurationControl": "both",
  "postDataToAirGradient": true,
  "ledBarBrightness": 10,
  "displayBrightness": 20,
  "offlineMode": false,
  "monitorDisplayCompensatedValues": false,
  "model": "I-9PSL-DE",
  "ip_address_mode": "static",
  "ip_address": "10.69.10.69",
  "subnet_mask": "255.255.255.0",
  "gw_address": "10.69.10.1",
  "dns_1": "10.69.10.10",
  "dns_2": "10.69.10.11",
  "corrections": {
    "pm02": {
      "correctionAlgorithm": "epa_2021",
      "slr": null
    }
  }
}

Does that help clarify? @Samuel_AirGradient .

Thanks for taking the time to look.

Okay, I understand now.

Adding the IP address to /measures/current isn’t difficult to implement, but I don’t see a strong reason to do so. To get the IP address from that endpoint, you’d still need to request it via mDNS, right? Or maybe you have a different method in mind.

Another approach is what Home Assistant does: it discovers the device using mDNS, and then the resolved IP is used to communicate with the device. If the device becomes unreachable, it will start over by discovering the device again.

As for setting a static IP, we’ll considering it for now. Of course, if someone wants to implement this and submit a PR, we’d be happy to review it. However, I don’t think using a PUT request to set a static IP is the best approach. Instead, it would make more sense to configure the static IP settings on the Wi-Fi setup page.

Right, you would have to get it via MDNS. But your docs already are very good in that regard so it would make finding the IP simple enough for most users.

This requires an already configured external system, so I’m not sure that helps in any meaningful way to a large percentage of the user base. In my case, I just found the MAC address in my Wireless Controller and then found its associated IP. Which is fine, but again required an external system to find information that could be available locally.

I would have already done this, but again, C++ is a bit out of my wheel house. I can certainly give it a try, but I didn’t want to waste your time in reviewing bad code I used an AI to help me write.

However, I don’t think using a PUT request to set a static IP is the best approach. Instead, it would make more sense to configure the static IP settings on the Wi-Fi setup page.

I think it would make sense in both places. For sure it would be very helpful in WiFi setup! If you want to MOVE the sensor to another network (like one on your network, but in a differant building as an example), it would be nice to be able to pre-configure it without having to jack into the serial console each time. If you are provisioning several AirGradients from your desk to go deploy out in the field, this would be very useful.