I have both comfort and cbus running their own time systems, but have just upgraded to ETH03, which is a reliable system. I have always had problems with Cbus going random on DST, so would like Cbus to pick up its time from Comfort, or have comfort transmit the time to cbus regularly, rather than having competing systems. Is this possible?
That is a good question!
From my experience C-bus has a random way of handling DST, it seems to move forwards or backwards by one hour on occasions, for no apparent reason. In PICED there is a section set aside for DST handling, but it seems to make no difference.
I have assumed that if I could use Comfort as a time server, all my DST problems would vanish, now that I have an ETH03 module installed.
Interesting... Being in a location that doesn't use DST I can't comment on the random changes but I must confess that I've never picked up anything like that on the Cbus forums.
If you want Comfort to manage time on Cbus then all you have to do is to enable the SNTP setting in the Eth03 configuration and also enable the Timekeeping checkbox on the UCM/Cbus2 interface. Comfort will periodically broadcast the time but there is a limitation. The Cbus time protocol expects the Time Master to send time more regular than itself. With this I mean if a time broadcast is detected it will accept it as a Master only if the broadcasts are repeated more often than it's own internal clock. The limitation comes in where the Eth03 ONLY broadcasts the time if it's out by x seconds and if your Comfort clock is very stable it could be many hours before another broadcast is sent to the bus. If this time exceeds 60 minutes then Cbus reverts back to itself as the master and the cycle start again.
My proposal to Cytech was to periodically send Time Broadcasts to Cbus irrespective if the Eth03 updates the time or not. Unfortunately this creates another problem. For the UCM/Cbus to detect a Time Broadcast it has to be sent on the bus. This then creates a Time Change entry in the log file and fills it up fairly quickly. Bit of a catch-22 situation if you ask me.
Perhaps the UCM/Cbus2 can keep the time running local to the UCM and periodically send it to Cbus so no log entry will be made. This might or might not be possible, only time will tell.
This may go some way towards explaining my problems. I don't have the timekeeping checkbox on my copy (3.11.6). Wont I need to disable DST on C-bus also? Otherwise C-bus will get a DST time from Comfort which it will then apply a correction to in October and April.
I think the issue is that you still have an older Cbus module as opposed to the newer Cbus2 module. NTP doesn't send DST information, it's up to the client to interpret the raw data from NTP into it's own timezone and DST calculations.
I remember somewhere on the forum is a upgrade path mentioned for Cbus to Cbus2.
With this I mean if a time broadcast is detected it will accept it as a Master only if the broadcasts are repeated more often than it's own internal clock.
I dont think this is a problem if the Cbus does not have another Time Master