2 Way Comms with CNI's

Curious to know if anyone has attempted 2 way comms with a NAC/SHAC and CNI's.

Its easy enough to send TCP commands TO a CNI with an event script.
Its also not too difficult to receive and filter commands FROM a CNI with a script.

Given the CNI only handles one TCP connection, the next step would be to work on a bi-directional script, but was wondering if anyone has had a go at it already?

 

Not quite sure what you're trying to do here. Given the SHAC is already connected to Cbus, what are you trying to accomplish?

 

The application is more for Large Project's with Multiple C-Bus networks. Essentially have a NAC / SHAC replace a schedule plus headend and make use of the existing CNI’s

 

You are heading down a rabbit hole there.

I have written my own windows application that supports multiple PCI's and models all the networks as a single large network. It was a major undertaking using a serious programming language and took a couple of years to complete (actually I'm still going!). Doing that in Lua in an SHAC would be impossible. As I discovered, it's not something you can half do. If you really want the SHAC to control multiple networks, you will have to replace the PCI's with bridges off the main network.

 

haha yeah i figured as much,

i have a test setup with 2 c-bus networks at the moment. One is a test rig with a SHAC and a few devices, the other is my home network with a CNI. Both connected via Ethernet.

Using one TCP script to receive, I’m able to connect to the CNI and map all the messages to groups/applications and objects within the SHAC

Using another event based TCP script, I’m able to connect to the CNI and fire off commands.

Now to nut out an approach to combine the two to send and receive. Has anyone created any bi-directional tcp scripts? Maybe splitting out some functions / user libraries may be the way to go?

 

I think ive got there with an event script and resident script

 

Success, i have 2 way comms working, I can send and receive apps/groups/levels bi-directionally.
Just handling lighting commands for the moment, need to expand the data parsing and stress test, but so far im happy to have the shac acting as a headend and GUI for the 2 networks, one local and one remote CNI. I'd like to test connecting to a few more CNI's as well, replicating a larger c-bus Ethernet backbone setup more common on commercial projects.

Is there any particular reason the new firmware’s have limited the object addressing structure?

I have a NAC on firmware 1.13 and can no longer add networks or applications outside the typical c-bus range.
In firmware version 1.6 the object ranges were less restricted, much like the KNX device its based on.

Funnily enough, its possible to restore a project with ranges outside the norm to regain them.

Only ask as currently im offsetting my network applications by the main group of the KNX object structure.
By default the local network groups are objects 0/xxx/xxx (0/56/0) etc. and im currently mapping the CNI address to objects 1/xxx/xxx (1/56/0) etc. on the SHAC.

I’ve used these ranges in the past for other dummy groups like widgets, time, date etc. with no issue so curious as to why they have now been restricted.

Wonder if maybe Schneider have or had plans to implement a c-bus Ethernet protocol much like KNXnet/IP and Dynalite over Ethernet. I’m a little surprised they haven’t done so already actually, it would make life a lot easier on large projects if the NAC's could communicate over Ethernet with each other.

 

Thanks Colin,

Is it possible to call the existing c-bus bus decode functions at all?

As the NAC / SHAC are already decoding the cbus messages on the local network it would be a great benefit to leverage them to parse the CNI commands.

They would likely be much more efficient than anything I come up with as well.

Is there any documentation available you could pass on for the API as well?

 

I also have some experience in playing around with this API (getting the NAC to create objects on itself), so i will be able to field some questions on it

 

I've just been revisting this again over the christmas break.

The Initial idea was raised as we work on a lot of large commercial installations running schedule plus and a number of CNI networks over an ethernet backbone. Its probably not too applicable to a residential installation unless you have a situation where its dificult to get a c-bus cable between 2 buildings ( main house / outhouse or detached garage ) but you can get wifi or have an ethernet connection there.

Most sites these days wish to do away with maintaining schedule plus and a dedicated lighting control PC and the Automation controller is a reliable replacement, however this means either changing all the CNI's to Automation controllers and using a BACnet device as a central platform to control all the networks or replacing all the CNI's with Bridges and wiring a c-bus backbone so the Automation controller can communicate to all networks.

Are there any plans to enable native communication like c-bus over ethernet between Automation controllers? This would allow the CNI's to be replaced with Automation controllers.

The KNX logic Machine currently does this using KNX netIP and multicast. The advantage is you can distribute the network over a commercial buildings central ethernet network, and choose one controller to host all master schedules and logic as well as the interface for control of the entire system, and if needed you can also offload local schedules and logic to the local controllers,

Ive currently got 2 way lighitng application comms working between one c-bus network with an Application Controller and another c-bus network with a CNI. Im in the process of adding support for a 3rd c-bus network with another CNI and more with the goal to have the application controller able to replace schedule plus without the need to remove the CNI's.

 

An update to this: I currently have 3 individual C-Bus networks connected via Ethernet as the backbone.
C-Bus Network 1 and C-Bus Network 2 use CNI's (5500CN2's), and the 3rd has an AC controller and acts as the headend.
The AC controller can send and receive lighting messages and stores the values as objects mapped to different applications. I can create a scene on the AC, and it sends messages to all 3 networks. I can also send messages between the 2 CNI networks, using the AC as the middle man. A switch on CNI network 1 can turn a light on/off on CNI network 2 and vice versa.

How do the C-Bus objects on the AC work in regards to networks? Ideally, I'd like to map each CNI network with a network value rather than mapping to applications. However, I've noticed while using the same application with different network addresses on the AC (e.g. 0/56/1, 1/56/1, 2/56/1, even 253/56/1) that if I send a message to one object, all objects on the AC with the same application will update to the same value. Is this the expect behaviour? I was expecting these to operate in isolation of one another on the AC.