Posts: 237
Threads: 41
Joined: Sep 2006
Reputation:
0
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
Posts: 84
Threads: 20
Joined: Mar 2014
Reputation:
0
I have noticed the same - would be good to not log this unless say time correction is greater than a threshold
Posts: 1,200
Threads: 262
Joined: Mar 2007
Reputation:
0
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
Posts: 629
Threads: 62
Joined: Jan 2007
Reputation:
2
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
Posts: 629
Threads: 62
Joined: Jan 2007
Reputation:
2
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
Posts: 629
Threads: 62
Joined: Jan 2007
Reputation:
2
05-02-2015, 03:35 PM
(This post was last modified: 05-02-2015, 06:39 PM by Ingo.)
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
Posts: 1,200
Threads: 262
Joined: Mar 2007
Reputation:
0
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
Posts: 629
Threads: 62
Joined: Jan 2007
Reputation:
2
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... :-)
Posts: 73
Threads: 15
Joined: Mar 2015
Reputation:
0
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......
