question

It might be that VenusOS thinks it is a device it should be concerned about and therefore has it open meaning that SignalK cant use it.

A search of the web for information about serial-starter and VenusOS will give you some pointers as to how to get serial-starter to ignore the device and allow SignalK to access it.

I might in a few weeks time when on my boat be able to try plugging one into my VenusOS install and see what happens. Will be able to give you more information then.

Afaik NGT-1 is not a common usb-can device , and will not show up as socketcan and will thus not work.

You’ll be saving yourself a lot of time by going for a can-hat for the pi. Or soms other something that ends up being socketcan

I have made a start on this. Looking at the VenusOS file start-signalk.sh, VenusOS appears to start SignalK as the current user:

exec /usr/lib/node_modules/signalk-server/bin/signalk-server -c /data/conf/signalk

This suggests the error is not a privilege issue?

The start-signalk.sh script also defines a "before opening serial port" command used by SignalK:

export PRESERIALCOMMAND="/opt/victronenergy/serial-starter/stop-tty.sh"

PRESERIALCOMMAND is used in SignalK's "serialport.js" where it "is invoked once per each configured serial port", passing the port name as an argument:

if (process.env.PRESERIALCOMMAND) {
child_process.execSync(
`${process.env.PRESERIALCOMMAND} ${shellescape(this.options.device)}`
)
}

VenusOS documents "stop-tty.sh" as "stopping the driver", and (presumably) closing the port.

Can anyone see anything wrong with this? Note that the Actisense NGT-1 port is "/dev/serial/by-id/usb-0403_NGT-1-A_1A4FA-if00-port0"; is this a valid argument to "stop-tty.sh"?

Knowing that SignalK attempts to close the port made me look further. I see now that in the file:

meta-victronenergy-master\meta-third-party\recipes-extended\signalk-server\signalk-server_1.40.0.bb

the SignalK start-up is defined as follows:

DAEMONTOOLS_SCRIPT = "${bindir}/prepare-signalk.sh && exec setuidgid signalk ${bindir}/start-signalk.sh"

As you suggested, @mvader (Victron Energy) , this will likely cause the same problems as a similar exec did for NodeRed. Changing this will hopefully fix the problem. Based on the commit at

https://github.com/victronenergy/meta-victronenergy/commit/f1c18713a44a9e1d849caca059575d6360aa3b3c

the change should be, I suggest, although I have no experience as a Linux programmer :-)

- DAEMONTOOLS_SCRIPT = "${bindir}/prepare-signalk.sh && exec setuidgid signalk ${bindir}/start-signalk.sh"
+ DAEMONTOOLS_SCRIPT = "${bindir}/prepare-signalk.sh && exec setpriv --init-groups --reuid signalk --regid signalk ${bindir}/start-signalk.sh"

Does this look right?

Andrew

Thanks, @mvader (Victron Energy) and @Bathnm for the good ideas.

I am not expecting the NGT-1 to provide NMEA-2000 data to VenusOS, but instead for VenusOS to leave the NGT-1 USB port available for Signal-K to then use. A standard Signal-K Raspberry Pi install (i.e. not using Signal-K within VenusOS) works fine with the NGT-1. There is good Actisense NGT-1 support in Signal-K because the NGT-1 was one of the first NMEA-2000-to-USB/Serial devices to be available.

To summarise the comments above, either :
(1) the Signal-K "user" under VenusOS may not have the correct permissions which will require (small) code changes to fix, or
(2) VenusOS is opening the NGT-1's USB port which, can be fixed using "serial-starter".
I will dig into this further when next on-board. (I am assuming that if VenusOS is opening the NGT-1 port, then the best fix is for me to discover an NGT-1 device ID and then add an appropriate line to /etc/udev/rules.d/serial-starter.rules )

@mvader (Victron Energy) I am not quite sure what you mean by "On the opposiite: in signalk the NGT-1 should work.", but just to be clear, the NGT-1 does work under a standard Signal-K install, but does not work with Signal-K as part of VenusOS.

Thanks, again, for all the help and suggestions.

PS: I note that my NGT-1 is the USB model, whereas @Jwfrary 's seems to be a serial model. I assume that a "serial-starter.rules" change will work for USB ports, but won't work for generic serial ports?

Success!

I have now tested this on my Raspberry Pi 4 running Venus OS Large v2.90~12. Specifically, in the two files:

/service/signalk-server/run
/opt/victronenergy/service/signalk-server/run

I replaced the last line, which read:

/usr/bin/prepare-signalk.sh && exec setuidgid signalk /usr/bin/start-signalk.sh

with

/usr/bin/prepare-signalk.sh && exec setpriv --init-groups --reuid signalk --regid signalk /usr/bin/start-signalk.sh

I then added my NGT1 in SignalK as a Data Connection, re-booted, and it seemed to work. Specifically, SignalK showed my NGT1 as being connected to the NGT1 port instead of showing the "permission denied" error message I received before.

I do not have anything connected to my NGT-1, so I have not yet confirmed that it is actually receiving NMEA 2000 data, but at least the obvious error has been resolved.I will test this further when next aboard the boat.

It would be great if this change could be considered for the next 2.90~XX release.

Thanks, @mvader (Victron Energy), for pointing me at the commit I could copy from: https://github.com/victronenergy/meta-victronenergy/commit/f1c18713a44a9e1d849caca059575d6360aa3b3c