That’s an easy one
You need the IP address of the box running VelServ
127.0.0.1 is the local loopback port for the software running in the box to itself.
My guess is you’ll need something along these lines for Velbuslink…
192.168. Something. Something
Hello,
I see 2 problems:
your interface isn’t recognised as “/dev/serial/by-id/…”, so you’ll need to solve this first. It could help to see in the log files when plugging in th interface to see where it’s been mapped to. You can browse to the dir “/dev/serial/by-id” and look for the name of the velbus interface. An other thing you can try is just open the interface as “/dev/ttyACM0” or “/dev/ttyUSB0”
so try “./velserv -d /dev/ttyACM0 -p 6000 -vvvvvv” and check that there are no errors left (no such file or directyory is an error"
you 're trying to connect to your loopback interface “127.0.0.1”. It’s normal that velserv connects to this because the data is distributed on the loopback in your linux box, but when using velbuslink, toy 'll need to state the ip adress of your linux (OH) box to connect to the server…
Hello Jeroen,
Thank you for your reply.
When I look into “/dev/serial/by-id/…” I see following lines:
So no log files into this directory.
When I read it out I got my constant datastream:
I tried to changed it to “/dev/ttyACM0” or “/dev/ttyUSB0” or “./velserv -d /dev/ttyACM0 -p 6000 -vvvvvv” but no connection anymore in OH
you 're trying to connect to your loopback interface “127.0.0.1”. It’s normal that velserv connects to this because the data is distributed on the loopback in your linux box, but when using velbuslink, toy 'll need to state the ip adress of your linux (OH) box to connect to the server…
You mean that I need to enter in Velbuslink my IP adress of my OH? I did so far and I tried all kinds of different ports but no connection was possible here.
Thank you for your help!!!
Hello MDAR,
Wel I did. 192.168.1.20 is the IP of my OH on the RPi. Tried all kinds of ports (scanned also with a port scanner) but sometimes it seems to connect but I’m unable to scan or with other ports it connects and scans but no real connection (can’t e.g. simulate a channel).
result of the port scanner:
Thanks, J
What is lsusb showing? Do you see the Velbus gateway? dmesg output? I had some problems with connecting the gateways as well and it boiled down to invalid path to the device.
Edit: I have some troubleshooting info here - maybe it can help you. The important part:
"Make sure the gateway is connected:
openhabian@openhabian:~ $ lsusb -d 10cf:
Bus 001 Device 003: ID 10cf:0b1b Velleman Components, Inc. VMB1USB Velbus USB interface`
openhabian@openhabian:~ $ udevadm info -q property /dev/bus/usb/001/003 | grep DEVPATH
DEVPATH=/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3`
That path should be the same as reported by “systemctl status velserv”. If it’s different it needs to be changed in “/etc/systemd/system/velserv.service”"
Okay, so just to be super clear, is this statement still true?
IF openHAB is working fine, we can assume that your Velbus TCP gateway is working just fine.
Sorry to ask, are your using @jeroends VelServ app or the Velbus-tcp snap package?
What is shown with
systemctl status velserv
For example, one of my machines shows the application connected to the by-id path and using port 6000
velserv -d /dev/serial/by-id/usb-Velleman_Projects_VMB1USB_Velbus_USB_interface-if00 -p 6000
and (to check if you have the official Velbus-TCP gateway running instead
snap get velbus-tcp -d
ONLY ONE CAN BE ACTIVE AT ANY TIME, I will assume you only installed one, I just need to be clear as to which one, so that I can give you a clear answer.
If you used my script to setup VelServ or velbus-tcp,
BOTH will offer port 6000 via LocalHost / 127.0.0.1 for openHAB to use
HOWEVER
If you installed VelServ by yourself, without using my script, by default it uses a different port, which is what openHAB Velbus Bridge will be using.
Can you look at the openHAB Velbus Network bridge and see what the settings are.
Mine show this
With your port scanner application can you add ports 6000 and 27015, then query your device at 192.168.1.20 to see if either of those ports are available.
IF port 6000 is available.
use this in VelbusLink
IF port 27105 is available, you will need to know what the TLS authentication key is with your velbus-tcp snap package, as shown with the snap get velbus-tcp -d command
You can change this key with a simple command, if you wish.
Hello PrzemoF,
Just had a quick look… The commands gave me following output:
The output of “systemctl status velserv” is:
Is this the line that should be the same?
Thank you for your help!!
Hi MDAR,
Yes used yr script. I think the VelServ package…? When I enter ’ systemctl status velserv’ I’m returned :
When I gave in ‘snap get velbus-tcp -d’ got:
So I’m assuming that only the VelServ is running. However in the ‘systemctl status velserv’ output there is an error (see below). Is this normal?
My openHAB Velbus Network bridge settings are:
I’ve noticed that sometimes the status of Velbus Network Bridge is giving me a communiction error. When I refresh the page it is gone… Strange 
Unfortunatly the ports you are describing are no available here. I assume port 27105 in combination with the TLS authentification is only when velbus-tcp is installed?
Thanks for your support!!!
For some reason on MDAR system by-id works, on mine I had to use by-path.
P.S. If MDAR tells you something else - follow his advice. He knows that stuff for years, I’m just learning…
For reference, my velserv.service file:
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=Velserv
# ConditionFileIsExecutable=/opt/velserv/velserv
After=network.target
After=network-online.target
[Service]
Type=forking
#ExecStart=/opt/velserv/velserv -d /dev/serial/by-id/usb-
Velleman_Projects_VMB1USB_Velbus_USB_interface-if00 -p 6000
ExecStart=/opt/velserv/velserv -d /dev/serial/by-path/platform-
fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0 -p 6000
#ExecStart=/opt/velserv/velserv -d /dev/ttyACM0 -p 6000
ExecStartPost=/bin/bash -c "/bin/touch /var/log/velserv.log"
ExecStartPost=/bin/bash -c "/bin/echo Velserv Started $(date) >>
/var/log/velserv.log"
ExecStartPost=/bin/bash -c "/bin/pidof velserv >> /var/log/velserv.log"
ExecStop=/bin/kill $MAINPID
TimeoutSec=0
RemainAfterExit=yes
StandardOutput=journal+console
StandardError=journal+console
RestartSec=5
Restart=on-failure
[Install]
WantedBy=multi-user.target
and status results
openhabian@openhabian:/etc $ systemctl status velserv
● velserv.service - Velserv
Loaded: loaded (/etc/systemd/system/velserv.service; enabled;
vendor preset: enabled)
Active: active (running) since Mon 2024-07-01 14:27:09 CEST; 2
days ago
Process: 728 ExecStart=/opt/velserv/velserv -d /dev/serial/by-
path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0 -p 6000
(code=exited, status=0/SUCCESS)
Process: 741 ExecStartPost=/bin/bash -c /bin/touch
/var/log/velserv.log (code=exited, status=0/SUCCESS)
Process: 758 ExecStartPost=/bin/bash -c /bin/echo Velserv Started
$(date) >> /var/log/velserv.log (code=exited, status=0/SUCCESS)
Process: 780 ExecStartPost=/bin/bash -c /bin/pidof velserv >>
/var/log/velserv.log (code=exited, status=0/SUCCESS)
Main PID: 739 (velserv)
Tasks: 4 (limit: 4531)
CPU: 9.963s
CGroup: /system.slice/velserv.service
└─739 /opt/velserv/velserv -d /dev/serial/by-
path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0 -p 6000
Jul 01 14:27:09 openhabian systemd[1]: Starting Velserv...
Jul 01 14:27:09 openhabian systemd[1]: Started Velserv.
Okay
So as PzremoF is suggesting, you need to confirm the path to the Velleman USB interface is correct.
The fact that your openHAB bridge is going online and offline tells me that VelServ is auto-restarting.
Which hints to the fact that the base OS of your board is losing the USB module.
When the USB module is lost to the OS, VelServ closes, but the service file restarts it.
Without knowing the Raspberry Pi at all, but assuming that my script worked well previously.
We should assume that the /opt/velserv/velserv -d /dev/serial/by-id/usb-Velleman_Proje cts_VMB1USB_Velbus_USB_interface-if00 path is correct
The best way to check this is simply by running an ls -l command
ls -l /dev/serial/by-id/
Which should return something like this
total 0
lrwxrwxrwx 1 root root 13 Jun 30 11:52 usb-Velleman_Projects_VMB1USB_Velbus_USB_interface-if00 → …/…/ttyACM0
Which tells you that the Velleman USB module is alive and well and also routed to /dev/ttyACM0
(However, I found that for people with multiple USB serial devices, Linux can assign them differently on each startup, hence using the /by-id method, as that never changes.
(I can see from your screen shot that the service file is looking to start Velserv with the by-id path.)
What I am thinking is that the Velserv config is fine, as is openHAB
But the problem is that the PI is losing connection to the USB module.
Just something to check (eliminate), can you use a different USB cable between your PI and the Velbus interface?
OR
Can you plug a laptop into the Velbus USB with the same USB cable and see what happens?
Purely for context.
This shows that whatever OS PrezmoF is running doesn’t support the serial/by-id method and he chose to use the /dev/serial/by-path method, to define the precise USB device that VelServ should use, rather than risk the OS juggling the USB devices on start up.
That would suggest it has stopped completely.
Does this command start it going again?
systemctl start velserv
###############################################################################
############### openhabian ##################################################
###############################################################################
## Ip = [edited - not public info]
## Release = Raspbian GNU/Linux 11 (bullseye)
## Kernel = Linux 6.1.21-v8+
## Platform = Raspberry Pi 4 Model B Rev 1.5
## Uptime = 2 day(s). 19:51:40
## CPU Usage = 0.81% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
## CPU Load = 1m: 0.09, 5m: 0.04, 15m: 0.01
## Memory = Free: 2.23GB (60%), Used: 1.51GB (40%), Total: 3.75GB
## Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
## Root = Free: 47.34GB (84%), Used: 8.53GB (16%), Total: 58.28GB
## Updates = 13 apt updates available.
## Sessions = 1 session(s)
## Processes = 131 running processes of 32768 maximum processes
###############################################################################
_ _ _ ____ _
___ ___ ___ ___ | | | | / \ | __ ) (_) ____ ___
/ _ \ / _ \ / _ \ / _ \ | |_| | / _ \ | _ \ | | / _ \ / _ \
| (_) | (_) | __/| | | || _ | / ___ \ | |_) )| || (_) || | | |
\___/| __/ \___/|_| |_||_| |_|/_/ \_\|____/ |_| \__|_||_| | |
|_| openHAB 4.1.3 - Release Build
Looking for a place to get started? Check out 'sudo openhabian-config' and the
documentation at https://www.openhab.org/docs/installation/openhabian.html
The openHAB dashboard can be reached at http://openhabian:8080
To interact with openHAB on the command line, execute: 'openhab-cli --help'
openhabian@openhabian:~ $ ls /dev/serial/
by-path
There is no by-id on openhabian 4.1.3
Good evening,
Sorry for my late reaction. Indeed there is no by-id only by-path.
‘ls -l /dev/serial/by-path/’ gave me:
The ‘/dev/ttyUSB0’ is for my Smart Meter.
@MDAR; I will try another cable tomorrow and I come back to you.
Which begs the obvious question…
How was it working before, as my script calls the by-id path ?
Not a big deal, use the by-path method or risk the /dev/ttyACM0 etc symlink option
As Przemo suggests, you need to edit the
/etc/systemd/system/velserv.service file and make the ExecStart line look like this
ExecStart=/opt/velserv/velserv -d /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.2:1.0 -p 6000
Save that change
then run these commands
systemctl daemon-reload
systemctl enable velserv --now
It never worked for me out-of-the-box, but my linux kung-fu is strong, so I fixed it after a short troubleshooting session. 
Indeed.
I think because my script assumes a by-id path is available, which I had to do because there’s no way I can predict which ttyxxx port each Linux box will give it.
While looking for a link for another post, I stumbled across some Linux Magic that @Stef_Coene created a few years ago, to address the issue of some Linux versions not playing nicely with USB devices (as in, not assigning the same tty link in boot up.)
His udev rule creates a new ttyVelbus symlink.
Thanks to your input, I revisited the use rules solution that @Stef_Coene created and expanded it to include the new Velbus USB options.