The team behind the open source Airgradient AQ monitor are looking to develop the code needed to contribute Airgradient data to the sensor.community map.
Please can anyone provide a technical contact and or relevant documentation?
Thank you.
1 Like
Please read here:
You will have to register the sensors as PMS5003.
You must send data to:
- madavi API
- sensor.community API
You also have to register the sensors at devices.sensor.community.
For the API:
SC
https://api.sensor.community/v1/push-sensor-data/
Header
Content-Type: application/json
X-Pin: 1
X-Sensor: esp8266-12345678
Data
{
"software_version": "your_version",
"sensordatavalues":[
{"value_type":"P0","value":"66.04"},
{"value_type":"P1","value":"66.04"},
{"value_type":"P2","value":"53.32"}
]
}
Madavi
https://api-rrd.madavi.de/data.php
Header
Content-Type: application/json
X-Pin: 1
X-Sensor: esp8266-12345678
Data
{
"software_version": "your_version",
"sensordatavalues":[
{"value_type":"PMS_P0","value":"66.04"},
{"value_type":"PMS_P1","value":"66.04"},
{"value_type":"PMS_P2","value":"53.32"}
]
}
Thank you Pierre-Jean Guéno. That is so helpful.
Is it really required to also send to madavi?
No, it’s not required to send to the madavi API.
1 Like
Achim Founder of AirGradient here.
We do have an endpoint with all our public monitors. I wonder if it wouldn’t be easier if sensor community pulls all our public stations from this endpoint instead of us pushing them seperately?
https://api.airgradient.com/public/docs/api/v1/#/default/getCurrentMeasuresOfWorld
We use the same approach with OpenAQ and some other 3rd parties.
@pjg Would that be something you would consider implementing on your side?
We have thought about something like that together with OpenSenseMap.
This pulling may result in many duplicates. In our project people can send data with nearly every system (esp8266, esp32, raspi, via TTN, …). How should we detect if a system is sending to one or to many communities? And people should have the possibility to decide to which communities they are contributing. There is also the question of different licenses, we would need to check every project for the actual license if it’s compatible with our. What if this is changing? What happens if you decide to sell the AirGradient data in the near/far future?
There are so many things you need to think about, what we can’t achive as a volunteered project with limited resources.
1 Like
We have already integrations with OpenAQ and IQAir to share data with them. The way it works is that a user can opt-in to 3rd party data platforms they want to share their monitor data with.
In our UI it looks like this:
So we could add sensor.community there as an additional opt-in.
Then we can provide you with a dedicated end point to pull only the data in with monitors that people have opted to share with sensor.community.
This way, people have full control with whom they share the data and the duplications can be avoided.
On your website you mention “contributors driven global sensor network”. We do have a large footprint in North America and parts of Asia, so I think it would be a great addition to your network.
Also, our terms and conditions, I believe shouldn’t pose a problem regarding data licensing.
We are fully committed in sharing air quality data with as many other networks as possible and regard it as a public good.
Personally, I have always admired the work of sensor community and I believe it would be great if we can make a systematic integration.
1 Like
@ricki-z @pjg
It would be great if you could get back to me on this or connect me with a core developer to discuss this further.
Wouldn’t it be great to join forces to support open data across networks that share the same intention?
@Achim_Haug You are writing with the core developers of the project.
And again we are a volunteered project. Most of us have full time jobs and are working on this project in their spare time. So we may need time to think about something like your idea (But as mentioned I don’t really see this integration, just read my last answers).
@ricki-z Would you be open to a push request if we implement this on your code base?
I am asking in advance because I want to avoid that we put in the resources and then it’s getting rejected.
Please let me know, Thanks,
There are different part of our project published at github. To which do you want to push?
I had a look at Open Data Stuttgart · GitHub but it’s not really clear to me where you do the data ingestion.
Could you point us to the right repository?
The code of our map: https://github.com/opendata-stuttgart/feinstaub-map-v2
The code of our firmware (changes should be pushed to the beta branch): sensors-software/airrohr-firmware at master · opendata-stuttgart/sensors-software · GitHub
Documentation, how to send data to our API: APIs · opendata-stuttgart/meta Wiki · GitHub
Changes to our firmware, that include sending data to a special platform, will not have a chance of getting included. We can’t change our firmware that fast so that we can react to changes in these projects. Sensor won’t be able to send to these platforms for month …
For this people can use the “Send to own API” function, which may be only a mapping script to send the data to other platforms (that can do this job also for more than one user).
@ricki-z I agree that an implementation in the firmware does not make much sense. I think the best integration would be on your backend where you receive the sensor data and run your database. Is that code also open source?
@Achim_Haug the source code of our backend is open source, you can find it at https://github.com/opendata-stuttgart/feinstaub-api.
But I think what you are looking for is done in the local config of the instance (sensor types, system/chip names, allowed value types). To add some of these please send me a DM with those informations.
If you are looking for how to send data to the API then take a look at the documentation I’ve mentioned in one of my answers.