Date / Time change in Event Log

[Ingo]

I just unplugged a few UCM\'s for a few minutes and plugged them back in again. I am now 12s behind. Doing it again didn\'t cause any change in time at all. Something is not keeping time as we think it should... Perhaps we have more than just a \'Log to Eventlog\' issue here. I think keeping accurate time, even through a module replacement or hopefully a reset, is key.

Don\'t get me wrong, I like the SNTP feature, it\'s perhaps only now that we notice these time changes because we have something that corrects it. In the past we wouldn\'t have known about this.

Oops, forgot, I had to do a reset inbetween the module replacements and that added a whole bunch of seconds.

[slychiu]

Reset would add quote a lot of seconds as the firmware does not run during reset

[Ingo]

Comfort III Ultra enhancement request. Add external RTC chip to supply time to Comfort CPU when required. At reset it will keep running and on CPU startup it will read the time from the RTC. NTP can then keep the system in sync while an Internet connection is available. For people not connecting to the Internet it will keep Comfort in sync over time.

[juwi_uk]

Maybe in a future UCM baseboard it can connect direct to the backup battery so that it runs even during reboot.  Then its time will be correct and can pass onto Comfort as soon as it has finished bootup.

[slychiu]

I dont believe an external RTC is justified if the UCM/ETH03 time adjustment and the daily time adjustment features are available. It increases the cost for all users who do not need this and for those who have ETh03 unneccessarily.

Those who need very accurate time should buy an ETH03

And using it just to correct for the few seconds lost during reset seems to be of not much use. ETH03 will update the time after it resets

We need to find out why the event log is being updated so many times for those who have the prioblem, which we can do as soon as we  can duplicate it

[Ingo]

Ok, so here is my analyses done with a KT03 and Eth03. I had Bus Monitor capture the data and then made a manual change to Comfort to see the outcome. I must say that I do NOT get the eventlog entries every 10mins like some of the other users and that I checked my RTC to be within 1s of NTP time over a 24H period.

Bus Monitor Log:

18: 18: 32: 785 ----< 03 14 53 32 30 31 35 30 39 31 30 31 38 31 33 31 32 30 30 30 42 02 <--->S20150910181312000B Set date and time
18: 29: 59: 934 ----< 03 14 53 32 30 31 35 30 39 31 30 31 38 32 33 31 33 30 30 46 41 02 <--->S2015091018231300FA Set date and time
18: 41: 30: 849 ----< 03 14 53 32 30 31 35 30 39 31 30 31 38 33 33 31 33 30 30 45 41 02 <--->S2015091018331300EA Set date and time
18: 53: 10: 516 ----< 03 14 53 32 30 31 35 30 39 31 30 31 38 34 33 31 34 30 30 44 39 02 <--->S2015091018431400D9 Set date and time

Set time here to <NTP> minus 3s to see if the Eth03 will correct it. Restarted Bus Monitor again.

19: 03: 21: 457 ----< 03 14 53 32 30 31 35 30 39 31 30 31 39 30 33 31 36 30 30 31 36 02 <--->S201509101903160016 Time changed here by Eth03
19: 03: 21: 473 ----< 03 00 53 32 30 31 35 30 39 31 30 31 39 30 33 31 36 30 30 32 41 02 <--->S20150910190316002A and Broadcast to all.

Wait for next update @ ~19:13:17... Checked time and is 100% correct.

19: 14: 02: 917 ----< 03 14 53 32 30 31 35 30 39 31 30 31 39 31 33 31 37 30 30 30 35 02 <--->S201509101913170005
19: 25: 19: 686 ----< 03 14 53 32 30 31 35 30 39 31 30 31 39 32 33 31 37 30 30 46 35 02 <--->S2015091019231700F5 

EventLog entries:

Changes shown below where I made the manual DT change and where the Eth03 updated the time to the correct NTP time. No other entries appear whatsoever.

09/10 19:01 Date/Time Change 66 <- KT03
09/10 19:03 Date/Time Change 20 <- Eth03

If someone that get eventlog updates every 10 minutes do the same Cytech can compare the data and perhaps find a way to correct it. Just a quick PS. I thought the Eth03 would only correct time if its out by 4s or more, perhaps I caught it right on the boundary of 4s, I might try the same test later with 2s time difference.

[slychiu]

Thanks for the  results
I am puzzled as to why your time on the left is not the same as the time reported by Comfort
[color=\"#ff0000\"]18: 18: 32: 785[/color] ----< 03 14 53 32 30 31 35 30 39 31 30 31 38 31 33 31 32 30 30 30 42 02 <--->S20150910[color=\"#ff0000\"]181312[/color]000B Set date and time
18:18:32 on your computer vs 18:13:12 from Comfortut 
 I thought the Eth03 would only correct time if its out by 4s or more, perhaps I caught it right on the boundary of 4s
That is not correct. ETH03 will correct the Comfort time as long as it is not the same, but it will not report the time change to the event log if the correction was less than 4 seconds.This way, ETH03 should keep the time accurate but there should be no events in the event log as long as the time correction is less than 4 seconds. If ETH03 does not correct the time if less than 4 seconds then the inaccuracy would  accumulate.
So if the update interval is shorter than the interval at which the clock inaccuracy is 4 seconds then there should be no events
One way of fixing the event log issue is to not update the event log if the correction is less than 1 minute

[Ingo]

Thanks Chiu, now I understand the 4s rule. Can that be extended to other UCM\'s, like Cbus2, that receives Date/Time updates as well?

The issue with the time on the left and the right is because Bus Monitor somehow starts to \'slow down\' over time and buffers data - strange but true. A change that happens at \'18:13:12\' only shows up in the application window a few seconds, to a few minutes, later - it\'s an application issue if you ask me.

[slychiu]

You mean update the cbus time only if there is 4 seconds difference?
The problem is the UCM/Cbus does not always know the cbus time

[Ingo]

Yes, the Cbus time is also broadcast back to Comfort and that generates an event log entry every 70 minutes if you have a PAC connected. That\'s why I said in a previous post that things can get complicated.

The PAC is a Cbus P2 time device and updates the devices, and Comfort, every 70 minutes. Native Comfort, without an Eth03 or Eth03 with SNTP disabled, should not send time updates more frequent than this, I think the standard in Cbus for a P3 time device is 150 minutes. Be that as it may, with an Enabled Eth03 it then changes from a P3 to a P1 time device which should send time updates back to Cbus between 30 and 70 minutes. This will override the PAC (P2) time device and we (Comfort) will not receive any updates as it yields control to Comfort (or the higher priority time device).

Now, if you don\'t have an Eth03 your Comfort is a P3 and Cbus is a P2 time device and Cbus will update Comfort every 70 minutes. This change is logged in the Comfort Event Log every single time. Here is where I propose that the event ONLY be logged IF the time change is greater than 4s as is the case with the Eth03. Cbus still updates every 70 minutes but it\'s not logged unless the time deviation is greater than 4s.

I like the Cbus time protocol, it\'s clear and simple. Three layers of priorities and they yield time to the \'better\' source. With the Eth03\'s Max update time being 60 minutes it conforms perfectly to this standard. Relaxing that standard might make Cbus the Master again and it is only a P2 device. I would want the most accurate clock, the Eth03 in this case, be the Master. With both the Eth03 and Cbus updating time it could cause issues. I assume KNX, and other vendors, have a similar protocol.