Sensors, subscriptions and metadata

[tkurki]

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.

[tkurki]

See also

• 454 meta deltas

• 206 ad hoc data model extensions

[seandepagnier]

Has any progress been made here? This is really essential to minimize bandwidth and cpu consumption. It also allows linking several signalk servers.

I believe the best way is the relayed subscriptions.