TPC/IP connection Velserv - Velbuslink not working

jvelbus · July 2, 2024, 10:01am

Hi everyone,

I want to connect my Velbuslink via TCP/IP. I did install the Velserv on my Pi4B.
I recently updated from OH 2.5 to OH 4.1. In OH 2.5 I could connect without any porblem but after the new OH 4.1 (building from scratch) installation no connection is possible. However I checked if the Velserv was running and it was (see below). Also OH is running fine.

Entered the adres and port as I did before but no connection possible from Velbuslink.

afbeelding

Any ideas how I can set this up or what is wrong here?

Many thanks,

Jona

MDAR · July 2, 2024, 4:47pm

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

jeroends · July 2, 2024, 5:51pm

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…

jvelbus · July 3, 2024, 11:02am

Hello Jeroen,
Thank you for your reply.
When I look into “/dev/serial/by-id/…” I see following lines:
afbeelding

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!!!

jvelbus · July 3, 2024, 11:24am

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:
afbeelding

Thanks, J

PrzemoF · July 3, 2024, 11:51am

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”"

MDAR · July 3, 2024, 2:36pm

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.

jvelbus · July 4, 2024, 7:58am

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!!

jvelbus · July 4, 2024, 8:26am

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!!!

PrzemoF · July 4, 2024, 8:43am

Get the result of “ls /dev/serial/by-path”. It will be something like:
platform-blah-blah-blah
Edit the velserv.service file
Make a copy of the ExecStart line
Comment out (add # in front of the line) one the original ExecStart line
Change the path starting after -d to /dev/serial/by-path/[the results of the ls command from point 1 here]. It will look like this:
ExecStart=/opt/velserv/velserv -d /dev/serial… -p 6000
Restart velserv with “systemctl restart velserv”

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…

PrzemoF · July 4, 2024, 8:44am

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.

MDAR · July 4, 2024, 10:20am

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.

If not present, Velserv will close and the service file will restart after 5 seconds
If present, VelServ will run perfectly.

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.

MDAR · July 4, 2024, 10:21am

That would suggest it has stopped completely.

Does this command start it going again?

systemctl start velserv

PrzemoF · July 7, 2024, 8:08am

###############################################################################
###############  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

jvelbus · July 9, 2024, 6:31pm

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.

MDAR · July 9, 2024, 8:32pm

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

MDAR · July 11, 2024, 9:47am

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

PrzemoF · July 11, 2024, 10:40am

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.

MDAR · July 11, 2024, 11:46am

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.

MDAR · July 19, 2024, 2:00pm

@jvelbus

How did you get on?

Are you back up and running now?