First time poster...need help!

Hi All,

Never posted on here before but I've got a problem on a project and am hoping someone here can give me a few ideas. Sorry if I have posted this in the wrong section.

I am using a network bridge for he first time. I have 2 wired Cbus networks connected via the bridge. Both networks have burdens and clocks enabled. Network A has around 85 units and network B has around 60 units. I have no more than 6v voltage drop across either network. The bridge is set to broadcast group address changes to both sides of the network.

I have a C-Touch connected to network A.

I have CNI connected to network A which is being used by a third party device for integration.

I have a DLT on network B triggering a scene switching on 10 group addresses. The scene is stored on the DLT. All 10 of the group addresses are assgned to output units on network B.

The problem I am having is when the scene is triggered I am only receiving group address status updates for 3 out of the 10 groups on my thrid party device through the CNI. I'm sure its not the third party device because when I monitor the bus on the CNI I only see 3 out of the 10 groups.
All other units on both networks receive the group status changes OK.

If I move the CNI to network B and disconnect network A I get the status changes of All 10 groups. So I dont think my CNI is dodgy.

I have taken various troubleshooting steps including adding and removing software and hardware burdens. Storing the scene on the C-Touch on the same network as the CNI (When I did this I still had the same problem but got staus changes from a different 3 of the 10 groups).

Other than this problem my 2 networks are runnig well and are stable.

Sorry it was so long winded just trying to paint the picture.

Any help would be much appreciated.

Cheers,

Dom.

 

That's definitely a "head scratcher".

The first thing to do is to independently inspect where the messages are coming from.

I would download yourself a copy of the C-Bus Diagnostic utility and grab a spare PC Interface for checking things out. Connect up the PCI and open Diagnostic Utility on Network B. Press the Scene key and make sure that you're seeing all the groups come out of the DLT, along with the Scene Trigger (if you have one).

Move the PC Interface over to Network A and press the scene key again. Look at the message window closely. If you see all 10 groups, and the source address is shown as Network B, and the Source unit is the address of your DLT on Network B, then you know that your bridge is correctly configured and your networks are working reliably.

Check your programming in your Network Bridge and make sure it's forwarding the correct Application Addresses. If you're just treating the two networks like one big network then All Applications will be fine. If not, then you'll need to make sure that at least your Lighting Application (typically 56) is being forwarded. You'll also need to forward the Trigger Control application if you want to remotely trigger the Scene from some other device. Don't forget that each side of the bridge is configured independently.

Since both the C-Touch and the CNI are sitting on Network A I would also suggest you create a diagnostic page on your C-Touch, where you put 10 buttons, one for each of the groups. After you press the DLT button, take a look at this page. This is useful because it is on the same network as the CNI and therefore will see the same messages. It will tell you if the C-Touch is seeing all the group messages. If it is, the problem lies in either the CNI or your 3rd party product. If the C-Touch doesn't see all 10 groups, then the problem is a network or bridge problem.

 

Not sure how much help this will be since its been a long time since I have used a scene within switch (having our own 3rd party app to handle that stuff)..... but....

From memory (and happy to be corrected on this one). When you send a scene out from a DLT, it transmits the scene group address but not necessarily the devices themselves. And by that I mean of course it sends the message, but in cbus there are different levels of messaging. Some that the relays and dimmers see and some that a PC interface will see.

So it is possible to have lights turn on/off without a status update bring broadcast.

This can be further confused when talking over networks depending on how you have your bridges set. For example your third part app may be able to see the messages, and send out messages to the switches, but the switches may not be able to see each others messages (resulting in two switches set to the same address not syncing).

To try and resolve your issue I would suggest.

1. Find out which mode the third part app is putting the PC Interface into. Some modes ("smart" mode) allow more information to come back.
2. Run toolkit and use the application log. If it doesn't show in there, then there is a good chance that the 3rd party app will not see it either since toolkit should reset the PCI to a smart mode anyway.

Bear in mind the application log only shows you whats happening (I think) on the network your currently hooked to. So this might tell you if the bridge is passing the messages properly.

Without knowing what your 3rd party app does its a bit hard to tell, but if it has scene running capabilities, then maybe use the DLT as a trigger and get the app to run the scene.

 

Day-to-day commands on C-Bus do not use Device Addresses. C-Bus communicates using Group Addresses which are global network variables. When a C-Bus unit sends a command, it is changing the state of the network variable, not the state of some other specific device. However, any other devices that have an interest in that global variable will see the change and update their states accordingly.

This statement is only true if there are Network Bridges in between the devices interested in the Group Address and there is some message filtering being done in the Bridge. The way C-Bus devices communicate with each other is actually via a broadcast of the new group address state into their network.

Filtering in the network bridges is required for all sorts of reasons. For example, if you have 50 networks in an installation, you don't want to have every message from every unit broadcast into every network. If this were to occur, you would find the bus very quickly overwhelmed by the volume of messages. You would also quite quickly run out of available address space.

It is certainly possible to have two switches on two adjacent networks using the same Group Address, separated by a bridge, and for the switches not to be able to see messages from each other. Message filtering in the Bridge is how this is achieved.

Toolkit application log only shows you the messages that originated on the network you're looking at. If messages have come across a bridge from some other far-flung network, they won't show up in the application log for your local network. You'll need to go and look at the application log for the remote network to see them.

 

Thanks for the replys.

I am certain I have configured the bridge correctly. Both the near and far side of the bridge is set to broadcast groups from all applications to the adjacent network so it will behave as one large network. I have even replaced the bridge.

I will be back there tomorrow and will set up a test page on the Ctouch to display the status of the 10 groups as well as the trigger group.

Thanks for the ideas!

Cheers,

Dom.