Sensors, subscriptions and metadata #587
Description
Most if not all sensors currently work in passive mode: they connect to the server over ws and push data as delta messages. The server is totally passive and just accepts the data. Working like this any tweaks to the sensors update rate are done out of band: recompiling, altering settings or in the most flexible case using a web UI.
Motivation for altering a sensor's data production data includes at least
- bandwidth and storage savings: high rate when something interesting like testing or racing is happening
- power saving: with low data rate a sensor can sleep between measurements
We do have the subscription mechanism that we could leverage:
- upon connection a sensor/data source could send an advertisement: metadata about what it can produce, rates and metadata (name, unit, description) for non standard paths and it's default behavior
- the sensor could start with default settings
- the server could alter the data production by issuing regular subscriptions
- relayed subscriptions: if a UI, db or an analysis engine client subscribes to the data on the server the server could relay those subscription on to all the sensors that are producing the relevant paths
This would result in a flexible mechanism to alter the data production at the source from downstream. Metadata (meta deltas) would allow sensors to contribute to the server's metadata model and allow ad hoc extensions.