Moving units across different networks

We recently designed and successfully implemented a C-bus system across a reasonably large residential site, using multiple networks. We placed a network bridge (and associated switches and dimmers) on each of three floors and put the PCI and CTC2 on the backbone connecting these three bridges, along with any other hardware that would be controlled from keys on any of the floors so that these more "global" messages only needed to "hop" no more than one bridge.
Although we probably didn't need to use this many bridges, it cerainly taught us a thing or two about solid multi-network design. Anyway, the job works like a charm. Infact, it works so well that the owner has now asked for yet another CTC2 to be placed in the lower ground floor home cinema and for it to be configured in precisely the same way as the existing unit. Here's the rub... We initially designed around one CTC2 to be placed on the backbone and each floor daisy chained from its network bridge. To place now, one more touch screen on the lower ground floor would mean that we need to bring all the lower ground floor network onto the "backbone" so that the newer touch screen can continue to successfully control all the loads across all the floors (i.e. only one bridge "hop" required). Ok, re-wiring this at the board doesn't pose too much difficulty. The difficulty lies in re-addressing the existing units assigned to the lower ground network address, as there are a significant number of these.

Hence, my question....
Is there any way we can easily change a unit's network address, instead of deleting it from one and adding it again to the other network?

PS
I'm aware that network bridges can be configured to pass through messages to the adjacent and one other remote network. In our instance, there a too many instances of commands destined for loads spread across the three floors that placing the CTC2 on the lower ground floor network and then configuring the bridge for one specific remote network only will likely compromise it's controlling ability and cause much frustration for the owner and ultimately..us.

As we have to deliver this tomorrow, I know I've left it rather late and will have to do it in the manner just described... Damn..!!

 

grasshopper.
I been asking for this for years, it a simple piece of code,
so I have written my own macro to do just, only works on 2 networks at mom.
If any good lets know, also be careful with the bugs in Toolkit,
We have spent days trying to get shutters working on DLTs but Toolkit screws up the saves.

dave

 

Have you checked all alternatives solutions in cabling?
In a similar situation I was too lucky to have a spare UTP 4" in the telephone/data distribution cabinet that I used as C-Bus cable and saved my wonderful back.

Also, I was always wondering what will happens if someone uses the two spare pairs of C-bus cable for a second C-Bus network

 

Thanks Dave and 2SC...

Trust me 2SC, if there was any way of using spare pairs or additional spare conductors then that would be our first and only choice. Using the brown and green pairs in the CBus cable is something I'm not preferring, as this too is frought with difficulty in this situation, not to mention the compromise of foregoing the manual override (which is kind of a nice feature that I'd like to keep up my sleeve at this point in time).

Dave, your sugestion seems quite palattable. I take it you're altering the XML tage file, in comma delimitted spreadsheet format, no?

 

Dave, your sugestion seems quite palattable. I take it you're altering the XML tage file, in comma delimitted spreadsheet format, no?

Yes and No
Yes I change the Tag file with lots and lots of checks and balances included, then reload in Toolkit, be careful of Toolkit bug that's says it "Refresh" is dose NOT reread the file so changes not show up till you restart it.
Its only in spreadsheet because I have lots of things that make and use spreadsheets so was easy to add there.

dave

 

Many thanks for pointing me in the right direction, Dave...

I have since opened the tag file with a non evasive editor such as Visual Web Studio, and have re-positioned the desired units in the appropriate <network>...<\network> section. I then saved the .xml trag file and transferred it to the C-Gate\tag folder. After starting up Toolkit, I then backed up the database, so that next time I open today's backup (on-site tomorrow), prior to doing a network scan after we've re-wired the network accordingly, everything should be good.

I hope that's right. If so, you've just saved me at least two hours in deleting and then re-adding units to the different network. Thank you again.

 

I guess that you have already finished working on this site now, but I was wondering why you need to re-structure your networks at all.

The Touch Screens can all send and receive messages across any number of C-Bus bridges. In principle, a touch screen can be placed on any network and will work fine provided that:
1. You set its network correctly in the project details
2. All necessary messages will be seen by the touch screen

Point 2 is possibly the sticking point, but will generally require no more than setting the option in one bridge to forward messages to the touch screen's network.

 

This is definitely best avoided for many reasons:
1. You will get some cross-coupling and interference between the two C-Bus networks
2. You will not be able to use the local overrides
3. Is someone else does any work on the site, they will not know about the unusual wiring and this will cause all sorts of problems
4. Your warranty may be affected

 

Thanks Darren.

So are you saying that unlike network bridges, that can only transmit messages to the adjacent and one other network, the touch screens transmit to every other network, across every network bridge, regardless of the physical setting in each bridge?

Also, while on the subject of this project, after altering the .XML file as described above, I noticed that the DLT labels retained in Toolkit for the units now moved across into the backbone network, were no longer there. I tried scanning the new backbone network and writing to the database in Toolkit, with no improvement. The funny thing is that the physical DLT label descriptions on each of these network parameter modified switches was unnaffected. I just don't seem to have the same information in Toolkit. Could you possibly shed some light on that one (pardon the pun)?

 

DLT Labels are properties of the Groups that they are associated with, not properties of physical units. Since the labels only apply to a specific group on a specific network, moving a unit to another C-Bus network doesn't move the label to the new network.

The labels that were in the DLT will remain there until something else comes along and changes them. If you've got the default labels in your Toolkit project then no new label messages will be sent to the unit when you download the programming, so the text or icons that were in there previously just get left alone. If you make a change to a label, the new label will get stored in the unit.

 

That's why I keep the DLT text the same in all the networks, its a shame Toolkit does not take the DTL text from a network and add to the other when "Copying Tags"

Also watch the group name descriptions ie "Bed1" as the C-Touch will use the names in its logic code so if they different on the networks and you move a C-Touch the logic
not compile.


dave