Help me understand Network Addresses please...

Hi all,

Past 2 weeks I was working on a big project, with 2 Cbus Networks spread out over a pretty large area. The site is so large that it's very much easier to connect to Cbus in various places to work on it. The Network Bridge set up NOT to pass messages, as interaction between the 2 Networks is handled via a B&W Ctouch which is connected to Network 254.

It appears to me that Network Addresses are "automagically" set somehow in Toolkit, and I had all manner of problems...

Connecting to Net 254 I can scan and see the Far Side of the bridge as Network 253. That's OK, and everything is as expected.

But physically connecting Toolkit to Network 253 makes "THAT ONE" appear to be the local Network. Therefore, what was 253 then becomes 254 - and the other one (original master network) then becomes 253.

This confuses the hell out of Toolkit, which seems to completely screw up the Tag Names. What happened was that I ended up with duplicated TagNames on Both Networks - I assume the ones I set up on Network 254 got copied across to the 2nd Network after I connected directly to it and did a Scan.

The Network Address is critical when using a Ctouch, PAC or Homegate - as these units communicate to remote networks using a specific "Network Address". What happened next to me (after connecting to 2nd Network) was that the Network Addresses got reversed. And that meant that the Ctouch wouldn't issue commands properly (eg: Group 10 on Network 253 is a completely different thing to Group 10 on Network 253 ) !

It's very hard to explain, and I've finally fixed it (to a degree) - but basically it seems that Network Addresses are assigned based on the context of where you connect to the Network. And you have almost NO control over them... ?

This is the first and only site that I've worked on with Multiple Networks... and I didn't set it up initially. But the behaviour I attempted to describe above made this an absolute nightmare to work on. My final solution was to tap off a Cat5 from one side of the Bridge and run a trailing cable around to the 2nd Network - obviously not a very neat or practical solution
- But that was the only way I could find to work on BOTH networks without screwing up the Network Addresses !

• Is all this stuff by design ?
• Have I done something wrong, which is causing this behaviour?
• Is there a way to "lock" the Network Addresses, so that Network 253 STAYS as Network 253 ?
• How is the Network Address stored - In all Units, or only in the Bridges?
• Can you manually assign a Network Address?
• Is there a clear Networks For Dummies tutorial somewhere?

Help please !

Thanks, John

 

Hmmm

You should not have changed the network that the toolkit connection was made to. Toolkit can navigate through bridges to program, inspect, monitor, etc. units "on the other side". The only thing you might have gained by changing the connection point was a faster network scan.

Network addresses in C-Bus are determined by the address given to the side of each bridge (or gateway, in the case of a wireless network) opposite to each network. The local network is a special case.

In your case, with 2 networks, near being 254 and far being 253 would require you to "see" your bridge with an address of 253. When you connect to the other network, you should "see" the bridge with a different address.. and this will not agree with your database from the other side. If you change the bridge address on either side, you will be changing the network addresses, and invite troubles.

I believe that toolkit keeps a map of the network topology as viewed from a specified point in order to route messages through to the correct final destinations. Changing the toolkit connect point without updating the topology map would be the source of your troubles.

programming of C-touch and other sophisticated units with network capabilities should not be affected by the network you connect to with toolkit

Don

 

Thanks for the confirmation, Don.

The difficuly I have is that the site in question doesn't have an "active" database... I am still building one up to reflect the realities on-site. So, I am reverse-engineering" the site.

For example, the only way of determining which unit a Key Input is... Put toolkit in "Application Log" mode, then press a button on that keypad. Then see what load (if any) is connected to that key. Then update the database with respective Unit Names and Group Addresses, and separate list in Excel of what Output controls what load.

Next I have to toggle each Group in every Output Unit, and see what lights come on - that allows me to determine what does what on the site ! Then try and find each Output Unit by cross-referencing Serial No with the Database, then label it.... an absolutely horrid job when there are some 300 devices and even more Groups !

The difficulty therefore is that connecting to Network 254 only allows me to (physically) see half the site. To check Units on the "far" network 253 means walking a considerable distance each time. Since the site is "live" there are all manner of other events happening on the network as I do this - so being physically close to Toolkit means I can capture a individual keypress quickly and accurately.

LESSON TO ALL... Use meaningful Unit Names ! "LC1.62D" might mean something to you when you initially commission, but is absolutely NO use for then next person that comes along! And even you will forget if you make no list of what that code means!

Also, wouldn't it be great for the future Cbus3 to store TagNames in the devices, rather than just a Hex Address! Take it from me that working on a big site where nobody has a Tag File is dreadful ! Please please give your clients the Tag Files, it really doesn't help anyone if you keep the Database to yourself!

Would someone please confirm if this is correct, and how to do it. If we had control over how Toolkit viewed the Topology then it would be easy to access the network from any point.

Thanks, John

 

John,

What Don said is correct.. at some point we'd like to introduce the ability to plug directly into Networks temporarily.. at this point, you cant do that.

 

OK, thanks Duncan

So at least I know now that's it's not me that screwed things up !

I still have some work on that project, but at least I have been able to get it operational... in other words I have re-programmed it so at least they can switch every light on and off (which they couldn't previously do, as about 30% of lights didn't work for 1 reason or another)

Cheers, John