Network Comms

I am not clear about the following:
I set up a bridge on a 2-Network installation to allow communications across 'All Applications'.
I then set up a GA on each network on the Lighting application to have the same tag (e.g. Bedroom) and the same group address (e.g. 233 (E9)). Note that the output unit for that group only exists in the remote network.
I start Toolkit and open both networks.
If I open the groups node on the remote network and toggle the group ON and OFF, it all works fine.

If I go to the local network and toggle the group ON or OFF, the output on the remote network does not respond.
HOWEVER, checking the application logs, the groups show as being toggled ON and OFF on both networks .

This does not seem to make much sense, so I must be missing something. Can anyone point me in the right direction?

Thanks
Thomas

 

Toolkit sits on top of C-Gate which is the comms server for this app and others like Schedule Plus / Homegate etc. C-Gate builds a comprehensive model of the networks it is connected to, this includes network topology for message routing. When you do the following

you are actually routing a message for that group address to the remote network and the remote network only.

In this case the message is being routed to the local network only.

C-Bus input units are lower order units and do not route messages. If you have set up connect applications properly when you use the key input on one network it will transmit a message to the network it exists on. That message will be routed across the bridge and control / interact with other units on the other network with the same GA. Once a message has been routed across a bridge it will not be routed again otherwise messages will bounce back and forward. Hope I am not confusing you.

Try it with a key input...

 

Hi Phil,

This is clear enough, but doesn't quite answer the last part of my question yet.
Based on what you say, I would expect that when I send the command via Toolkit, i.e. C-Gate to the Local Network, then it should not arrive at the Remote Network. However, the Application Log shows that it does
Further, if it arrives at that network, then it also should switch on the GA.

Is there an explanation for that?

 

Hi Phil, or perhaps Darren,

Do you have an explanation about why the command actually arrives at the remote network, but does not have an effect?

 

OK. Is it possible that because you have toggled the GA via the groups node on both networks that the application log shows both those actions ? When you mentioned "the groups show as being toggled ON and OFF on both networks" are you suggesting a single action on either network is showing up in the appplication log for both networks eg identical time ???

 

Thanks for your reply Phil,

This is exactly what happens. Just confirmed now as follows:

open Toolkit, both networks.
verify that both App Logs are empty
Toggle GA ON on Local Network
Check on App Log Local to confirm - Positive
Check App Log Remote - there I see the same action, but no effect on the Network

Phil, in my opinion, this is how it should be, as comms have been opened up in the bridge. But I don't understand that the actual Output does not comply???

 

My understanding is, if you are selecting a particular network (in Toolkit) and controlling a GA on that network then due to the involvement of C-Gate the message should terminate in the network it is directed to. Previously (recently) I found a problem with Toolkit triggering certain messages on the bus. The situation you have described should (will) be looked at by the boys in the brains trust

PS C-Bus Embedded devices and C-Gate based software can route messages across a bridge if it is set to connect applications or not. - Not directly relevant here but an interseting point none the less...

 

Hi Phil,

Thanks once again. From your reply I assume that you are connected to the brain trust. Can you say that they are aware of the query, or would there be someone who I could contact directly?

 

I am not part of the brains trust. The brains bit lets me down

I might have a chance tomorrow to set up the arrangement you have mentioned and give it a whirl, if not I will call a friend who has the brains bit covered and see what I can find out.

 

The only Load Change messages that are allowed to cross over a bridge connection are those that have no Network Routing information.. This stops circular routing of messages. We call these Load Change messages "SAL Messages"

Key Units, when keys are pressed, generate SAL messages with no Network Routing Information

When Toolkit (via CGate) is used to control a group on the Local Network the presence or absence of Network Routing Information on the SAL messages that CGate generates is determined by something called the "Local SAL" mode of the PCI/CNI. By default, ALL messages coming into a Network via a PCI contain routing information.. Local SAL mode strips this information out so that those incoming messages can transit bridges if required.

If the Group on the Remote Network is NOT going ON when you trigger the Group on your Local Network then there is 2 possible explanations.

1. Your PCI is not in Local SAL Mode. CGate should be putting PCI's into Local SAL mode as a matter of course (it does, I've checked).

2. You have an old PCI. Only PCI's with a firmware version greater than 3.12 have Local SAL mode. If CGate is sending SAL messages to a Local Network WITH a <3.12 PCI then the messages will never get out of that Network as they will have routing information on them.

If you have a >v3.12 PCI eg a 4.4 PCI then you should repeat this test.. if that fails, we need to dig a little deeper..

Hope this helps..

 

Local SAL mode and its impact are discussed in http://www2.clipsal.com/cis/cis/__data/page/4129/C-Bus-Networks.pdf

 

I havent drilled into this part of the issue yet..

 

Thomas,

I told you I have friends in the brains trust. It would be good if you can confirm the PCI details mentioned in Duncan's post. There might still be an issue with application log saying one thing and equipment doing something else.

There is a really good document floating around covering networks / networking / messages etc. It specifically covers SAL / local SAL. I will try to dig it up.

 

A couple of posts back Darren had posted the link to the doc I referred to. I dug around the CIS website but could not find the doc. I don't have a PhD in Forensic Computing

 

Thank You!

Hi Phil, Duncan, Darren,

I was surprised to see a heap of responses so soon. Thanks Phil, for waking up your friends, and we know they are clever ones..
Now to Duncan's PCI matter. I have two. One is an old one, installed permanently on the network here, and one which travels with me. Naturally I used the local one, and had no success. I swopped over the the DIN one, and now the messages have the desired effect.
I will also study the Networks doc which Darren has provided the link for, and hopefully get a little more clever when I am finished with it.
As I have reached an age at which I am no longer in possession of the full complement of hair on the head, I might not remember at all times to first check out a new PCI when something doesn't work, but I will try to...

In summary then it would appear that the messages will follow the paths opened by the configuration of the bridge, and will be useful (or confusing, depending on what is to be achieved) on the relevant connected networks.

Thank you all for your assistance!
Thomas

 

CGate has interrogated the bridge configuration and based on that configuration it has determined that a Group Change on the Local Network must result in a Group Change on the Remote Network thus its automatically generated a Load Change Event so that clients connected to it have the correct view of the network..

Alas.. it hasnt appreciated that an old PCI is being used and the message hasnt actually got to the Remote Network.. Its a deficiency in C-Gate.. I've logged it for attention when time permits.