Make connected Signal K servers appear on OpenCPN

[cybardev]

May be an extension of #64

I have the following systems running Signal K server:

• Pi Zero W + GPS
• Pi 3B+ + GPS + AIS

The Pi 3B+ runs OpenCPN which shows self and other AIS targets. However, since the Pi 0W doesn't have an AIS unit, it doesn't appear on the 3B+'s OpenCPN map. I would like to make it appear there. This needs to be replicable, since there may be more Pi 0W units with GPS only in the future that need to be shown on the OpenCPN map.

I was considering these potential solutions:

• inject template AIS data with GPS coordinates on the Pi 0W's Signal K server
• inject template AIS data with the Pi 0W's GPS coordinates on the Pi 3B+'s Signal K server
• do something in OpenCPN, although I'm not sure what

If nothing else works, an alternative would be to show the AIS targets on a World Map node in Node-RED, but I'm not sure how to get the different vessel data, since the context field can't be set to vessels it seems.

Any way to show connected Signal K server nodes (without AIS, only GPS) on an OpenCPN map connected to a central Signal K server (with AIS, and GPS)?

Any suggestions or pointers would be greatly appreciated. Thanks.

[tkurki]

What do you mean by ”connected” - what are the Pi 0Ws connected to? Are they on separate vessels?

[tkurki]

Sorry, dropped the ball here. Did you get this sorted out?

Afaik OpenCPN can receive data for multiple vessels in Signal K format. So by establishing a Signal K connection between Pi 0W and Pi 3B+ so that all data is in Signal K in Pi 3B+ and OpenCPN is connected to it with a Signal K connection the Zero should appear in O.

Trouble is that we only support connections out of the box that allow a Signal K server to initiate a connection to another SK Server and receive data. In your scenario you'd probably want the Zero and other vessels to connect to the 3b+ and send data. This would be pretty easy to implement and an interesting use case. If you're still active with this let me know.

[cybardev]

@tkurki Hi, sorry for the late response as well; didn't check work stuff over weekend.

I am still concerned with this but it hasn't been an urgent issue for the last few weeks. There's been some changes and now we are doing this:

• Everything is a Pi 4 - the central Hub, and each Module
• Modules and Hub each run HTTPS Signal K on OpenPlotter
• Modules are GPS only; Hub is GPS + AIS
• Modules are added as Signal K data inputs on the Hub's Signal K server
• Modules send uniform data in this format, where much of it is metadata, and data is the unique information each module sends to the Hub for dashboard display and logging:

{
  "path": f"modules.{id}",
  "value": {
    "timestamp": timestamp(),
    "position": self.get_value("navigation.position.value"),
    "type": module_type,
    "data": data,
},

With this setup, the modules will appear as vessels in the Hub's full data model, but since each of them won't have AIS HATs, I don't think they'll appear on OpenCPN unless I inject some data to their own models. Any suggestions on what that might be?

[tkurki]

You only shared a part of your delta message. What do you use for context?

You are misusing the SK data model here. path is for identifying what the value is - for example navigation.speedOverGround. It must be the same for all vessels. The specification defines some of them and provides metadata (unit, description, data type) for them, but you can extend the data model.

What goes in your data payload? If there's stuff that the SK spec already defines, like navigation.position`, you must use the SK path for any existing SK or SK integrated software to work.

The vessel (why do you call them modules, not vessels?) is identified by context in the delta message. Again you must use this mechanism if you expect any connected software to use your data correctly.

So the way this is supposed to work is that

• vessels have each their own id and use that as ´context` in the data that they produce
• hub gathers this data and passes it on to OpenCPN
• OpenCPN uses context to identify vessels in its SK data input and renders the other vessels like it does AIS targets
• OpenCPN uses SK paths, like navigation.position to "understand" the incoming SK data and use it correctly

The vessels having an AIS hat has absolutely nothing to do with OpenCPN rendering the data correctly or not. Think about how AIS works:

• a vessels gets its position from GPS
• it transmits that position over VHF
• an AIS receiver receives data for all vessels and passes it on to OpenCPN
• OpenCPN renders other vessels' positions on the screen

Now in your scenario the same thing would work like so

• a vessel gets its position from GPS
• it transmits that position over SK to the hub
• the hub passes the data from all vessels to OpenCPN
• OpenCPN renders other vessels' positions on the screen

[cybardev]

@tkurki Sorry for the delayed response again. I'm back to working on this again fully now.

Here's some more info about how I'm handling things:

def module_event(self, id: str, module_type: str, data: str) -> None:
    self.update(
        [
            {
                "path": f"modules.{id}",
                "value": {
                    "timestamp": timestamp(),
                    "position": self.get_value("navigation.position.value"),
                    "type": module_type,
                    "data": data,
                },
            }
        ]
    )

def update(self, values: list[dict]) -> None:
    self.__socket.sendto(
        bytes(
            '{"updates":[{"values":'
            + json_utils.minify(json_utils.stringify(values))
            + "}]}",
            "utf-8",
        ),
        ("localhost", 8375),
    )

---

What goes in your data payload?

Something like this (converted to UTF-8 str):

{
    "filename": "test.wav",
    "status": "playing audio in ~5 seconds...",
}

---

why do you call them modules, not vessels?

Since 1 boat may have >= 1 modules. I don't really like saying vessel to mean 1 Pi board, when an actual vessel can contain more than one vessel (Pi). It feels confusing.

So for me, module = Pi board, vessel = boat OR hub Pi (cuz 1 per boat).

---

Now in your scenario the same thing would work like so

• a vessel gets its position from GPS
• it transmits that position over SK to the hub
• the hub passes the data from all vessels to OpenCPN
• OpenCPN renders other vessels' positions on the screen

Ok. But that doesn't happen naturally. Is there additional setup?

• The Signal K dashboard on the hub Pi shows the "Audio Out" module/vessel's data as a context.
• It shows correct navigation.position etc. data for the module.
• OpenCPN shows the hub as the main blip and all external AIS targets as vessels.
• OpenCPN doesn't show the "Audio Out" module/vessel on map as a blip or vessel despite all the data being available on the Signal K dashboard.

One reason I suspect this is happening is cuz I'm using HTTPS. OpenCPN doesn't play well with Signal K HTTPS, so instead of adding it as a Signal K connection, I'm having to add it as a TCP 10110 connection in OpenCPN. I'm assuming data from Signal K "vessels" that show up on the Signal K dashboard may not be transmitted over TCP 10110 or something?

In that case we either have to disable HTTPS and use HTTP, or we have to wait until OpenCPN finishes changing to a better websocket client (OpenCPN/OpenCPN#3207).

[cybardev]

Just tried using Signal K over HTTP and added the Hub server to OpenCPN as a Signal K data connection, but that alone makes the AIS targets disappear. AIS targets are only shown when using the TCP 10110 connection. The Projector module/vessel does not show up on OpenCPN in any way still.