Understanding correct paths /vessels/<RegExp>/propulsion/<RegExp>/revolutions
Am I understanding the specification correctly in that the correct way to specify the SignalK path for revolutions on a vessel with a single engine is for example:
/vessels/main/propulsion/main/revolutions
I am not sure I understand the purpose of the second <RegExp>
20 Replies
that is correct. the second RexExp is a placeholder for your propulsion unit id here
Thankyou - it's pretty obvious now
π©
/vessels/mmsi/propulsion/engineId/revolutions
By the way: And who assigns that unit id?
In practise n2k networks use their own scheme that maps to sk. Or you can just do it yourself
At start SIgnalK server and plugins no "propulsion" path present. So, you need to complicate either the client or the server plugin part for access to "propulsion/<RegExp>".
Standard identifiers instead <RegExp> would simplify everything.
sorry, don't understand. are you talking about something that produces or consumes propulsion data?
Consumes.
I want to subscribe to the state of the engine in my app. How does the app know the path?
Http request to https://demo.signalk.io/signalk/v1/vessels/self/propulsion/ (well, demo data does not have propulsion)
Your app should consider supporting multiple engines anyway
For plugin with getSelfPath
The data not being there on startup is a bit different issue. You can an initial state
null to the engine state in baseDeltas.json. We could also add persisyimg state over restarts to the server, but that would need to include a mechanism for removing paths that are no longer relevant somehow, that complicates thingsHttp request to https://demo.signalk.io/signalk/v1/vessels/self/propulsion/I mean, the idea is that should only subscribe to "propulsion/", not "propulsion/<RegExp>/"?
The data not being there on startup is a bit different issue.Not a problem if I know the way to subscribe. Subscribe and wait.
yes, subscribe for
propulsion/*This complicates everything for simple non-interactive applications for very weak devices. Engine revolutions indicator, for example. Must come up with its own crutches.
But since the SIgnalK data do not contain internationalization, data freshness info, user measurements, display accuracy info, etc. - crutches are still needed.
Well, signal k was not born perfect. There is certainly lots of room for improvement. We just need to work together to create solutions for the missing functionalities and use cases
i'll take one example: user measurements - i assume you meant the units that the user wants to use? Now InstrumentPanel has the ability to store the preferred units as they are called. Who could take this mechanism and make it universal? The server already supports global and user specific applicationData so this might not need anything but documentation. ping @Christian MOTELET
WebApps - Signal K Server Documentation
A Guide for users and developers.
i assume you meant the units that the user wants to use?Yes.
Who could take this mechanism and make it universal?"/propulsion/0/revolutions/ru/rpm" ? "revolutions" returns value in SI and meta in English, and "revolutions/ru/rpm" returns value in rpm and meta on Russian.
The server already supports global and user specific applicationData so this might not need anything but documentation.It's the same crutch. My crutch is simpler and more useful. My point is that SignalK must provide absolutely everything you need. In an ideal world, of course.
imho you are confusing the language and the unit. lots of finnish speaking people who like to see wind data in knots, but also in m/s - you can't derive units from language
using the http path for language is also a bad idea in the http api, http spec already has https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language
MDN Web Docs
Content-Language - HTTP | MDN
The Content-Language representation header is used to describe the language(s) intended for the audience, so users can differentiate it according to their own preferred language.
not sure about websocket, use either the same header or an explicit parameter. and what about tcp - a property in the subscribe message maybe?
imho you are confusing the language and the unit.I'm not confusing, I'm combine. The measurement unit has a name in the national language. And description must be in the national language too. Websocket begins from http request, so the server can recognise Accept-Language header. But the http headers is not a part of a REST API. I think it's wrong to return in response to "revolutions/rpm" the to the Finn, and the to the Russian.
I think the first one should be returned in response to "revolutions/fi/rpm", and the second is in response to "revolutions/ru/rpm". In addition, it is useful to allow the user to specify the language if, for example, they do not like the translation. Not everyone knows how to replace the Accept-Language header in the browser.
Ah.
units is a not a label meant for humans, it specifies what unit the data value is in. Machine readable, and sk data is using SI units almost everywhere
Preferred unit should also be machine readable so that the client can show the value in that unit
But we do need the label to draw on the screen for humans. And i think we need long and short labels like knots and kn and localised versions of them
Http headers are definitely part of HTTP apis. See for example https://swagger.io/docs/specification/2-0/describing-parameters/
It is the UI client that supports localisation that is doing the http request, not the end user
Trying to put everything (data item, language, unit) in the path is a bad idea, they must be explicitly separate, using headers or request parameters
Path specifies just the data item (sk path)Ah. units is a not a label meant for humansOk, I'm just for an example.
It is the UI client that supports localisation that is doing the http requestYes, that's what they usually do, and I'm doing it now. But I'm not sure that's right.