Thanks for the pointers.
It is definitely more complex but also more flexible than what pypilot currently is using. It really isn't that far off and would be exciting to make fully compatible.
I think the starting point for pypilot output would be the "subtree" with updates because at least for now, the intention is not to relay signalk data. It might convert a few things from nmea but that is all, the rest of the data will originate from pypilot itself.
Obviously the initial message should contain meta data (it does already in pypilot) to describe the unit type and some other information.
What is a little bit different currently in pypilot is that the "source" for gps, wind and other data is actually a data field of its own that can be subscribed to. This is really useful to for display, and also the watchdog plugin of opencpn can subscribe to the wind.source without caring about the wind data itself and so this data isn't sent, but it wants to sound an alarm if the sensor is lost and the source becomes "none" This is also used by nmea parsing which happens in a separate process (because pypilot uses realtime processes for critical control loops) and it can know not to bother sending the data if it received nmea from a lower priority source than what is already being used.
I don't think this is a problem for signalk and should probably be a feature of pypilot, so it doesn't need to affect the standard or anything like that. It is a different field in the sense that it is the source the autopilot is actually going to use which may be different from other data passing through.
I am wondering, if the $source field is omitted, would the client just assume the source is whoever they connected to, or is it whatever the last value for $source was set to?
Code:
{"wind":
{"speedApparent":
{"meta": {"units":"m/s","description":"Apparent wind speed"},
"value":8.498624375207065,
"$source":"nmeaFromFile.II",
"timestamp":"2020-01-27T00:13:23.047Z",
"sentence":"MWV"}
}
}
Would this then update with?
Code:
{"updates": {"$source": "nmeaFromFile.II", "values": [{"path": "wind.speedApparent", "value": "3.14159"}]}}
Could it just be instead:
Code:
{"wind.speedApparent": {"value":8.498624375207065, "timestamp":"2020-01-27T00:13:23.047Z"}}
This is really just the subtree format with fields omitted which is incidentally the exact format pypilot already uses
I am trying to understand the logic of "updates" is it to share fields like $source and timestamp such as:
Code:
{"updates": {"$source": "nmeaFromFile.II", "timestamp":"2020-01-27T00:13:23.047Z", "values": [{"path": "wind.speedApparent", "value": 3.14159},{"path": "wind.directionApparent", "value": 123}]}}
Is this correct? and if so, what about instead:
Code:
{"wind": {"$source": "nmeaFromFile.II", "timestamp":"2020-01-27T00:13:23.047Z", "speedApparent": {"value": 8.498}, "directionApparent": {"value": 123}}}
This seems more intuitive to me, and does away with the extra rules needed for "updates" and "values" since everything is supported as the standard format with fields omitted.
It could even possibly be simplified to:
Code:
{"wind": {"$source": "nmeaFromFile.II", "timestamp":"2020-01-27T00:13:23.047Z", "speedApparent": 8.498, "directionApparent": 123}}
But this means that if there is one field rather than the dictionary it is assumed to be "value" and this adds an extra rule which is maybe not better or maybe ok?
To share source from fields that do not share other fields:
Code:
{"$source": "nmeaFromFile.II", "wind.speedApparent": {"value": 8.498, "timestamp":"2020-01-27T00:13:23.047Z"}, "navigation.speedThroughWater": {"value": 3.53, "timestamp":"2020-01-27T00:24:09.421Z"}}}
I would like to open the discussion to everyone's input. My intention is to keep the format intuitive, have as few "rules" as possible making it much easier to implement software, but also keep the actual data transmitted minimal (avoid redundancy)
Just because a previous format was already used, or some device exists using it is not really a good enough reason to keep it in my opinion. The standard can remain dynamic. I am sure I am overlooking some important factors which need to be taken into consideration.