network always in error state

Hi,

I am using sockets to connect to c-gate and determine the state of the various groups on my home network which I can't get it to work reliably (no problems on the PC / sockets / application end). I seem to have a problem with an errant group or unit on the network because the C-GATE state spends most of its time in the error state (using the get network state command) and the console repeats this message below every minute.

20081122-150843 827 //HOME/254 3c9b611f-af4d-43e8-92b7-79284f81825c C-Bus Send Error: (%)(retrying)

20081122-170917 843 //HOME/254/56 cc8f0c1c-4942-47cd-b3e9-ecb9ea9ec1b8 Group sync failed

20081122-171141 751 //HOME: null newtag: null

I have checked the toolkit data and it all seems to be in sync between network and DB, but I will get a toolkit failed to open message while the network is an error state and scanning the network.

I also find sometimes that issuing a lights on/off command via sockets will sometimes fail even though C-GATE gives the 200 OK message (and I use the 'force' parameter), but I never have any problems with lights not switching on/off from the physical units. I get the same response with the traffic analyser and toolkit using the on/off group commands where about 50% of the requests won't work (but no error is reported). Using the force command in software does seem to help though.

Traffic analyser shows up the odd error every couple of minutes (eg. 1 per 100 messages when toggling a unit quickly) but apparently that is OK according to the docs.

At the network layer I have about 70 units connected in a large house on 1 network (no bridge) and have followed the C-BUS wiring standards (only 1 hardware burden). I suspect the problem is either the PCI or the logical setup of the network as the physical units work very reliably.

Any ideas?

Regards,
Dean

 

Hmm.

Not sure what is happening here, I left it overnight, ran up the toolkit and scanned the network, checked all voltages with a 'PING', and the sync state of C-Gate is much more stable now.

Now I get this error message every few minutes.
20081123-100931 751 //HOME - Tag information changed at tag address: //HOME/ Installation oldtag: null newtag: null

as well as the error:
20081123-160426 827 //HOME/254 3c9b611f-af4d-43e8-92b7-79284f81825c C-Bus Send Error: (%)(retrying)

What does 'send error: (%)' indicate? And how can i trace this identifier '3c9b611f-af4d-43e8-92b7-79284f81825c' to see what the fault is?

 

Good tip Daniel, thanks for the help.

It turned out I had 3 other units with clock active, so obviously the clocks were interfering with each other. My C-Bus system has been going fine with the units, its only when using the PCI interface that the problems occurred.

Now back to the PCI with the only clock, and all good!

Thanks again!

Regards,
Dean

 

Hi Dean,

You've subtly misunderstood what Daniel said..

Clocks don't interfere with each other.. when the Network starts one clock is "elected" to do the job.. having 3 units with clocks enabled isn't a problem, in fact its a good thing.

As your network currently stands if you unplug your PCI, nothing will work.

 

Duncan,

So I may not have discovered the root of the problem? However I no longer get the send errors in the console and controlling C-BUS via C-GATE is now working reliably, so something must have worked.

From a redundancy perspective, I have 4 locations across the install with relay banks, so should I enable a clock in one of the relays in each location?

Thanks for the info.

Regards,
Dean

 

I'd disagree with you on that statement Duncan, i've seen many sites where having mulitple clocks turned on has been causing network issues. I only ever have one clock enabled in any network, i know that leaves no back up if that one unit fails but from past expirences i've had many more problems with multiple clocks then not having a backup clock.
I know in theory you shouldn't get any problems with having more then one clock on, but in theory and in real life are two different things

 

Thanks guys for the feedback. I'll enable another clock on a relay unit in the same equipment cabinet as the PCI. All my other equipment racks connect back to the main rack via a star network so redundancy should be OK having 2 clocks in the same location (and I do have runs of over 50 metres).