Thanks Newman for your previous response - most helpful! Further to my understanding of the PCI and CNI interfaces 1. Is it possible to send SAL commands/responses in a "True broadcast mode" through all network bridges without the need to know what the bridge network addresses are? is this possible using the \03....... header command or some other command header? 2. It seems that the bridges themselves can be set up to relay messages from one cbus network to another - but this method I assume will cause all network messages to be sent over all bridges and thus cause heavy and unnecessary trafic -- what I want is to be able to do a "true broadcast" over all network bridges fom just one device without the need to know (or send ) the specific bridge addresses for making up the broadcast message? 3. Maybe there is a "special bridge address" or command that can be sent to activate all bridges to simply relay that particular message on to its adjacent network? 4. Can the CNI be used with multiple ports -- eg Can one open up several telnet connections into the same CNI interface and connect to the C-Bus network -- it appears that the CNI has two serial ports to do this? 5. It appears that the PCI/CNI interfaces are not meant to be used in so-called basic mode - and the docs are somewhat confusing in descriptions. Such as one needs to "connect" in basic mode or it doesn't onterface to cbus - while on the otherhand th edoc says not to use connect in basic mode? 6. One feature I like about Basic mode which doesn't seem possible in smart mode is that SAL responses via bridges are simple in that you get the last bridge address and the number of bridges - thus saving a number of bytes in the very limited 21 byte PCI/CNI buffers?
No. The best you can do is have the bridges forward the messages for you (see below). The bridges can be set to forward messages for one C-Bus Application, two C-Bus Applications or all C-Bus Applications. No. A CNI can only have one client. It would not be possible for the PCI within the CNI to deal with two clients, as it would not know which client to send C-Bus replies to. Just use the recommended default mode and it will all work nicely. Some of the modes of operation are there for historical reasons.
SAL commands can be sent only to the local network or to a specific network. What you want to do can be achieved by configuring bridges to relay messages and putting your CNI into 'local SAL' mode. Limited filtering is available on bridges to reduce network traffic. Traffic from one, two or all applications can be relayed. This is easy to configure on each side of the bridge. No, there isn't. The main difference between 'basic' mode and other modes of C-Bus PC Interfaces and CNIs is that basic mode echoes characters back as they are received. Basic mode is great to get things working, but it's best to turn this off once you know what you are doing to reduce traffic returning to your controller. The 'connect' in C-Bus is a means of monitoring SAL activity on a network. No 'connect' needs to be set up to issue messages to a network, but it is required if you want to view activity of one or more applications.The echoed characters in 'basic mode' can become interspersed between characters of monitored messages and therefore can confuse interpretation. While 'basic' mode returns fewer characters, it does so only because some characters of the original message are stripped off. The network still has the same limitation, so 'basic' mode won't allow you to do anything more.
To add a little more... Bridges will forward messages as they are programmed to. There is no specific "broadcast to everything on every network" command but you may be able to achieve the same result using careful network bridge configuration and network topology. The second serial port is a physically un-connected port on the ethernet module inside the CNI. The CNI can only support 1 client at any given time. The PCI has a range of different options that determine how you see the messages from it. Some combinations of these messages make more sense than others. If all you want to do is turn on and off lighting groups then basic mode may be all you need, but learning the options and setting them appropriately is really essential when going beyond the basics. The idea of turning on or off features in the PCI to "squeeze a few more bytes in" is flawed because changes to most of these options don't actually affect the final command that winds up on the bus. They do affect how you talk to the PCI however, so that you can tailor the interface to give you the specific information you're interested in.
PCI/CNI & BRIDGE Configurations Thanks again for your feedback I am only very new to cbus applications appreciate the help! 1. Darren, Don & others have suggested that the bridges can be configured to relay Local SAL messages to other networks - but I find that not all applications are supported ? It appears you cannot configue any application number - you can only select from a list and that list is limited - for example the measurement application number E4 (228) is not supported. - So while this method of routing messages seems ideal - it does not seem to support all applications is there a way around this? 2. Maybe this is limited by the C-gate inteface that toolkit uses? 3. Other's have noted that the CNI can have only one client - noted and acepted - thank you. Is there a way to have several clients or applications talk to cbus network using the same PCI command set? The Only package that appears to be able to support multi-client applications with a sinlge PCI interface is the Clipsal C-Gate driver -- But this driver doesn't sem to support sending and recieving raw PCI commands? It only accepts commands that support its java based methods and these methods do not seem to support sending/recieving raw PCI command strings - which is a shame! 4. Further to 3 above. Does the Clipsal CBUS.DLL windows driver support multi-client access? For example if a PC is operating Clipsal's HomeGate Sofware using the CBUS.DLL driver - can another application running on the same PC use the same driver to access the same PCI interface module? Somethng tells me that the CBUS.DLL driver doesn't really support windows and NET based multi-threading applications - has anyone had any experience with this? 5. As a slight offnote - I have found that the Toolkit software has a lot of difficulty in communications where I quite often need to retry or re-start the application because the comms (or c-gate) hangs up? - Is this a common occurence with toolkit - I have only a relatively small test setup with a couple of bridges, 2 PCI's, 4 Relay modules, CNI and and some Keyswiches. many thanks for the support?
You can configure the bridge to send 1 specific application, 2 specific applications, or all applications. By setting Application 1 to All Applications, all application data will be transmitted across the bridge. C-Gate can send a message to every network in an installation, so it seems that C-Gate can do everything you want it to. C-Gate supports multiple client connections. Once you start talking to C-Bus using C-Gate you'll probably never go back to using the serial strings directly again. C-Gate provides an abstracted interface with hundreds of very powerful features. It's worth the effort to learn it. C-Bus Toolkit and C-Gate are pretty stable. C-Gate is designed to run 24/7 on server PC's so it's most likely a configuration problem on your PC. If you're having problems communicating with your network it's most likely that the networks themselves are not communicating reliably, which you can use the C-Bus Diagnostic utility to determine.
Cni & pci Thanks Newman Yes, but setting ALL APPLICATIONS will tend to increase trafic - How can I set the bridge to accept a "Single Application" not listed in its menu - such as E4 (228) - if its not listed toolkit will not allow it? Also, I have a test setup with two bridges and when the "ALL APPLICATIONS" relay has been set - I can send SAL Messages form local to middle network and from the last network to the middle network - but NOT from the last to local or local to last networks? I had a look at C-gate but it doesn't have support for a lot of applications - lighting, alarms, security, air-con, etc are fully supported but the general object methods "get and set" do not allow for all applications or future applications and does not allow the capability or flexibility to send "raw PCI strings" to overcome the applications that it doesn't support? The multi-client capability is a great advantage and I would love to use it, but C-gate doesn't seem to support new applications or data stuctures. I may me missing something with C-gate, but the get / set methods are restricted only to objects supported in c-gate and conforms strictly to application requirements. If the oblect is not supported then the general format of the get and set methods are very limited - they don't allow setting/recieving raw string responses as with simple PCI ? Does the cbm.dll windows driver support multi-application access running under windows multi-threaded operating systems or NET applications? Many thanks again
It looks like there might actually be an issue there with Toolkit, not allowing the Measurement Application to be visible, even after adding a unit that used that application to the network. I'll check it out further. See other thread. Raw PCI strings are not allowed because you may inadvertently change the mode of the PCI under C-Gate's feet, which would break lots of things. There is a user-definable range of application addresses where you can do what you want and C-Gate supports standard lighting commands in those applications. When new applications are defined and made available, C-Gate is always updated to support them. The C-Bus Module supports all public applications and can run on a whole variety of applications. Suggest you visit www.cbus-enabled.com for more information.
