Add toggle button for sensors in dashboard

[oscgonfer]

Feature expected

To be able to toggle metrics based on their meaning, for now we suggest to include a raw metric coming directly from the sensor, such as voltage or amps only when the toggle button is active. If not, then we hide them and show the meaningful metrics such as pollutant concentration derived from the raw metrics.

Example as @pral2a suggested:

Currently

All metrics are shown. For kit_id as 33 (Station rev 3.0) we have more than 30 metrics that do not make sense to overpopulate the dashboard.

Open questions

1. If we want to include more options for filtering out different categories already:
   • gas, pm, environmental
   • experimental
2. How do metrics that are relevant in one device can be considered not such in another. For instance, many stations have the potential of having a GPS inside for keeping a better RTC when not connected to the network. In this case, the GPS is a secondary metric, whereas on the dynamic sensors (i.e. sensors on a bike), is a primary one.

Solved issues

As @pral2a pointed out:

1. Sensor tags are already implemented in the API. their creation or update is accessed via the Rails console.
2. Tags are strings
3. A sensor has multiple tags
4. Sensors Tags are already a property part of the Sensors i.e. https://api.smartcitizen.me/v0/sensors/125

[oscgonfer]

Regarding this topic, I gave a thought on how to implement this, and I think we should use NILU's data levels convention for the tags. All the description is found here, but the gist is:

• Sensor readings are organised by levels
• Levels are only related to how much postprocessing is applied from the "manufacturer side" (i.e in a Smart Citizen Sensor, ourselves)
• Levels are defined by numbers from 0 to 4

If we apply this to all our sensors, then we can use this toggle button in the front-end to hide readings that have level 0. These would be for instance low-level voltage readings in sensors (i.e. raw), or amperometric readings. All the rest of our sensor readings are either level 1 or 2. An example can be found here in the connector I implemented to forward data to their platform.

If you agree, I can work on adding sensor_tags as such to the sensors with some guidance or support by @viktorsmari on how to do it fast:

• data_level_0
• data_level_1
• ...

However, I don't think this is as clean as it could be, since each sensor could only have one data level. So probably, a data_level table makes more sense. I leave this point open for discussion regarding available time and effort.

In either case, this toggle button feature would just need to filter out sensors containing data_level_0 as a first implementation. It also sets the grounds for a future improvement in which we could visualize data in spatio-temporal aggregations (level 4) which currently are not supported, by maybe in the future could be thought of "virtual" sensors generated by scdata periodically from various sources, including our networks of low-cost sensors.

[oscgonfer]

Any further ideas? @pral2a ? @viktorsmari ?

[pral2a]

My idea is to keep the taxonomy as open as possible. Primarily because that is associated with a sensor, not to a sensor instance on a device, and I know for some complex use cases linked with data post-processing we might need it the other way.

My opinion and the original approach is to use them primarily to improve the presentation in the generic front-end.

For that reason, I suggest using simple keywords that range from raw (some post-processing might be needed) to topics (air, water, soil, noise, indoor) or warnings (experimental, DIY) Tag filter will be hardcoded in the front-end to perform simple operations such as, hide from non experienced users raw sensor data, to group sensors in different ways (see img) to simplify understanding (see image), in particular with sensors containing a lot of metrics.

For that reason I will start with one tag only called raw in backend and we'll implement the filter in front-end with the button as in the original issue.