OK, Velserv is starting manually OK but despite my following the instructions in jeroends github to install the service, it does not start up automatically on boot.
ps shows it is just not there (as running process) after boot. And the systemd journal looks like this…
pi@pivelbus:~ $ journalctl -b | grep velserv
Mar 28 18:39:11 pivelbus systemd[1]: Starting velserv.service - Velserv…
Mar 28 18:39:11 pivelbus velserv[439]: /bin/stty: /dev/ttyACM0: No such file or directory
Mar 28 18:39:12 pivelbus systemd[1]: Started velserv.service - Velserv.
Mar 28 18:39:12 pivelbus systemd[1]: velserv.service: Main process exited, code=exited, status=1/FAILURE
Mar 28 18:39:12 pivelbus systemd[1]: velserv.service: Failed with result ‘exit-code’.
pi@pivelbus:~ $
But if I now start it with
sudo systemctl start velserv
Then it starts up just fine.
Anyone have any good idea what is going wrong?
But that got me the same error. I wondered if somehow perhaps the name was not resolvable yet at boot-time so I changed it to the standard port that I knew my VMBRSUSB was mapping to… but the same result.
dmesg suggests that the VMBRS is genuinely on /dev/ttyACM0
I tried switching back to original velserv too… same result.
When I manually start velserv (aside from when in development, when it is not resident) I just use
sudo systemctl start velserv
And then it works just fine. That is how it is running just now.
All of this is on fresh simple installs on latest Raspios image but there have been a lot of re-attempts and I can’t help wondering if I have missed something obvious. I will try a completely clean install and setup this weekend to see if that sheds any light on things.
The system that is failing to start automatically is an old Pi1 Model B+ running the latest Raspbian Lite (which is “12 (Bookworm)” ).
Oh, and the exact same install on a Pi3B running Raspbian Lite (“10 (Buster)” ) seems to start-up at boot just fine… so the install process is probably not the problem.
I just double checked and the source files and service setup are identical on both. Each is on it’s own velbus with it’s own VMBRSUSB. Each executable is built on it’s own host Pi (so the executables are not identical as they are build against different OS versions). The Pi1 with newest OS just fails to start the service.
Curious. I must be missing something or else I’m going to try an old image on the Pi1 when I can find time.
Cool!
I just installed dietpi on an even older early Pi1 Model B that has just 256MB of RAM. And then I compiled Velserv and installed the service, as detailed in jeroends github page.
It works great!
And everything starts up correctly on power-up too.
It even has 100MB memory free, and no SWAP use.
Thankyou for the suggestion.
And a +1 from me for DietPi, to anyone wanting an easy and flexible custom Linux install without a lot of command-line messing. I have only used the minimum here but there is also much more too it and the supported configurations and packages.
I’ indeed not very active anymore at the forum and the code of velserv didn’t change that much since 2007 already
I think the missing modules problem relays on that fact that my code never states the buffer full command since back than there was never a problem of the buffer running full.
So I think 2 options in this one: enlarge the send/receive buffer of velserv or implement the buffer full option wich get the senders to wait when it’s full.
the bigger the installation gets, or the more data is needed to be transfered, the more chance you’ll run against this issue.
For now I think option 1 is the most fast way to change, option 2 is for me now hard to implement since no time (story of the last 6 years).
I don’t have any problem anyone else changing the code, but do it on github and keep it open like I started it (I 've bad experience of people running away with credits).
As for the NTP part. The setup that time was to create different clients depending on the needs of everyone else. So thats why hte time sync was written as a seperated client, as also some perl scripts and even a PLC part. The latest was never finished since the upcoming home server tools so it was useless to do more effort in that one.
As for the startup scripting, linux starting system changed much the last years and I did not follow the evolution. The biggest chance you’ll have is changing the permission of the usb interface because I don’t know with which user the startup systems start the velbus program.
I still use my velserv program on a PI4 with an older version of raspi running openhab. Parallel runs an dedicated mini PC with home assists in a virtual environment. I’ll have to migrate everything, but … see above
Thanks. I have the clock-setting working in a custom velserv build now and everything is fine here. And running very nicely on dietpi. I don’t write often write linux code so reading-around the changes was quite educational here too.
And most of all thanks for providing the source on github… having all that command-line handling and startup-install stuff and some sensible error handling in there makes all the difference.
I would fork or push the change back but I’m not sure how (I’ve never pushed to github). I doubt anyone else needs my use-case anyway.
idd good question, I’ve never took the time to read the functions of github, If you find out, let me know because I’d probably have to give you access to it.
OK, I will look into learning more github when I have time. It’s probably fairly easy to get the Velserv code change up there somehow.
Raspberry Pi with Velbus USB interface is still probably most cost effective since it is cheap and can do the time and expose the velbus server. PiZero (cheap/old single-core model) is more than powerful enough but does not have CAN or ethernet or RTC (clock to avoid reliance on network for time) without add-ons.
You can do simpler, but whether Arduino or ESP32 or Pi Pico etc all the “off-the-shelf” boards I have seen appear to need 2 or 3 other small boards adding to get all the hardware needed. Then you could avoid need for SD card and Linux OS.
I did fancy making something with STM32 or ESP32, with CAN, RTC, and a small LCD display and a few buttons, and ideally ethernet too… running a slimmed-down velserv plus a simple scripting language (eg. Micropython or Lua) able to run a few hundred lines of user code that can be easily updated over network.
I am not known for finishing such projects though :-/
Much easier for Velleman to do. I would buy it… but how many would they sell?
LOL, yes I did.
Either of those two approaches would get you most of the way there.
Just missing ethernet.
I would not like to rely on WiFi… Velbus+Velbuslink is real-time enough that normal WiFi can cause problems that Velbuslink might not handle.
ESP32 does have ethernet support but most the devkits do not have the little bit of extra hardware required (PHY+magjack)… probably because the WiFi is so popular.
Oh… I see there IS a PoE module for the Atom S3 also…a bit pricey though.
With a few software tweaks and some added CAN support those 3 modules combined could definitely run an adapted velserv without Linux or SD card.
RTC would be nice but we could probably do without it if we can rely on being on a LAN with an internet connection.
oh, it looks like the M5Stack PoE addon is a whole other ESP32, interfaced to another M5 ESP32 module over a serial port like a modem… which is OK for short IoT messages but probably won’t work well for Velserv.
There are homebrew options but they still need a bit of work to make tidy.
or you could take an Arduino ethernet and add a cheap CAN interface (several different options there). Still ends up multiple stacked boards though… and needs a case of some sort.
Or PJRC’s Teensy 4.1 has ethernet PHY and CAN and RTC all built-in but just needs a RJ45 socket and a simple CAN driver chip added (and a small battery to support the RTC). Still also needs a case really to hold it all together.
Making a 1-off from cheap boards and a 3D printed case is not too hard but not so easy to recommend a set of cheap parts for easy home assembly :-/
I think the old Pi3B (in standard rPi3 case) or a single-core PiZero is still looking hard to beat. Though to connect to connect the PiZero to ethernet AND Velbus USB at the same time you would need to add something like this hat+case. I have several of these and they work well…
All of the above also need a small 5V PSU.
You could put a CAN hat on the Pi also to avoid needing the Velbus USB interface but I like having the Velbus USB as a fallback anyway.
I would still like to see a single simple DIN-rail mount PCB that can be powered from Velbus, that has microcontroller + CAN + ethernet + RTC, and a small display. And maybe a SPI flash to store script (simple programs written in Lua or MicroPython).
It would really just be an upgraded version of the VMBRSUSB.
