You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a fetcher pulls data in from a source it will typically have a source site identifier as well as an identifier for the parameter (and units). This parameter value is then mapped to a name that corresponds with the name used in the openaq database.
Different fetchers are handling this differently. Purple air is using the source parameter identifier in the final sensor source id name that is sent to the server while the clarity fetcher is using the openaq name, but without the units.
Example source_id for sensor: PurpleAir-35053-10.0_um_count
When a fetcher pulls data in from a source it will typically have a source site identifier as well as an identifier for the parameter (and units). This parameter value is then mapped to a name that corresponds with the name used in the openaq database.
Different fetchers are handling this differently. Purple air is using the source parameter identifier in the final sensor source id name that is sent to the server while the clarity fetcher is using the openaq name, but without the units.
Example source_id for sensor: PurpleAir-35053-10.0_um_count
And in clarity we are using the first entry in the value
Source id for sensor: AX5CC5K1-pm10
One of the issues that this creates is that we cannot create a new node/system/sensor directly from the measurements file
The text was updated successfully, but these errors were encountered: