Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disambiguating data with multiple sources #46

Open
tkeffer opened this issue Aug 26, 2024 · 5 comments
Open

Disambiguating data with multiple sources #46

tkeffer opened this issue Aug 26, 2024 · 5 comments

Comments

@tkeffer
Copy link

tkeffer commented Aug 26, 2024

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
Copy link
Owner

tkurki commented Aug 27, 2024

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
Copy link
Author

tkeffer commented Aug 27, 2024

Good idea. That would definitely help.

@tkeffer tkeffer closed this as completed Aug 27, 2024
@tkurki tkurki reopened this Aug 27, 2024
@tkeffer
Copy link
Author

tkeffer commented Aug 27, 2024

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
Copy link
Owner

tkurki commented Aug 27, 2024

Separate issue, please create a separate issue..

@tkurki
Copy link
Owner

tkurki commented Aug 27, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants