Good to hear you got it working; it was a dirty but Proof Of Concept workaround that one byte change. 
That should be possible too, changing the x-tal to a dividable multiple of 16k6 (not 8 nor 16 MHz).
Will take a look at your Canable suggestion over time.
Hello friends,
To bring new live into this discussion, I made an overview of what I think are the options to have multiple Velbus system linked.
My challenge
I would like to have some Velbus modules in my garage
Concept 1 - long cable
Installing a cable straight through the backyard is not an option.
Concept 2 - ESP32 modules to connect buses
This is the solution I was planning to develop. But quite a challenge. Because the 2 Velbuses are no longer connected on electrical level, there will be multiple messages on the buses at the same time. The “ESP” interfaces will have to buffer a lot of data. Especially for bus scans (255 messages) and read/write to/from modules. Major benefit: operation not depending on a Raspberry pi (which can fail, corrupt SSD, etc).
Concept 3 - Velserv in server & client modes
Use Velserv in Server-Client modes. This would link the buses at a “driver” level (not really driver level, but rather low level on the RPI. But does require a raspberry RPI in my garage. But, a crash of OpenHab will not endanger my bus performance (and that is a very important WAF (Wife Acceptance Factor).
A Pi-Zero of Nano-Pi with bare minimum install could do the trick and probably provide a few years of stable operation.
Concept 4 - Linking by Openhab
Variation on concept 3. Just let Openhab do the linking of the 2 buses. So basically 2 separate buses.
Concept 5 - Hardware TCP-Serial interface
I found an “hardware” TCP-Serial interface module which I connected to my own “Velbus serial interface”. OpenHab then connects to the TCP port of this module. Actually, that worked better than expected.
Status
So far I did test #5. That works.
So far I did test #4. That works.
I would like to test #3, because in theory, it would result in 1 Velbus and Velbuslink should be able to detect all modules of both the house and the garage. Just need to find some time. #2 will take a lot of time and effort and is on hold for now.
BUT, how many signals do I really need from the garage in my house Velbus? 1 or 2 (or none, has been working smooth for 5 years now). It is just for convenience to check the lights are out and the garage door is closed.
Greetings Matthijs
Hi
I’ve tested this with a BeagleBone Black (VelServ Clients) to an Odroid C4 (VelServ Server) and it works very well.
I did send a BeagleBone Black with VelServ in Client mode for Cytech to test new Velbus modules on my demo rig, but they never acknowledged receipt of the unit, nor have I ever seen it connect. (What a waste of £90)
In theory, it should have worked perfectly.
I am not inclined to trust WiFi. I have had trouble with WiFi connection to Velserv when the Wifi signal is not 100%… initial bus scans sometimes fail to complete and this upsets things at Velbuslink.
I do have a lot of modules though so that initial scan requires a lot of traffic to complete.
I suspect that Velbuslink waits after each device query in the scan, to see the response… and if there is no reponse within a short time it moves on to the next ID… and I suspect that a response coming in late (because poor WiFi connection) stuffs this up in a way that Velbuslink is unable to recover from.
Velbus TCP-snap seems to cope better but in any case I have switched to wired connections 99% of the time. I never have any scan problems with a wired connection to the server.
I think you need to find an excuse to run two CAT6 cables to your garage 
(May as well use TWO to futureproof… one for wired LAN, one for Velbus).
Are you SURE it is not possible?
Hai,
Yeah I am sure. Cable(s) to the garage would mean I have to dig a trench of 20 meter, and have some serious rugged CAT6 cables at least 50 cm deep in there. Nahhh. Not worth the effort.
I now have 2 Fritz routers / extenders facing each other (line of sight) and that works like a charm.
So I am not afraid of wifi. Just must make sure that any TCP type of connection, properly re-connects on signal loss.
Grtz Matthijs
Do you have any CAN+Velbus code already running on ESP32 or is it something you have yet to start?
But I presume you DO still have STM32 modules running CAN and connecting to Velbus already?
And development tools ready to go.
What if you used STM32 with some other radio for the bridge instead of WiFi?
No Pi, no OS, no WiFi, no TCP/IP stack.
There are lots of very cheap bi-directional radio modules with better range than WiFi and much lower latency. And they are very well supported by library code on Github with small or no OS-library dependencies. ie. they are simple, fast, small footprint.
NRF01 modules (2.4GHz), or the HopeRF (RFM95/96/98) LoRa modules 868 or 433MHz all just a few Euro each. The HopeRF LoRa modules are slower than WiFi but have much lower latency and much longer range and are very easy to use from a microcontroller.
I don’t think buffers would need to be too large. Velbus is only 16K6 baud and even during a bus scan the traffic is only half duplex and has pauses for responses. You only have to go faster than that. You can probably even block whilst waiting for CAN TX (so no need for multiple TX buffers).
The Nordic nRF24L01 can manage 2Mbit in some cases. The HopeRF modules can manage 300kbit or easily trade that speed for longer range and low-error. They can be very RF noise immune.
You could start with bridge code using two of your existing STM32 with a UART link between them as proof of concept… easy to debug. Then replace the UART link with simple radio for the same packets.
It’s just a thought if you might have the kit for this already lying around… I don’t like the unexpected latencies that come from TCP/IP stacks… it can be a lot of other software between your code and the hardware. Even on Windows+Linux systems I have had trouble from Nagle interfering with packets that is very difficult to debug real-time.
FYI
Be aware that (pure) Velbus V2.0 networks will work at a much faster speed.
I don’t know what it is, but I’ll find out.
Interesting. But would seem sensible.
Choosing to stick to CAN spec back in 19XX looks to be paying off now… must make it much easier for it to be backwards compatible given wide availability of cheap CAN controllers.
Can you check the likely impact on cable length also? (I think I must be close to max now, even at 16K6).
I presume V2.0 can also still be set to lower speed where max bus length is needed?
I’ll have to ask that question about the V2.0 hardware.
The official word on original spec hardback is that with a cable like DeviceNet_Thick, you can expect a first to last module maximum cable length of about 3KM
The word is…
With Velbus V2.0 pure systems, at the new faster speed on standard EIB / CANbus cable, we’re looking at a maximum cable distance of 500M
However, if the bus speed is getting faster, it might mean it’s suitable for standard CANbus isolation / repeaters.
I’ll reach out to a company I spoke to years ago and see what’s new
Lots of nice ideas.
I found out some things:
Concept 6
Meanwhile I have been playing with concept #6. I asked ChatGPT to make an example on how to bridge between 2 network ports/sockets. That was a good basis to continue experimenting.
So the bridge (in this case a python script) connects to both servers (!) and just copies the data between them. Because it is 1 script, I can disconnect both sockets if one fails. This turns out to be quite important. In the main loop of the script, I then can try to reconnect some time later.
I am going to stress test this script this weekend.
Greetings Matthijs
Yeah, dedicated RF modules is for sure an option. I do have some Zigbee modules around here that make a transparent serial data link.
I also have some experience with the HopeRF modules. I just was hoping to use a more standard solution in the end.
But I will give it a go. At least an RF solution is hardware / firmware based and not depending on an RPI to work.
I really like the HW solutions for stability and robuustness.
Keep you posted.
Greetings Matthijs
I recently installed five AirMax 5G Ubiquity wireless bridges in the roofs of a complex.
(Not 5Ghz WiFi, these are a stand alone 5GHz point to point or point to multi-point devices for long distance data linking)
I was amazed at the throughput.
Fairly easy to setup, the UI is great and if you add in location and elevation data, it gives a great graphic to show the setup and self assessed traffic speed.
These would be worth a try for your data bridge.
Ubiquity NanoStations
https://www.broadbandbuyer.com/products/30941-ubiquiti-loco5ac-kit-pnp/
Apparently…
Good for 13KM @ 300mbps
I am getting ~350mbps at about 100M from one pair
Concept 6
Worked on this concept for a while, it works, but VelBusLink shows some weird errors about the “Bus being not oke”. So my idea is that copying the data between 2 velbus servers, messes up the timing. Especially the scan messages (which have a 50 msec gap to allow for answers), are triggering some sort of crash behaviour.
It did run for a few hours without any issues, then all of a sudden things went south very fast.
Anyway, off to the RF link testing.
Just a thought… did you definitely have Nagle and delayed ACKs disabled (ie. TCP_NODELAY and TCP_QUICKACK) for ALL the sockets you were using, on both sides?
Otherwise TCP delays can easily be unexpected hundreds of ms and debugging the resulting behaviour can be difficult. If they exceed even just one scan timeout then the whole scan can break.
On top of that, if you are using WiFi (rather than wired) that can sometimes also do it’s own breakdown and reassembly of packets that causes further delays.
When the link gets unreliable velbus-tcp-snap seems more robust that velserv.
Good info! Thanks! But I decided to sped no more time on it. (the engineer in me wants to solve this, but not at all costs).
The “most efficient” solution turned out to install an RPI 3B+ in the garage. It runs an velserv instance, OpenHab connects and transmits the 2 signals for which I needed a bridge in the first place.
The RPI also uses Modbus to read my 2 solar converters (on the garage roof). 2 birds with 1 stone.
Greetings Matthijs
I’m just curious
Are you running two Velbus network bridges in your openHAB instance?
(This works very well as a solution)
Yes indeed. 2 Bridges. Only 4 rules to get it working.
And now openhab handles any connection issues or wifi loss. Seems to be robust so far.
Latest update (Aug 2024) is that there is no Velbus in the garage anymore. Too much modules for 1 or 2 lights.
Now the solution is (and has been working for 1 month):
Zigbee2Mqtt bridge on the RPI for 2 Aqara Zigbee sensors (door + motion) + Zigbee antnenna. Save on cabling in the garage. Just 2 battery powered modules.
2x 433 MHz controlled power sockets. There is this Dutch “KlikAanKlikUit” series of 433 MHz modules and the transmitter is in the house, connected to the main RPI. But range is enough to trigger the whole neighborhood
This turned out the be the most efficient for me. Especially the battery powered part of it saved a lot of time.
Schematic of the current layout:
Note:
