Python Plugin: OpenAQ Topic is solved

[FireWizard]

Hi,

@Jan Jansen

You are probably right, as I found that I'm using an older version, which updates every hour and not every minute.
Looked into the source, but except of that line I cannot find anything that indicates the update frequency.

So @Xorfor has to answer this question.

Regards

[Xorfor]

Fortunately openaq.org allows unlimited requests in their API .

Because of a big change in Oct 2019 in the plugin, the self.__MINUTES was not used anymore. I have updated the plugin and implemented this again and now the plugin will update the sensors only once per hour.

[Jan Jansen]

@ Xorfor,

Thanks for your time and attention, it works as desired!

Regards
Jan

[FireWizard]

@Xorfor,

I have installed the new version and I can confirm that it works as intended.

Regards

[rrozema]

(Air quality) openaq returned a status: 504

It has been doing this since yesterday. It's probably them having an issue, not a problem of the plugin.

[FireWizard]

Hi,

I think, it is an incident, as I saw it only once in the log:

2020-11-23 21:29:33.373 Error: (Air Quality) openaq returned a status: 504

From: https://developer.mozilla.org/en-US/doc ... Status/504

The HyperText Transfer Protocol (HTTP) 504 Gateway Timeout server error response code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server that it needed in order to complete the request.

Regards

[rrozema]

Hi,

I think, it is an incident, as I saw it only once in the log:

2020-11-23 21:29:33.373 Error: (Air Quality) openaq returned a status: 504

From: https://developer.mozilla.org/en-US/doc ... Status/504

The HyperText Transfer Protocol (HTTP) 504 Gateway Timeout server error response code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server that it needed in order to complete the request.

Regards

I agree that it is probably an incident at their side, and as such it will probably go away once they discover there's a problem in their server(s). However, it is happening every +- 5 minutes in my log, so that's why I wanted to share this to let others know it is not just them . I also see 503 errors every now and then.

[waltervl]

Seems that Xorfor was so nice to update the plugin yesterday to the new OpenAq V2 Api. I just tried and it seems to work. I get measurements but have to wait 1 hour to see if they update....

So in the plugin folder of OpenAQ do a git pull and it should work again after an update of the OpenAQ Hardware in Domoticz.

[Derik]

Hi... looks the plugin is gone on git..
Only after a new setup in domoticz is in my db the plugin "working"...
And i cannot remove the plugin because he is not there..
Some a solution?

[waltervl]

I am currently updating this plugin as it now needs an API key to get the data. It is testing at the moment. I will report back when it is working properly...

[waltervl]

It is running now for some hours, everything seems to be OK.
So the modified fork is here:
https://github.com/waltervl/Domoticz-OpenAQ-Plugin

To update from the old plugin
1. Edit the config file in the .git folder of the plugin and change the url from Xorfor into waltervl

Code: Select all

url = https://github.com/waltervl/Domoticz-OpenAQ-Plugin.git

2. Do a "git pull" in the plugin folder to update the plugin.
3. Register on OpenAQ and get your API KEY from https://explore.openaq.org/account.
4. Restart Domoticz
5. Go to menu Setup - Hardware, select the plugin hardware gateway and add the API KEY to the OpenAQ plugin configuration.
6. Click on Update. Now the plugin will start and succeeds to login and update the existing devices.

Alternative for step 1 and 2 is to go to the github repository, copy the contents of the plugin.py and paste it into the plugin.py of your Domoticz server and so overwiting is contents.

[JayDotR]

Hi Waltervl,

As the plugin was working well until october 2024, I read that the old API calls in V1 and V2 would be decomissionned in a near future (it happens that they redesigned the API). I permitted myself to fork your plugin and redesign it a little bit in order to make it V3 API compliant. For the moment, it's stable.

If you would like to test it, feel free. If it's stable for you, I am fine with a link on the Domoticz Plugins Site .

Nevertheless, without the work of Xofor and yourself, I would have taken far more time.

https://github.com/janreimen/Domoticz-OpenAQ-Plugin

[JayDotR]

OpenAQ plugin for Domoticz: version 4.1 released, 4.2 (several stations) coming

The OpenAQ plugin reads air-quality data (BC, CO, NO2, O3, PM10, PM2.5, SO2) from the OpenAQ API v3 and shows it in Domoticz as devices, plus an Air Quality Index and a pollutant alert. It needs a free OpenAQ API key.

GitHub: https://github.com/janreimen/Domoticz-OpenAQ-Plugin
Thanks to Xorfor and waltervl for the original plugin and its evolution.

Version 4.1 (robustness and secret handling)
Upgrading from 4.0 needs no action: the devices keep their numbers and history.

• The API key field is now masked in the hardware form.
• The API key and your Domoticz location are never written to the log any more, not even with Debug on. Versions up to 4.0 did write them to the Debug log. If you ever posted a log from 4.0 or earlier, please rotate your key.
• After a failed start the plugin stays idle instead of throwing errors on every heartbeat.
• Your Domoticz location is only read, and only has to be valid, when the plugin looks for a station automatically. If you enter a Location ID it is not used at all.
• The radius is checked: decimals are accepted, the maximum is the 25 km that OpenAQ allows, and the log says which value was used.
• The automatic lookup no longer claims to find the "nearest" station, because OpenAQ does not guarantee an ordering. It now tells you which Location ID to enter to keep the choice.
• The repository now has a README, DEPLOY guide, SECURITY, CONTRIBUTING, CHANGELOG, ROADMAP, issue and pull-request templates, and an automated test suite (no Domoticz or network needed).

Planned for version 4.2: several stations in one hardware instance
4.2 is finished and in testing; it will be released afterwards. The code is on the development branch on GitHub.

• OpenAQ Location IDs: a comma-separated list such as 9645,1140 (up to 20 stations). Leave it blank to auto-detect.
• Max auto-detected stations (new, default 3): how many nearby stations are used when the list is blank.
• Ten devices per station. The first station keeps the current device numbers, so an upgrade needs no re-creating. With several stations the device names include the station, for example PM2.5 (Beidweiler).
• Each station is tied to its own devices, so reordering or removing IDs can never put one station's readings on another's devices. A removed station keeps its history.
• Auto-detect ranks stations by distance itself, keeps stations that already have devices, and logs the IDs to copy into the field.
• If one station cannot be set up, the others still run, and the log says which one failed.
• Upgrading from 4.1 or 4.0 needs no action. An existing single Location ID keeps working as before, and an existing auto-detect setup keeps its one station until you change the number.

Support policy
4.2 and 4.1 are supported. Support for versions before 4.2 will end in a future release, so please plan to update.

Feedback welcome
I would especially like to hear from people who use stations in other countries: which pollutants and units they report, and whether anything looks wrong. Please remove your API key and home coordinates from any log before posting it.

Install or update:

Code: Select all

cd domoticz/plugins/Domoticz-OpenAQ-Plugin
git fetch --tags
git checkout 4.1
# then restart Domoticz

[ClimateBlender]

For the international-station feedback, a useful test case would be a gas sensor reporting in ppm or ppb. Your README already notes that the current limits are in µg/m³ and that no unit conversion is applied.

Would it make sense to mark the AQI/alert as unavailable for unsupported units, while still showing the raw reading and its unit? That would avoid a plausible-looking alert level based on incomparable units.

This is a documentation-based suggestion; I haven't run the plugin.