question

@fguiot are you planning on keeping up with the beta releases as well, or only the main releases? There is no file set available for 3.20~30 so I went back to 3.12.

@derrick thomas I will install the beta on my dev Cerbo and will update the repo. Stay tuned..

3.13~1 is the latest one proposed by Venus GUI. I can't download the v 3.20~30 and test it, but I believe this should work as seems the mod files remained the same.

3.13~1 and3.20~30 are now supported. Please let me know if all good.

@fguiot I have to remove your added lines from serial starter rules or it knocks off my bms and my system goes into fault and disabled charging and discharging. Any chance on making that part of the setup to have it's own entry in setup helper? I use 3 dingtian relay boxes via tcpip over WiFi so I don't need the changes to serial starter rules, and my bms uses uart so the added lines interfere. It wouldn't bother me except that any time you push an update to your repository, or Venus os updates, then serial starter rules gets changed again.

Edit to add: Alternatively, I'm curious if it's possible for me to just remove remotergpio from setuphelper after installation without uninstalling it? I know I can disable automatic updates but I think that disables updates to all installed mods and I cannot select individual ones?

Maybe @Kevin Windrem has a suggestion?

It is not possible for PackageManager to be interactive or offer install options.

I have a few packages that require input from the person installing them and these must be installed from the command line. The selected options are then stored in the /data/setupOptions/<package name> directory. Future installs are then possible from PackageManager or reinstall after a Venus OS update. Changing the options requires running the script from the command line again.

Look at my RpiDisplaySetup package for an example of how to setup options.

From my perspective, it would seem that ethernet/WiFi would be a better default for the relay extension. You can use static IP addresses and run the relay expansion point-to-point with the GX device if you don't have a local network. Cerbo and some other GX devices also have a WiFi access point that could be used.

Hi all,

A bit newbie here.
I have installed the usb to modbus module on the Cerbo and the Dingtian relay module.
Used the install like described and all works but when I press a relay it takes about 5 seconds for the relay really switches.
Is this normal for modbus or not?

Also I read that some have made the relay module working on wifi or ethernet.
I have wired network al over the boat so what do I need to do to make this work?
Is it as simple as setting TCP client on the Dingtian module with the IP of the cerbo and turning Modbus/TCP on on the Cerbo?

Hope you can help me out here, thank you in advance.

Stefan

Hello, I have v2.3 downloaded and when i try to install I get "unknown error 255" and "incompatible ???". Tried re-booting and updating all other software packages.

Cerbo GX with OSLarge v3.14
GuiMods v9.2 and SetupHelperv6.3

Also not got far enough to try yet, can I use one of these MODBUS relay boards (Amazon MODBUS 16 channel relay board)
Anything funky to do differently?

Thank you!

Is there a possibilty to use the 16 relay variant of the Dingtian box?

You can buy it on Alibaba but not on Aliexpress.

https://www.alibaba.com/product-detail/Smart-Home-Digital-Input-CANbus-RS485_1600513863638.html?spm=a2700.shop_index.89.11.4fe7127aTnBjCr

Hello All,

I have manage to install the latest version of RemoteGPIO but when I am trying to use it from GUI interface of my Cerbo do not make anything.

I have try to run the troubleshooting steps and I have this outputs:

root@einstein:~# dbus -y com.victronenergy.system /Relay GetValue

{'0/State': 0,

'1/State': 0,

'2/State': 0,

'3/State': 0,

'4/State': 0,

'5/State': 0}

root@einstein:~# dbus -y com.victronenergy.system /Relay/3/State SetValue %1

0

it run, but relay is not closing

if I change the relay number whit on of the factory relarys (those who are inside of cerbo) it is working.

root@einstein:~# dbus -y com.victronenergy.system /Relay GetValue

{'0/State': 0,

'1/State': 0,

'2/State': 0,

'3/State': 1,

'4/State': 0,

'5/State': 0}

root@einstein:~# /data/rgpio/modpoll/arm-linux-gnueabihf/modpoll -m rtu -b 115200 -p none -d 8 -r 11 -s 1 -c 1 /dev/ttyUSB0

modpoll 3.10 - FieldTalk(tm) Modbus(R) Master Simulator

Copyright (c) 2002-2021 proconX Pty Ltd

Visit https://www.modbusdriver.com for Modbus libraries and tools.

Protocol configuration: Modbus RTU, FC3

Slave configuration...: address = 1, start reference = 11, count = 1

Communication.........: /dev/ttyUSB0, 115200, 8, 1, none, t/o 1.00 s, poll rate 1000 ms

Data type.............: 16-bit register, output (holding) register table

-- Polling slave... (Ctrl-C to stop)

[11]: 255

-- Polling slave... (Ctrl-C to stop)

[11]: 255

-- Polling slave... (Ctrl-C to stop)

[11]: 255

-- Polling slave... (Ctrl-C to stop)

[11]: 255

-- Polling slave... (Ctrl-C to stop)

[11]: 255

-- Polling slave... (Ctrl-C to stop)

[11]: 255

-- Polling slave... (Ctrl-C to stop)

when I am checking if relay is closing using this command:
/data/rgpio/modpoll/arm-linux-gnueabihf/modpoll -m rtu -b 115200 -p none -d 8 -1 -r 3 -s 1 -c 1 /dev/ttyUSB0 257

it is working, I can see the green light and also I can hear it closing.

this process are using my USB port:

root@einstein:~# ps | grep USB0

5432 root 1608 S supervise gps-dbus.ttyUSB0

5454 root 1620 S multilog t s25000 n4 /var/log/gps-dbus.ttyUSB0

12013 root 2688 S grep USB0

also I have try to trick the recommended file

#! /bin/sh

. $(dirname $0)/functions.sh

for tty; do

tty=$(basename $(realpath /dev/$(basename $tty)))

test -c "/dev/$tty" || continue

# hide tty from serial-starter

rm -f "/dev/serial-starter/$tty"

# stop any running services

svc -d /service/*."$tty"

# if lock_tty fails, serial-starter may be about to start the service

# delay and bring it down again until lock_tty succeeds

while ! lock_tty "$tty"; do

sleep 1

svc -d /service/*."$tty"

done

unlock_tty "$tty"

done

but I do not manage to understand what line I need to modify.

My usb to RS485 is connected in the second USB port of cerbo GX

Somebody who know better then me please help me to fix it.

BR.

Calin

@Calin, so if I understand correctly, theUSB communication is working fine.

For having it to work with the Venus GUI, you need to have Node-red installed. and you will see the first 4x external relays in addition to the 2x internal ones of the Cerbo GX. This is also requiring GuiMods from kwindrem.

Or you may wait a bit, I'm finalising the new version 3 that is 100% dbus native (no more Node-red) with improved GUI for supporting up to 18x relays (3x pages each with 6x relays).

I hope to release this soon.

@derrick thomas yes, definitively! The package to be released will initially supports 2x modules but I'm counting on you to update and contribute to the V3.0. ;-)

You will see, I have added few interesting mechanisms such as watchdog, driver running as a service, configuration from GUI, ...

At a second stage, I'm planning to also add also native Ethernet support and give the choice between USB and Ethernet.

I have forked a branch, called beta-3.0

the setup is still manual as I need now to redo the integration with PackageManager.

Unless I'm told this is a bad idea, I plan to support Venus OS 3.21 and onward....

Thanks, but today the issued the release v3.22 and now remoteGPIO 2.4.1 does't work to have te 4 relays more

You may find v3.21 in the stored firmware menu. If so, just select it and the system will reboot.

To avoid future updates to v3.22, disable automatic firmware updates BEFORE switching to v3.21.

Otherwise, you can download previous versions here:

http://updates.victronenergy.com/feeds/venus/

and put them on a USB stick. When you plug the USB stick into the GX device it will prompt for the install.

How do I get remote GPIO in I/O as below?

thanks

@sergio this screenshot is for the new coming v3 fo RemoteGPIO that will be natively integrated with D-Bus and Victron GUI. For now you have to stick with the setup guidelines at the beginning of the thread and it is requiring to runVenus_OS large with Node-Red enabled.

I followed the whole procedure and now I'm at this point, the relays don't activate and I have two errors on the node-red, see Read Relays and Write Relay.

on the RS485 a USB converter the red led is blinking, so maybe there is comunication between cerbo and relay board, but I'm not sure

but there is not a procedure much more easy to command these 4 relays more?

thanks a lot for help

@Sergio68 please check the following commands is ssh terminal:

Close Relay 1:

/data/rgpio/modpoll/arm-linux-gnueabihf/modpoll -m rtu -b 115200 -p none -d 8 -1 -r 3 -s 1 -c 1 /dev/ttyUSB0 257

Open Relay 1:

/data/rgpio/modpoll/arm-linux-gnueabihf/modpoll -m rtu -b 115200 -p none -d 8 -1 -r 3 -s 1 -c 1 /dev/ttyUSB0 256

With this we will know If the communication with the Digital relay module is broken. Then it will be more likely related with USB0 interface not been exclusive with RemoteGPIO. BTW, do you have other devices attached to USB ports? have you connected the Relay interface of the rely to the far external USB port of the Cerbo GX?

Thanks a lot for your help, my project is ongoing..now is time to "push" inside my boat

Looking forward to your v3 of your remoteGPIO. Keep up the great work! Glad you found a way to make it futureproof with the new GUI-integration. Your chosen relaysboard seems very powerful, but also on the hungry side, since it has a lot of components installed that one does not need. I am opting for this board:
https://www.ebay.de/itm/403876604917?

and the USB485-STIXL from https://hjelmslund.eu/ (Victron-supported + isolated - just had some bad experiences with a nonisolated BMS Can...)

Do you see any problems with this choice?

Will v3 also include Inputs? How can i make use of them?

Matthias

I'm releasing a first beta, currently v3.0.5

It requires GuiMods version 10.6 to be installed and Venus OS 3.22

If you want to test, you need to update the PackageManager with GitHub branch or tag = "beta-3.0" you can always return to "main" for the normal support through Node-Red.

It supports up to 2x Dingtian 8 relay modules. Control is configurable either via USB or Ethernet

Beta v3.0.14 is now supporting all the Digital_Inputs at D-Bus level! :-)

They are all listed in the main page. The last remaining limitation is the Digital Input Setting page that shows only the first nine. @Kevin Windrem any ideas why?

Easy fix seems to remove the line:

  
                  

                   
        filterRegExp: "/[1-9]$"
                  

I have implemented the change on RemoteGPIO side as I anyway have to add the sub-Menu for RemoteGPIO in this qml page.

Beta v3.0.15 just released.

All Digital Inputs and Relays are now managed vis D-Bus with no limitations on GUl nor access via Node-Red.

I'm now waiting for users feedback before releasing as main stream and ask Kevin Windrem to add RemoteGPIO to the repository list of PackageManager.

Next step will be to support the various sizes of these relay units

I propose here a solution to better handle USB to RS485 interface with RemoteGPIO, making sure there will be no more conflicts with other services requiring the same model of USB to RS485 adapter.

The solution I Propose is to purchase an adapter based on FTDI chipset, in particular FT232R based. These are still inexpensive and have the advantage to be reprogrammed on demand.

Follow this procedure:

1/ Download FT_Prog - EEPROM Programming Utility from https://ftdichip.com/utilities/

As of 7th March the version is 3.12.46.653

and install it on Windows (I tried Windows 7 successfully)

2/ Connect the USB to RS485 you wish to reprogram and select the driver you just downloaded

3/ Let Windows to search on internet the right driver

4/ Run FT_Prog

5/ Press F5 to scan the USB bus (go to menu DEVICES and select Scan and Parse

It should display a device in the Device Tree

6/ Select USB String Descriptors in the Device Tree and update the Product Description with « RemoteGPIO » (original value is « FT232R USB UART »

7/ Select Program in DEVICES menu

Hit Program button

8/ Hit F5 to scan again and confirm RemoteGPIO is now the correct Product Description in the USB String Descriptors

Then add the following lines at the beginning of /etc/udev/rules.d/serial-starter.rules :

# ** RemoteGPIO **
#Serial-starter to ignore the USB-RS485 (ID_MODEL=USB_Serial) so USB interface for RGPIO works
#ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="USB_Serial", ENV{VE_SERVICE}="ignore"
#Serial-starter to ignore the USB-RS485 converter attached to the first USB port so USB interface for RGPIO works
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_PATH_TAG}=="platform-1c14400_usb-usb-0_1_1_0", ENV{VE_SERVICE}="ignore"
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="RemoteGPIO", ENV{VE_SERVICE}="ignore"
# ** RemoteGPIO **

Finally reboot, and you are good to go.

I will add the new /etc/udev/rules.d/serial-starter.rules in the coming version 3.0 of RemoteGPIO that I'm very close to make public access.

Version 3.0 is released!

I update my Cerbo GX with v3.22 and RGpio 3.1, I can open the menu of the 10 added relays on my Cerbo inside the Relays menu, but there is no communication between Cerbo and the USB to RS 485 adapter, only sometimes there are some flashes on it (only one of the 2 led).

On menu I/O RemoteGpio is request to put the Unit 1 IP adress, wich adress I should put inside, see below?

also it will be possible to see thw config of all signals on Node-Red by Venus_OS as before I use it to make some logics between I/O signals DI/AI/DO.

thanks for help

v3.1.2 released and should fix the issue introduced in 3.1

Sorry have no time today to run deep tests, but initial tests shows it's working fine on my side

Version 3.1.6 just released. This is fixing the latency issue reported by some of you.

Now the additional relays are reacting as fast as the embedded ones in the Cerbo.

Hello and thank you for your great work.

I have installed RemoteGPIO v3.1.7 on RPI4 venusOS v3.3: all relays work fine, but none of the Digital Inputs configured as "pulsmeter" or as "Generic I/O" count the pulses of my dingtian 4 modules. Maybe I missed something!

Any idea?

Richard

I use Modbus via TCP protocol

This is when I jumped the GND to input_3

While your input 3 is jumped to GND, can you issue the following command:

cat /dev/gpio/digital_input_7/value

It should return a 0 if Input3 is grounded.

Also Careful, the first 4x Digital Inputs are the ones embedded in CerboGX, so DigitalInput1 of the Dingtian device is DigitalInput5 in Venus OS.

I've see that they issued rev. v3.30 for Cerbo GX, is the rev. 3.1.7 of remote GPIO compatibile or is better to wait to install v.3.30?

thanks

Playing around in the lab. Goal: get my DT-R008 connected over Ethernet vs my production via WaveShare Isolated, RS485 USB dongle.

Duplicating my production environment:

Pi 4B

WaveShare Dual Isolated CAN Hat.

Running 3.40~1 Large, None-Red: Disabled

Kevin's:

SetupHelper: v7.10

VeCanSetup: v3.12

ShutdownMonitor: v3.1

GuiMods: v10.17

Then TimD's: RpiTemperature: v1.2

All working like a champ, both can8 to a JK-PB series BMS, can9 to my to a SmartSolar MPPT VE.Can charge controller, then a SmartShunt via USB to VE.Direct dongle.

Now, when I try to getting my Digntian DT-R008 in the mix, things start to go sideways.

Installed @fguiot RemoteGPIO, Active packages show's "patch errors" under RemoteGPIO and obviously --, for installed version. Stored is v3.1.7.

/data/RemoteGPIO/patchErrors, has "patch unsuccesful for gpio_list" Typo "unsuccessful"

Haven't spent any time really digging in and see what's going on. Don't know if it's 3.40 code or what at this point.

Anyone have any idea's would be appreciated. But, I'll find it and keep you posted.

Cheers.

Working fine on my test system. It's a cerbo though not a RPi

Found the next line out output:

"ERROR: could not patch gpio_list - can't continue with install"

It's in /data/RemoteGPIO/HelperResources/CommonResources

1383 if ! patch "$patchedFiles/$baseName" "$patchFile" &> /dev/null ; then

1384 setInstallFailed $EXIT_FILE_SET_ERROR "ERROR: could not patch $baseName - can't continue with install"

1385 endScript

1386 fi

You guru's know this code like the back of your hands, what the heck is it not happy with?

All replacements backup an existing file (even an empty one) to .orig. If there is no existing file, a .NO_ORIG file is created instead.

On restore the .orig file is moved back into the active location. If there is no .orig but a .NO_ORIG exists, the active file is removed, leaving nothing in that file name, but that's the way the system was before the install.

Have just release version v3.1.8 (thx to @derrick thomas ) with support for rPI and ol d venus versions up to 2.92.

I'm away this week and have way to test it. Ping me if this is not working or breaking something

****** UPDATE Version 3.2 **********

Support for 2, 4, 8, and 16x relais modules.

Support up to 3x units.

Thanks to Thomas for adding the above

As we don't have all the units here to test, thanks in advance to report here your experience with the 16x relai version.

UPDATE Version 3.2.1 released

Removed option for 16x relay module. It will require different driver version

Added support for reading relays status and updating GUI. This option is set to default off in RemoteGPIO settings.

Thanks to @derrick thomas for his implication in the project!

Hi I have tried to install Remote GPIO

1. I added Remote GPIO in package manager from the inactive packages selection.

2. it has now been added to Active Packages however there seems to be some form of conflict with my 123SmartBMS-Venus package as per picture.

3. I have then tried to uninstalled the Remote GPIO but it seems to want to uninstall the 123smart package and not remote GPIO

Any suggestions ???

Good morning,
I proceeded with the "Blind" installation of "shetupHelper" as described in "setup", then in "inactive packages" I downloaded and installed "RemoteGPIO Lucifer06:main", but something went wrong as you can see in the photo.
I can't do anything at the moment, can someone please help?
thanks in advance

@fguiot

I know Fredrick has been globe hopping, but I've got Digital Input issue working on a RPi.

Running Venus 3.40~2

SetupHelper: v7.15

GuiMods: v10.20

ShutdownMonitor: v3.1

RemoteGPIO: v3.2.2

I'm a EE, that whores himself out to design whatever my clients need. Don't code for a living but I can make my way around. Saw what the issue was, and kludged it until the master makes it back home. Unless anyone wants to know, I won't even post how I fixed it. But certainly willing to do so. Love to be able to fix properly, but just don't possess the skills required.

Here's a pic of Active Packages

Here's a pic of the Digital inputs showing up in the console.

Now off to play with them, being so new to this I don't even know what they're capable of :)

Thanks for all the work here folks. It really opens up some exciting opportunities for those of us who are less programming savvy.

Can anyone provide guidance on the specific relay box required? Is the Dingtian the only option? For example, is this Waveshare Modbus RTU box compatible with RemoteGPIO? How would I confirm or test? https://www.waveshare.com/modbus-rtu-relay.htm

I'm not clear how much of the setup is expected to be "plug and play", vs. needing to be configured in a certain way.

One more question folks. I installed Remote GPIO 3.3.2 (nice integration with package manager!) and tested it with the Dingtian 8x relay box. All worked great. Installed it and went to test actual functionality, and discovered a strange and repeatable issue.

Whenever there is nothing connected to the relays, I can change their state on command through the remote console. They respond nearly instantly to a command, and continue to do so repeatedly and reliably. However, if I have wires connected to the common and N.O. ports of the relay and actually drive a load, I can only cycle the relay once. I command it closed (success), command it open (success), and then the relay module loses all communication. No relays will respond until I unplug the RS485 USB adapter and plug it back in. I am using the Dingtian module to drive standard 12V automotive relays so that I do not have any meaningful current flowing through the Dingtian relays. I have tested this with multiple relays on the Dingtian module and multiple "driven" relays.

Any thoughts as to what might be happening here? Is there a way to capture any logs that might be helpful? The issue was the same with version 3.2.2. Using a Cerbo GX-S.

Thanks!

One more question folks. I installed Remote GPIO 3.3.2 (nice integration with package manager!) and tested it with the Dingtian 8x relay box. All worked great. Installed it and went to test actual functionality, and discovered a strange and repeatable issue.

Whenever there is nothing connected to the relays, I can change their state on command through the remote console. They respond nearly instantly to a command, and continue to do so repeatedly and reliably. However, if I have wires connected to the common and N.O. ports of the relay and actually drive a load, I can only cycle the relay once. I command it closed (success), command it open (success), and then the relay module loses all communication. No relays will respond until I unplug the RS485 USB adapter and plug it back in. I am using the Dingtian module to drive standard 12V automotive relays so that I do not have any meaningful current flowing through the Dingtian relays. I have tested this with multiple relays on the Dingtian module and multiple "driven" relays.

Any thoughts as to what might be happening here? Is there a way to capture any logs that might be helpful? The issue was the same with version 3.2.2. Using a Cerbo GX-S.

Thanks!

Hello,

@fguiot Had this all set up for a few days, but getting limited reliable success.

I have used node-red for a while now with a successful setup for my excess solar going into a water heater; runs on PV yield, SoC, and time of day parameters also it has a 30 minute boost function so I am fairly confident with how that side of things works, looking into making and advanced dashboard 2.0 now.

For the below situations; I have disabled all my flows and have set a barebones setup downloaded from above, All packages are up to date as of today, and I have emptied all the log files because VRM was also complaining about being overloaded(new intermittent problem only in the last 24 hours).

I am experiencing 3 main problems;
Number 1, Randomly relay 2 (integrated in cerbo) will repeatedly turn itself off and on faster than any electronics person would like to see a relay going. I was scared it was going to be a soldering experience for my cerbo! This has happened at 2am and also right after uploading new flows.

Removing links in node red from the top of dashboard flow does solve this, So I have now changed them to only send updates on changes and things are more stable. Something to note I guess, Its inline with the following I think.

Number 2, all of the relays on the digitan board seem to be stuck in whatever random state they turn on in.

If I power cycle the board a few of them will change to closed status, and no matter what I do; On node-red dashboard or directly in the shell with dbus/ modbus commands will change them permanently. Sometimes from the dashboard or the relay network interface, relays 1-4 on the board can have their state jogged, but 5-8 never change.

Number 3, @derrick thomas (I think it's your beautiful work with GUI mods?) The relay control buttons on the touch screen only work for the onboard relays, not the digitan board. They successfully reflect the state of the relays but have no operation function, they don't even graphically respond to a touch.

I have included a few outputs from the shell below followed by some log entries.

I tried to close an open relay on the board first (relay 5) but as you can see from the status this didn't change.

Close Relay 5:
root@einstein:~# dbus -y com.victronenergy.system /Relay/5/State SetValue %1
2

List of all dbus relays and their status:
root@einstein:~# root@einstein:~# dbus -y com.victronenergy.system /Relay GetValue
{'0/State': 0,
 '1/State': 1,
 '2/State': 1,
 '3/State': 1,
 '4/State': 1,
 '5/State': 0,
 '6/State': 0,
 '7/State': 0,
 '8/State': 0,
 '9/State': 0}

Toubleshooting from command line with modbus

Read Digital Inputs:
root@einstein:~# /data/rgpio/modpoll/arm-linux-gnueabihf/modpoll -m rtu -b 115200 -p none -d 8 -r 11 -s 1 -c 1 /dev/ttyUSB0
modpoll 3.10 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright (c) 2002-2021 proconX Pty Ltd
Visit https://www.modbusdriver.com for Modbus libraries and tools.


Protocol configuration: Modbus RTU, FC3
Slave configuration...: address = 1, start reference = 11, count = 1
Communication.........: /dev/ttyUSB0, 115200, 8, 1, none, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, output (holding) register table


-- Polling slave... (Ctrl-C to stop)
[11]: 255
-- Polling slave... (Ctrl-C to stop)
[11]: 255
-- Polling slave... (Ctrl-C to stop)
[11]: 255
-- Polling slave... (Ctrl-C to stop)
[11]: 255
-- Polling slave... (Ctrl-C to stop)
[11]: 255
#This continues indefinitely

root@einstein:~# /data/rgpio/modpoll/arm-linux-gnueabihf/modpoll -m rtu -b 115200 -p none -d 8 -1 -r 3 -s 1 -c 1 /dev/ttyUSB0 512
modpoll 3.10 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright (c) 2002-2021 proconX Pty Ltd
Visit https://www.modbusdriver.com for Modbus libraries and tools.
Protocol configuration: Modbus RTU, FC6
Slave configuration...: address = 1, start reference = 3, count = 1
Communication.........: /dev/ttyUSB0, 115200, 8, 1, none, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, output (holding) register table
Written 1 reference.

#This lasted about 5 seconds and it returned to a closed state again. 

Check that no process are talking to USB0:
root@einstein:~# ps | grep USB0
25234 root      2688 S    grep USB0

Prevent USB0 to be used by another service:
root@einstein:~# /opt/victronenergy/serial-starter/stop-tty.sh ttyUSB0
svc: warning: unable to chdir to /service/*.ttyUSB0: file does not exist

Below are also some log files from this time as well, 
Firstly logs from rpgio_driver 

@400000006670b017109a38a4 cat: can't open '/dev/gpio/relay_a/value': No such file or directory
@400000006670b017124160c4 /data/RemoteGPIO/rgpio_driver: line 306: /data/RemoteGPIO/bin/modpoll/arm-linux-gnueabihf/modpoll: No such file or directory
@400000006670b01720000e04 cat: can't open '/dev/gpio/relay_3/value': No such file or directory
@400000006670b017209da5c4 cat: can't open '/dev/gpio/relay_4/value': No such file or directory
@400000006670b017210c8494 cat: can't open '/dev/gpio/relay_5/value': No such file or directory
@400000006670b01724425f1c cat: can't open '/dev/gpio/relay_6/value': No such file or directory
@400000006670b01725bcd5d4 cat: can't open '/dev/gpio/relay_7/value': No such file or directory
@400000006670b01728492604 cat: can't open '/dev/gpio/relay_8/value': No such file or directory
@400000006670b0172925e1d4 cat: can't open '/dev/gpio/relay_9/value': No such file or directory
@400000006670b0172a2bb914 cat: can't open '/dev/gpio/relay_a/value': No such file or directory
@400000006670b0172c01fbcc /data/RemoteGPIO/rgpio_driver: line 306: /data/RemoteGPIO/bin/modpoll/arm-linux-gnueabihf/modpoll: No such file or directory
@400000006670b01737db52f4 cat: can't open '/dev/gpio/relay_3/value': No such file or directory
@400000006670b017398165bc cat: can't open '/dev/gpio/relay_4/value': No such file or directory
@400000006670b01739f57c7c cat: can't open '/dev/gpio/relay_5/value': No such file or directory
@400000006670b0173b34c2dc cat: can't open '/dev/gpio/relay_6/value': No such file or directory

And also some logs from rpgio_monitor, this one is really long but sucessfully shows a heartbeat. 
@400000006670afd40b10ec84 Heartbeat = Mon Jun 17 21:51:06 UTC 2024
@400000006670afdf2321c064 Heartbeat = Mon Jun 17 21:51:17 UTC 2024
@400000006670afeb17585f2c Heartbeat = Mon Jun 17 21:51:29 UTC 2024
@400000006670aff7270d4e8c Heartbeat = Mon Jun 17 21:51:41 UTC 2024
@400000006670b00334df9f24 Heartbeat = Mon Jun 17 21:51:53 UTC 2024
@400000006670b00e394cc12c Heartbeat = Mon Jun 17 21:52:04 UTC 2024
@400000006670b01a27ca0edc Heartbeat = Mon Jun 17 21:52:16 UTC 2024
@400000006670b0261b555a44 Heartbeat = Mon Jun 17 21:52:28 UTC 2024
@400000006670b03304231ec4 Heartbeat = Mon Jun 17 21:52:41 UTC 2024
@400000006670b03e31b2c164 Heartbeat = Mon Jun 17 21:52:52 UTC 2024
@400000006670b049305cce54 Heartbeat = Mon Jun 17 21:53:03 UTC 2024

A massive thank you to all involved in this project, it's fantastic, and I love the potential it can provide for my projects. I have played around with this a fair bit on my own regarding all the above comments, but I think I need to reach out for some more direction/help now.

Of course happy to provide more logs or information to assist in diagnosing this, let me know what needs to be done.

Is there a possibility by node-red to reset the USB0 to prevent USB0 to be used by another service like this comand below?

/opt/victronenergy/serial-starter/stop-tty.sh ttyUSB0