Had cause to remotely dial in to comfort today to check up on an earlier arm failure. As expected, upon remote sign in, comfort automatically started speaking back the event log... Slight problem with this was it spent a good 10 minutes saying \"change time xx:xx\" where each instance of xx:xx was every hour since the arm failure... Seems like when the UCM/ETH03 does the Internet time sync, this is recorded in the event log...
This really could be a bit of a PITA - having to listen to days upon days worth of hourly timesync events...
Is it possible to turn this feature off? I really don\'t regard it as a security issue if comforts time is set via the configured timesync... Perhaps if it is set via keypad that may be worthy of noting, but it really unnecessarily pads out the amount of event history I have to sit & listen to when dialling in... I can imagine this being even more annoying if I\'m specifically wanting to listen for certain events... In an alarm condition perhaps...
Regards
Paul G
I have noticed the same - would be good to not log this unless say time correction is greater than a threshold
What is the frequency of updates setting in the ETH03? You should set it to a longer period to avoid to many updates
It is important to record time changes in the event log because the time and date could be changed by other devices eg Cbus and KNX. The event log tells the ID which caused the time change
Have you upgraded the Comfort firmware to the latest? The event log is updated when the time adjustment is 4 seconds or more so there should not be very frequent updates
Cbus broadcasts a Time Update every 70 minutes in my case (I have a PAC unit). Actually it\'s very strange seeing that Comfort is supposed to become the Time Master once connected to Cbus.
The device with the most frequent Time Updates becomes the master and if I remember correctly Comfort should, or did in the past, send Time Updates back to Cbus every 60 minutes. The reason for this was that Comfort had a more accurate clock and it is battery backed up. In the event of a network power restore Comfort would send a Time Change on Cbus Startup. Cbus will then become a \'Slave\' and start to listen to Comfort for time updates. If Comfort stops sending Time updates for 70 minutes(next best Slave\'s interval) then Cbus becomes the Master again. As long as Comfort sends a Time Update every 60 minutes it remains the Master and Cbus will \'listen\' to the Time and will NOT broadcast.
For some reason Comfort might NOT be sending this initial update to become the Master or it doesn\'t send periodic updates and Cbus takes over that role after 70 minutes from power up.
Ingo
Ok, I did some investigation on my network and found the following:
2015/05/01 11:35:45 Info : Time Mastering start-up
2015/05/01 12:20:40 Date/Time: Received C-Bus message to set date to 2015/05/01 (unit 19)
2015/05/01 12:20:40 Info : Time Mastering now passive
2015/05/01 12:20:40 Date/Time: Received C-Bus message to set time to 12:20:38 (unit 19)
2015/05/01 13:00:02 Date/Time: Received C-Bus message to set time to 13:00:00 (unit 18)
2015/05/01 14:10:21 Date/Time: Received C-Bus message to set date to 2015/05/01 (unit 19)
2015/05/01 14:10:21 Date/Time: Received C-Bus message to set time to 14:10:19 (unit 19)
2015/05/01 15:20:40 Date/Time: Received C-Bus message to set date to 2015/05/01 (unit 19)
2015/05/01 15:20:40 Date/Time: Received C-Bus message to set time to 15:20:38 (unit 19)
2015/05/01 16:30:59 Date/Time: Received C-Bus message to set date to 2015/05/01 (unit 19)
2015/05/01 16:30:59 Date/Time: Received C-Bus message to set time to 16:30:57 (unit 19)
Units:
18 - Comfort UCM/Cbus2
19 - Clipsal PAC
From my limited information on a very complex Time Control protocol I can explain the above something like this.
At 11:35 I started PICED to see what I can find on the network. Piced immediately went into a Time Startup state to learn what is already on the network.
At 12:20:40 a Time Update was received from Unit 19 (Clipsal PAC). At this point things still look normal and PICED went into Passive mode - No time advertisements from PICED.
At 13:00:02 another Time Update was received from Unit 18, this time from Comfort. All still legal at this stage. The PAC would probably have gone into a Passive state also so let\'s assume it did. From this point onwards the PAC is now watching to see if Unit 18 (Comfort) is a more frequent time source or not. IF, and that is a BIG IF, Comfort sends another Time update at 14:00 (60 minutes after first update), then the PAC unit will not sends any more updates. IF Comfort does not send an update for 70 minutes, the PAC\'s Time Update Interval, then the PAC will take control of the Time function again.
At 14:10:21 nothing was received from Comfort and the PAC unit assumes Time Master again and continues it\'s 70 minute Time Update Broadcasts irrespective of time.
Here is the trick, Cbus Broadcasts the Time Updates via PAC every 70 minutes, no matter what. This is to keep \'less accurate\' devices in sync all the time. Comfort interprets this Update Broadcast as a Time Change even though Comfort is probably within milliseconds of the Cbus time.
Here is my suggestion to Cytech:
1. Investigate the Time Control protocol to see if I am right with my explanation above and if so then Comfort should be Time Master whenever it\'s connected to Cbus.
2. Investigate why Comfort logs a Date/Time change on every Cbus Update Broadcast. Eth03 units only update the Time/Date if there is a 4s difference from the Comfort time to the SNTP time received. Can we implement the same for the UCM/Cbus to only log a Time/Data change on an Actual change and not just when it receives a Time Update Broadcast.
From the Cbus Time Protocol documentation the one note that stands out is essentialy: \"with all things being equal, the device with the shortest update timer wins, all others must become Passive\".
With Comfort also NTP connected for people with Eth03 and others with ComfortClient connected to the Internet so it should be Master even more so than in the past where Comfort just broadcast time back to Cbus every 60 minutes and assumed the Master role. The Clipsal protocol states a 70 minute update time for Priority 2 devices but it also states \'approximately 70 minutes\'. I guess 60 minutes is close enough then...
Ingo
UCM/CBUS2 sets the Long waiting Interval to 80 minutes and the short waiting interval to 40 seconds in the terminology of the Clocks and Timekeeping application
This was done before the UCM/ETH03 time sync feature
The UCM/Cbus2 currently has no mechanism to know if the time updates from Comfort are from ETH03 (or if the time sync feature is used) anyway so it may not know that its time is more accurate than Cbus.
Quote:Eth03 units only update the Time/Date if there is a 4s difference from the Comfort time to the SNTP time received. Can we implement the same for the UCM/Cbus to only log a Time/Data change on an Actual change and not just when it receives a Time Update Broadcast.
The above is not correctIt is not the ETH03 only updates Time/date if there is a 4 second difference.Comfort does not update the event log or send a time broadcast if the time difference is less tha +/- 4 seconds, but it still accepts the time from the UCM so that the time remains accurate
Thanks for acknowledging the fact that Comfort will never become a Time Master if there is another Time device on Cbus - Ever.
Can we please have a fix for:
1. Comfort to become Time Master on a Cbus network even if there is another Priority 2 Time Source.
2. Disable the logging of Time Updates from Cbus when periodic broadcasts are received and there is no need to change time.
Thanks,
Ingo
UCMcbus can be come a time maaster by reducing the long wait interval from 80 to less than 70 minutes
This may be a programmiable option in a future fimware
Excellent, thanks. That will also indirectly solve the problem of the event log filling up with Time Update messages as Cbus is no longer Master. Until someone connects a Priority 1 Time device to Cbus... :-)
Has there been any further development on this problem? I\'m still getting a logfile with hundreds of time/date changes every 2 hours or so......