Conversation
mweinelt
left a comment
mweinelt
left a comment
There was a problem hiding this comment.
I think PM1, PM2.5, PM4 and PM10 are a good sample to start with. Will try to implement these in our Space API shortly.
| "PM4.25": { | ||
| "description": "Concentration of particulate matter with a diameter of 4.25µm or less.", |
There was a problem hiding this comment.
| "PM4.25": { | |
| "description": "Concentration of particulate matter with a diameter of 4.25µm or less.", | |
| "PM4": { | |
| "description": "Concentration of particulate matter with a diameter of 4µm or less.", |
There was a problem hiding this comment.
I did some online research and found that "PM4.25" seems to be an industry standard. Are you sure "PM4" isn't just an abbreviation used by your sensor?
There was a problem hiding this comment.
The actual question would be if statically defined PM sizes are adequate.
There was a problem hiding this comment.
The actual question would be if statically defined PM sizes are adequate.
A "quick" solution I could think of that's both strict and allows different PM sizes would be the use of JSONSchema Pattern Properties.
However I've never used them and don't know how API clients deal with this. @SpaceApi/core can anyone of you provide input here?
Another approach would be to not use named properties, but a list of objects with the particle size as a separate property, e.g.:
"particulate_matter": [
{
"location": "Hackcenter",
"lastchange": 1756499104,
"properties": [
{
"measurement": "PM10",
"value": 20,
"unit": "µg/m³"
},
{
"measurement": "PM2.5",
"value": 25,
"unit": "µg/m³"
}
]
}
]Again, input from @SpaceApi/core is very welcome.
2 participants
This PR adds support for the
particulate_mattersensor type as proposed in #129.@mweinelt I would also ask you to provide feedback as well since you requested this feature in the first place.