search

tkurki / signalk-mqtt-gw

Signal K server plugin that provides gateway functionality between Signal K and MQTT
Apache License 2.0
14 stars 7 forks source link

Disambiguating data with multiple sources #46

Open tkeffer opened 2 weeks ago

tkeffer commented 2 weeks ago

I am in a situation where I have several devices providing numbers for the same data. For example, GPS position can be provided by 2 devices (ZG-100 GPS, VisionMate AIS). I only trust the data from the ZG-100, so I'd like to select it, and only it, to be published to the MQTT broker. Is there a notation to do this?

I tried working with the sample N2K data. The source for GPS position is listed as n2k-sample-data.160, so I naively tried subscribing to navigation.position[n2k-sample-data.160]. Nothing at all is published.

Am I missing something? Or, is this not possible?

tkurki commented 2 weeks ago

Not currently possible by path, but this is definitely something that should be added.

Meanwhile you can use server's source priorities to block the less reliable sources so that if the best source is active data from the others is discarded. May not be what you want, just noting that option in case you were not aware.

tkeffer commented 2 weeks ago

Good idea. That would definitely help.

tkeffer commented 2 weeks ago

Good that you decided to keep this open. I assume that means it's on the "wish list"!

Along the same line: while the plugin allows the user to specify which SignalK paths are to be published, they are all published to topic signalk/delta. This pushes the responsibility for disambiguating vessel sources to the subscribing clients. They have to listen to everything, even vessels that they are not interested in.

Suggestion: publish to signalk/{vessel}/delta where {vessel} is the MMSI or UID of the SignalK server. Or, even better, publish to path-specific topics, such as signalk/{vessel}/delta/navigation.position. Then the client can target exactly what it needs.

tkurki commented 2 weeks ago

Separate issue, please create a separate issue..

tkurki commented 2 weeks ago

Was on phone earlier - yes, I want to keep this open, on the backlog/wish list.

One way to achieve by path and optional by source subscription would be NOT to map value paths to hierarchical MQTT topics but simply two levels: per the previous example: vessels/<id>/navigation.position/n2k-sample-data.160. This would allow subsciptions to

  1. all values for a path for a vessel, from any source with vessels/<id>/navigation.position/+
  2. all values for a path for any vessel, from any source with vessels/+/navigation.position/+
  3. all values from a source on a vessel: vessels/<id>/+/n2k-sample-data.160 but not allow hierarchical subscriptions, like all navigation values for vessel x.

We could also do a hybrid: first 2 value path levels as hierarchy, like vessels/<id>/batteries/1/capacity.remaining/sourceId. This would allow subscribing to all values for a devicewhere the id is in the path, like a battery. Not very intuitive though.