Setting C-Bus Date and Time from C-Gate with a PAC Present

I'm having a problem whereby the date and time on DLTs is being set from the PAC's clock which drifts slower over several weeks. In an attempt to correct this I have a PC running C-Gate full-time and have configured it to broadcast the time periodically as a time master by changing settings in the config file but the PAC doesn't seem to want to receive date and time updates and basically ignores the correct time from C-Gate on the PC.

What do I need to do to configure the PAC and C-Gate so C-Gate is the time master and the PAC is not?

Currently I connect to the PAC with PICED, and set the time manually to set the PAC and all the DLTs to the correct time.

Yes Clock messages are being sent from the PC onto C-Bus and the above is what I have had configured for months - years even.

In desperation I recently commented out the last line and restarted C-Gate and things have suddenly started working much better.

Code:

# clock.update-interval=30

So either there is a problem with setting clock.update-interval or it causes some other bug to manifest or the default is NOT 30 and commenting it out actually changes the clock.update-interval value to another value that works with the PAC Clock primary/secondary logic.

I get a daily indication of the difference between the clocks as my blinds open via the PAC Schedule at 7:00AM and my Alarm on my iPhone is set for 7:00 AM and they are now only a few seconds apart. Previously they could drift to be 5 or more minutes apart over the period of 1-2 months.

So for now I think I'm running ok again but I think there is a bug or something deeper going on here than meets the eye.

The PAC will accept time keeping messages and stop sending them.
Here are the rules for which unit becomes the time master:

A brief description of the operation of the time arbitration follows :

1. Most C-Bus units which use the time have the ability to broadcast the time with a regular period.
2. At any given time, only the Time Master broadcasts the time.
3. C-Bus units which are more likely to have the accurate time broadcast the time more often. This period is 60 minutes for HomeGate, Schedule Plus and Colour C-Touch, 90 minutes for Black and White C-Touch and 120 minutes for the PAC.
4. Units which broadcast the time more often take over the role of Time Master from the slower units.
5. Units with equal broadcast periods will be randomly selected to be the Time Master.
6. If a unit is not the Time Master and sees that there has not been a time message for a considerable period, it will take over the role of Time Master.
7. If a unit is the Time Master and it sees a time message from another unit, it will let that unit become the Time Master.

Click to expand...

In the past I have seen circumstances where clocks jump around, this was a symptom of network comms problems. One way to verify that all units are communicating happily is to use the 'reliability test' feature in the C-Bus Diagnostics Utility available from the cis downloads page. This utility will also show you which unit is broadcasting time messages and will indicate whether C-Gate is/isn't sending messages when its expected to.

The PAC will accept time keeping messages and stop sending them.
Here are the rules for which unit becomes the time master:

Click to expand...

Ok, yes that was what I was expecting

Matty said:

In the past I have seen circumstances where clocks jump around, this was a symptom of network comms problems. One way to verify that all units are communicating happily is to use the 'reliability test' feature in the C-Bus Diagnostics Utility available from the cis downloads page. This utility will also show you which unit is broadcasting time messages and will indicate whether C-Gate is/isn't sending messages when its expected to.

Click to expand...

Ah huh! I'll take a look at that and see if I can track down the issue.

In desperation I recently commented out the last line and restarted C-Gate and things have suddenly started working much better.

Code:

# clock.update-interval=30

So either there is a problem with setting clock.update-interval or it causes some other bug to manifest or the default is NOT 30 and commenting it out actually changes the clock.update-interval value to another value that works with the PAC Clock primary/secondary logic.

Click to expand...

Out of interest what version of C-Gate are you using?

Your config options look correct.

I checked the C-Gate code and the built-in default is indeed 30 minutes. You can check this by deleting the entire config file, C-Gate will recreate it on startup with this value. Commenting out this line in the config file therefore should not have made any difference.

One thing worth mentioning is that these are 'network' scope config options, which means C-Gate will copy them into your project tag file. So even if you are tinkering with the global config options there may be values inside your project file that are overriding them. You can open the .xml file in a text editor to check this.

The C-Gate clock application code hasn't changed in many years, and goes something like this (where [30] is the value of clock.update-interval):

If clock.master=yes, C-Gate will emit regular time updates.

If mastermode=primary it will emit the first update [PCI address] seconds after startup, and then every [30] minutes after that. If it sees a time update from the network, it will reset its internal counter to wait another [30] minutes before it emits another update.

If mastermode=secondary it will emit the first update about [2 * 30] minutes after startup, and then every [30] minutes after that. If it sees a time update from the network, it will reset its internal counter to wait another [2 * 30] minutes before it emits another update.

In all this C-Gate does not actually change the PC time, it uses an offset to keep track of the network time wrt the PC time, and emits updates based on that offset. You can find out this value with the C-Gate command "get 254/223 Offset".

NB: You can track all this in a level 9 log as C-Gate should emit a level 8 event message that begins with "[clock] date XXXXX" or "[clock] time XXXXX" whenever it receives a time update from the network, and a message beginning with "Setting date and time (master mode)" when it emits an update.

To put all this together using the rules Matty describes, the physical units on the network and even the HG/S+ software should quickly begin to defer to a C-Gate configured as the primary time master as it is emitting updates more frequently than any of them.

So as for why it suddenly started working after C-Gate was restarted, I have no answer to this. Which is why I posted the above in case it may help you work it out.

Welcome to the C-Bus Forums!

Welcome to the C-Bus Forums, for help and advice with Clipsal/Schneider C-Bus devices. From time to time you will see Clipsal staff on the forums, but this is not an official support channel.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about your C-Bus products or chat with the community and help others.
Ask a Question