Linking actions across two systems

For developers
1

I have an existing Lonworks based automation system that is set up as two separate networks because of physical distancing that can communicate using LON over IP (each network has a router etc).

I’m in the planning stage of the replacement and really like the experimentation I’ve done so far with Velbus.

My question is, can I get one system talking to the other - the existing functionality I would need to replace is:

  • a light switch on network 1 triggering an action (relay etc) on network 2, along with the associated feedback event.
  • local triggering of an output node (such as a relay) on network 2 sending the feedback event to a switch bound from network 1
  • sending of climate / daylight related events from external PIR nodes on network 2 to nodes on network 1

Would I be best use use some type of virtual relay for the output and have HAB or HA do the network synchronisation ?

2

There’s two ways you can do this.

Either, each network is independent, with it’s own mini computer running Velbus-tcp and one of the machines also running openHAB, HomeAssistant, NodeRed etc, connected to both Velbus networks.

Then it’s a matter of creating rules to link the events between the Velbus networks.

  • The advantage of this solution is that you can have 254 base addresses in use in both networks.

  • Disadvantage is that you must create the links outside of Velbuslink

The key question is "just how much interaction do you really need between the two locations?

Alternatively

You can make use of a great feature @jeroends put into #VelServ

Create your two Velbus networks.

On the primary network, install a computer running VelServ in server mode, which will allow you to connect Velbuslink, openHAB, HomeAssistant, NodeRed, Control4 and so on.

On the secondary Velbus network, connect a small SBC and only run VelServ, but in Client mode, directing it to the Server mode instance of VelServ on the primary network. (This does work across a reasonable public internet connection, you can make it secure by using a VPN or Zerotier bridge, instead of just opening a port on your primary router)

  • Advantage of this approach is that the two locations would present as one big Velbus installation to Velbuslink (and openHAB, HomeAssistant etc) and permit complete interaction between all modules natively.

  • Disadvantage is you are limited to 254 base addresses.

FYI, I have requested that the official Velbus Python / snap package also get a Client mode, but I doubt that will come any time soon.

Does this help you?

1 Like
3

Thanks for all of that.

There’s a bit to unpack so I will try to get my head around it later, at this stage I’m just pencilling in “it’s possible”.

The existing solution used one RS485 cable across both networks (wired as one big daisy chain) but we had issues with the connection between the two buildings so I’d rather that each network was physically separate, even if logically connected (your second idea). I can split the wiring by removing the two parts that travel in a conduit underground between the buildings.

From memory we have around 5 lighting circuits physically connected to output nodes on network 2, where we require switch controls in locations that are part of network 1.
And there was a switch on network 2 that was connected to a relay on network 1 that would indicate the status of the main garage door in a remote building.
Plus a 4way RF keyfob that was connected to a 4 way switch input on network 2 (one channel had a binding which would set the alarm status on network 1 but I will come up with a different solution for that).

Cheers

1 Like
4

I’m sure you’re on the right track.

Feel free to ask if you need anything.

FYI

Velbus does have a 2 or 4 button keyfob solution.

1 Like
5

I only replaced the original RF keyfob system last year with a Sherlotronics RX4-500

1 Like
6

good call.

Any of the Velbus input devices will work with the switch outputs of that unit.

VMB8IN
VMB4PB
VMB8PB

and so on

1 Like
7

The suggestions for splitting the network and joining using velserv are already covered pretty well.

I just wanted to ask if you have any idea why the “one big network” approach might be a problem?
Short form of question: Does your long bus carry power? Could it just be voltage drop on the supply?

My velbus network runs on just over 1km of CAT6 cable with the power lines doubled up. The velbus signal wires here are just one pair but they handle this cable length just fine. My 1km length is in 4 sections, all joined together in one long bus (plus a few short spurs). Most of my velbus DIN-rail modules are sort of near the middle but I have switch modules all along and I do have a couple of relay modules and some VMB4DC nearer the ends.

The only problem I did have with the length of this setup is voltage drop on the +/- power lines between the middle and one of the ends. The end which gave me trouble was seeing a voltage drop that caused a VMBRLY4NO module to occasionally complain about low voltage. My 18V supply (about 30% along the total length) was down to 11V at the furthest end.
I solved this by adding a separate power supply to the end section on that end of the bus (and breaking the “+” wire at that section’s other end. This was easy for me to do because each section of bus here is a loop ie. I can get to both ends in a place where I have power available.

Just a thought.

2 Likes
8

Thanks for sharing your experience. Probably if starting from a new install, but wiring is legacy, and I’d need to dig up paving to retrofit.

1 Like
9

Oh, so the LON over IP was actually on a LAN?
ie. the cable was carrying regular LAN traffic as well as the LON signals?

I missed that first read through.
Does sound like two buses and velserv ought to be almost a drop in replacement.

2 Likes
10

FWIW this doesn’t need to be baked in necessarily (even if it would be a nice-to-have). Something like the socat(1) utility can be used to link together arbitrary TCP services like these. Or if one is using node-red they can use the built-in tcp in/tcp out nodes to a similar effect.

Here’s how you’d do it with socat (assuming port is 27015 on both machines):

socat tcp4-connect:192.168.110.1:27015 tcp4-connect:127.0.0.1:27015

Or in node-red

[{"id":"d76143fb456a2cc5","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"6928cb8711e980dc","type":"tcp in","z":"d76143fb456a2cc5","name":"","server":"client","host":"192.168.110.1","port":"27015","datamode":"stream","datatype":"buffer","newline":"","topic":"","trim":false,"base64":false,"tls":"","x":240,"y":160,"wires":[["226fe3bc5c6ef2c0"]]},{"id":"226fe3bc5c6ef2c0","type":"tcp out","z":"d76143fb456a2cc5","name":"","host":"127.0.0.1","port":"4567","beserver":"client","base64":false,"end":false,"tls":"","x":470,"y":160,"wires":[]}]

Unfortunately it isn’t as easy to do the same in OpenHAB/HA/etc. due to how they are architected to abstract networking away.

As a recommendation to OP: the way to go about joining the two networks together like this is to first setup this forwarding link between two buses and only then go about configuring them. Once the two are connected, the VelbusLink software will see the two buses as a single installation, which should help a lot with assigning non-conflicting addresses.

4 Likes
11

socat

(and now related netcat, ncat, nc etc)
:open_mouth:
How did I not know about this?
That is fantastic. Thanks very much!