[RELEASE] PurpleAir AQI monitoring driver

Is the AQI actually part of the value or just the units?

If it's just the reported units, then if you're using the Hero Attribute Tile to display the value in SharpTools.io, you can disable the units in the tile settings:

image

1 Like

@josh You nailed it! Thanks for the help...

1 Like

Adding the private key field was too easy, I knew there had to be a catch! I'll take a look over the weekend and see how much work is required. I'd love to get private keys working if it's not too much effort.

1 Like

Hi sidjohn1,

I just got around to this and based on the documentation it really does seem like the query for a private device should work as long as you add the read_key. It's not entirely clear why your test didn't work. We can try removing the max_age attribute though. Based on the example data you provided that doesn't seem like it's a problem, but we probably don't want it for that type of query anyway.

Could you modify line 111 of my driver to remove the max_age filter like this:
httpQuery = [fields: query_fields, read_key: Read_Key, show_only: "$sensor_index"]

Then see if it makes any difference?

Hi @pfmiller, it looks like data calls aren't working due to the API changes PurpleAir did earlier this week. Will you be updating the driver?
For now, a quick fix was to switch to the legacy API by changing the url from "api.purpleair.com" to "rollback.api.purpleair.com", which works again. Not sure how long they will be supporting this though.
Thanks!

1 Like

@pfmiller I noticed the same as @cchan. Hoping we'll be able to maintain this.

Interesting... PurpleAir noticed that I was using the rollback API from my key, and someone contacted me about why I was using it. It sounds like there shouldn't be significant changes with the new API though.
I'm going to try to look at it this weekend, presume it's something relatively minor to do with either the request format or response parsing. I've dabbled with APIs, but not expert enough to tell off the bat what's going on.

Hi guys, there is a newer version up that should be working again.

3 Likes

Thank you!!!

You're welcome, it was a pretty minor fix. The new API wasn't supposed to change anything but it changed around the order that the results were sent back in. I'm also testing a better fix so that the order of the results isn't hardcoded to better handle future changes.

1 Like

Thanks, working great for me using a neighbor’s outdoor sensor. Is this confirmed working on private sensors? I’m looking at getting a PA-1 for indoors and registering it private. Thanks again.

Unfortunately I don't have access to a private device to test with, so I can't really say if it's working or not. I hope it is, and I'd like to get it working if there's any issue.

An updated version is now available that doesn't have the order of the results hardcoded, should make things a little more resilient in case of future API changes.

3 Likes

Just started using this driver, it is excellent. THANK YOU!

2 Likes

I get a NULL exception if I select just my own sensor instead of an area.
Fixed it with the following addition

Float distance(Float[] coorda, Float[] coordb) {
    if (coorda == NULL)
    {
        return 0.0
    }
    else
    {
    	// Haversine function from http://www.movable-type.co.uk/scripts/latlong.html
       ...

I also for my own use added temperature and humidity reporting because that's what the old driver used to publish, but looking at the API page they're not good data points since the sensor is inside the housing being heated by the electronics.

1 Like

Thanks, updated my driver to fix that issue

Would it be possible to draw up a driver that would instead of using the cloud, use the local network IP address to provide the data to hubitat?
Apparently MeteoBridge has done that and is pulling the data from the local IP.
The deeper reason are (1) emerging pay for service scheme at PurpleAir (2) sensors going broke (3) needing only local value (related to (1)).

I'm sure it would be possible, but I would consider that out of scope for this driver. I personally don't have a PurpleAir sensor of my own to use it with or test with.

@pfmiller does your driver support any of the recommended Purple Air correction factors such as LRAPA, WOODSMOKE or US EPA? These formulas compensate for the fact that the Purple air sensors don't properly measure the density of woodsmoke particles, which results in reporting an inaccurate AQI.

The screenshot below of slide 26 of this deck has the formula for the US EPA correction. The deck provides a through explanation of how they evolved these correction factors over several years.

If not already supported, would you consider adding this as an option to your driver?

Thanks!

Marc

Hi Marc, I should be able to add some of those conversions, I will look into it!