My main velbus run is quite long (about 900m, maybe a bit more).
It has 4 din rail cabinets, each with own 18V DC PSU for dimmers and relays in that cabinet.
And I have 3x 300m runs to switches and a few “extra” modules (VMB4DC for fan speed control, extra relays in the garage etc
Between four seperately powered sections I join 3 connections GND (DC 0V), BUS-L and BUS-H, as shown in a Velbus doc somewhere I think.
But I note that CAN bus L/H is differential so presumably there is no need to join the 0V to sections that are independently powered? I could send velbus over just one pair?
Why do I ask?
Because I am considering one more run of velbus to another building (my workshop) but that will also have it’s own velbus PSU. So can I get away with using just one pair for that (to carry BUS-L and BUS-H so no 0V or +18V).
Yes, I know, I did not cable the workshop adequately. I have just one CAT6 cable from loft to workshop. I should have installed two (one for velbus, one for network). I am now wondering how best to have network and velbus in the workshop.
Or is there perhaps a simple way to bridge two runs of Velbus over ethernet?
My existing main run of velbus is already on a Pi3B with velbus-tcp-snap but I need that connection for velbus admin+development.
I have had issues with velserv (scans often don’t complete) but velbus-tcp-snap has been pretty solid.
So… the main velbus run already has velbus-tcp-snap on a pi… as used for my normal remote connection from velbuslink on the LAN.
If I put velbus in the workshop, and presumably, another pi, also running… velbus-tcp-snap?
Is that enough to bridge the two velbus runs AND still allow me to connect remotely from velbuslink on the lan?
I am slowly learning details of CAN… I have wondered about a pure CAN level link over ethernet but CAN seems to me to be too real-time for that to work 100% (eg. ACK and ERROR, for various real-time conditions, cannot work as they would on a common CAN bus) but I am not sure if that is enough to be a real problem for velbus (because maybe those errors would normally not occur?).
I did see that behaviour many years ago, when running VelServ on an overloaded BeagleBoneBlack and very occasionally on an Odroid C2.
But I’ve never seen that when running on an Odroid C4.
@jeroends
Is this something that we have addressed or were we unable to replicate the error consistently?
However, I have put a feature request on the Velbus GitHub page for Velbus-tcp, asking for a Client mode.
I’ve also created a support ticket / feature request.
That’s the concept, except any secondary instances need to have a Client mode to connect back to the main Server instance.
If… (and I know you don’t) have a software solution like openHAB or HomeAssistant, you could connect to two isolated Velbus networks, each with their own TCP server and present all Velbus assets in one UI.
Even creating rules to map events from one segment to another / others.
But that’s not what you’re looking for here.
That’s the concept of VelServ(s) in Client mode, looking back to a central Server instance.
I have an upcoming project where there will potentially be a number of electrically isolated Velbus networks (out buildings) that need to be linked together.
This would require multiples of what we’re talking about here.
It’s certainly an option, but outside of anything we can directly support you with.
Just keep in mind that the current speed of Velbus is 16.6Kbps, but this ‘might’ change in the future for pure V2.0 networks (combination networks will roll back to 16.6Kbps).
In theory, a CANbus to TCP client & TCP server to CANbus bridge would work… If you can get the timings right.
I did have a long conversation with a CANbus specialist some years ago, where we were discussing using their CANbus isolation hub, designed to link electrically isolated segments, with a large Velbus network where the client wanted resilience against segment damage.
(They were concerned that if one leg / section of the Velbus data pair were damaged / shorted, it would take out the entire network, which it would.
However, 11 years later, it hasn’t happened)
All that said.
If you have got a spare pair of cores and a ground reference between the building, it might be worth simply using that to link the Velbus data.
I guess it depends on what you’re primary objectives are.
I know this may not be helpful, but: what do you really need to achieve? Because based on the real bare bones requirements, there may be another option than just knotting everything together with copper.
I have reviewed the CAN physical layer docs and thought about what the CAN driver chip does… and yes, velbus (and most normal non-isolated CAN buses) DO required the ground (0V DC) connection otherwise the DC offset and noise can easily be large enough to exceed the common-mode range of the driver chips… circuitry could be damaged.
Hi PDH
I am thinking of extending the house Velbus into my new Workshop (just for occupancy, simple light-switches, and a few relays for lights and heating plus external light and PIR).
I had indeed been wondering about sharing my single Cat6 cable… for 100Mbit ethernet (two pairs) plus Velbus on the other two pairs (this is my fallback option)… and then I just wondered whether velbus really needs two pairs. I have seen other lighting bus connections that use 1 pair (eg. Helvar, and also DALI of course but DALI is not proper SELV).
Ideally I would like to keep all four pairs as a gigabit ethernet connection to my workshop… as long as I can push everything I need over ethernet. I am considering homebrewing a simple ethernet bridge if I have to (much simpler than a Pi - I have various bits of hardware that can read velbus now) but a reliable off-the-shelf solution would be better. My Workshop electrics (lighting, heating, ring-main, network) will hopefully come together some time in November but trunking (all around the room) and conduit (down to switches and sockets) is all surface mounted so changing it to velbus later is an option.
Cat 6 is a complicated machine to allow high bit rates through simple twisted pairs. They are all used by the switches to transfer the data. Use some of the wires in the cable for Velbus might kill everything.
It’s OK, I sorted it out (squeezed an extra cable in).
My initial confusion was whether Velbus/CAN really required the ground connection. It does not need the +ve if not powering the other end, and the signal is differential (like ethernet) so it initially looks like it could go over just one pair. That would have let me run fast ethernet over just two pairs (they do not need a ground). I have used this before to push two 100 Mbit ethernets down one cable - I wondered if I might be able to do the same for velbus.
However, unlike ethernet, Velbus is still wired with a common ground reference so you cannot omit the ground. In theory you might be able to but the common-mode swing can easily be outside the range rejected by input buffers… so it’s just not sensible.
Ethernet only really (normally) isolates and omits the ground by including transformers in the cable connection.
In the end i managed to pull another cable through the trunking. It is only plain CAT5… CAT6 (and EIB Cable also) was far too inflexible, but CAT5 is very flexible and is plenty enough.
My ethernet is now over the whole 4-pair CAT 6, so is gigabit, and velbus over the CAT5; wired with one pair for + and one pair for -, and just one pair for velbus H/L, so I even have a spare pair. Velbus seems very tolerant of plain old CAT5… just watch for the voltage drop on +/- if cables are long.
I have run 100Mbit ethernet, and Velbus, and modbus all over a single CAT5E cable before just fine but the runs were a lot shorter and the Velbus and modbus were sharing 12V power wires. My cables on this project are too long to run power over just two CAT5 wires.
