-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PurpleAir is discontinuing the API this plugin uses #14
Comments
Looks like Purple Air has implemented the change. 😦 |
Please use the code from Schweigi below - don't use my awful kludge here.@NathanBlais Good news! If you get HTTP Advanced Accessory, you can use the sensor's webserver to extract the air quality readings without needing the API. The annoying news is that you'll have to code it directly into the JSON configuration yourself, and I haven't worked out any way to combine the A and B sensors into a single averaged reading the way PurpleAir does (it should be simple; just add this to that and divide by two, but I can't work out how to make that happen). So you'll get two air quality sensors out of this. Also, HTTP-AA really doesn't like extracting the temperature values for reasons I can't figure out. That said, to save you a world of grief, my code to do this is below, refined from a lot of painful trial-and-error. It works so long as the sensor is connected to the home network, even if the internet is not available. I've used the more hardline Tasmanian standards for when to cut off the ratings like "excellent" (that's the code of "if(value >= 0 && value <= 9){value = 1}" - adjust them as needed). What you need to do to make this code work:There are two things you have to do to make this code work for you; first replace every instance of XXX.XXX.XXX.XXX with the IP address of your PurpleAir sensor (no login or key is needed), and second assign the sensor a static IP in your router, or you'll have to do that every time it changes IP address. Otherwise, you should just be able to copy and paste this into the appropriate place. Note this code will pull the live values. The code for the JSON:
|
@nashnix - Instead of using the
|
@Schweigi Thank you very much for that! I've replaced my horror mess with your code, and it looks like it's working wonderfully (unfortunately the air here is really clear right now - so I can't tell if the values are actually 0, or if something went wrong and it's just saying that). You can probably tell that I was pretty much just throwing myself at it (and trying to learn this coding language) until I found something that sort-of-worked. The result is the brutal kludge you see in my comment above. |
I tried to use the code above, edited the xxx IP for the local IP of my purple. I could not save the code.. it would just hang in its saving mode for a few hours .. Any suggestions? thank you |
@adresner Are you using my awful kludge at here, or @Schweigi's excellent code at here? With my awful kludge, you can just copy and paste it and swap out the XXX.XXX.XXX.XXX. But Schweigi's needs a couple little changes made to it to make it play happily with the HTTP AA thing. I've copied my (working) code directly from my config.json file in full; if you swap out the XXX.XXX.XXX.XXX in the code below with the local IP of your Purple, and just paste it in via the advanced configuration page, it should work:
One last note; I used the Tasmanian values for what is good and bad air, so it's a bit more sensitive to that than most others. |
Thank you for helping... The code you shared allowed HOOBS to save the file under advanced. I changed the xxx to my local IP of my purple. But now, nothing showing up in home.app I even deleted and re-added the bridge. My Hoobs is fully up to date as well... frustrating - any other ideas? Cheers |
Hey @adresner, Sorry to hear it's not cooperating. Here's a step-by-step of what I did to get mine working. If you follow this, it ought to behave:
If you're seeing this, great! The sensor is connected and the plug-in should be able to get to it. If you can't, then something is blocking access; check your wifi, your firewalls, make sure things are on the same subnet - all that sort of thing.
It is helpful if you have a second screen here; open the HOOBS interface in a browser like you normally would and set it to the log page so you can see what's happening. Do your configuration in the app, watch what happens via a browser.
It should work now, but be warned that it'll be added to some random room. It could be "Default Room". The first time I did this it got added to the bedroom; the second time it was the kitchen. You may have to go on a hunt to find the thing (and if you have another air quality monitor, it could be hiding behind that one, because of course it does). Hope it works! |
PurpleAir has made the change and this plugin will no longer work. There is a workaround here.
As per their Using PurpleAir data document, PurpleAir is migrating all users to a new API at https://api.purpleair.com/, and will soon be blocking all access to purpleair.com/data.json and purpleair.com/json.
Users will also need to contact PurpleAir by email to get a key to access the new API, which would need this plugin to provide a place to provide that key.
Next day edit:
There may be a workaround; the sensor has a webserver open on port 80, and from that the user can find a string of data that gets reported out to PurpleAir (it can be found at http://192.xxx.xxx.xxx/json). I'm not sure how to go about doing this (my java-fu is very weak, and so far I've only got an error log a mile long to show for it), but if this string could be accessed and the readings extracted, then that would eliminate the problem of the API access altogether. There's also the option to expose the PM1.0 reading, dewpoint, and air pressure, and make these available to the user.
There'd be a bit of calculation involved though to make the values match what the PurpleAir map shows; there's the humidity and temperature divergence issues that have already been raised, but also there are two particulate sensors in the device, and this method exposes both of them as-is, so that would need to be taken care of as well (but I'm pretty sure they just average them, unless one of the sensors dies).
The text was updated successfully, but these errors were encountered: