specification
specification copied to clipboard
SignalK
Standard API and client libraries
To make Signal K usage and adoption easier and promote similar behavior across clients we should have a standard api for acccessing Signal K data and metadata and communicating with servers.
@sailoog I understand you are using keyswithmetadata.json, which is not exactly standardised and just changed location with #368.
Could you please describe your use case? I would like to pin this down so that we can provide an api you can rely on.
@tkurki thanks for notifying.
Openplotter allows to use many types of sensors. Users must select the key where data from sensors will be stored. So, we need to build menus with all available keys to be selected, an example:
We parse keyswithmetadata.json, group keys by SK group and offer a selecting window with keys description. There are also other uses of Signal k key menus like trigger/actions system that need to use the same system. keyswithmetadata.json is doing the job but we could use also any "on the fly" method.
We need an json output with key name, description, unit, enum value. Any idea? Thanks.
What if we made the flat schema, essentially keyswithmetadata, part of the server api, retrievable from say /signalk/v1/schema/flat?
That would be great. Easier and more reliable than a file. Would it be possible to add enums? We would use them to set/select possible "states" of keys on trigger/actions system and could be useful for others too.
@sailoog Thinking about this and needing units in a webapp code I remembered earlier discussion about metadata/schema data retrieval via the current api. The schema for full model includes a meta element that has units, so let's make the server return relevant metadata for all paths, not just ones that the server happens to have data for: see https://github.com/SignalK/signalk-server-node/pull/294
@tkurki OK. So, do you think keyswithmetadata.json is still the best way of getting the complete list of supported keys?