Comfort Automation/ Security System Forums > Support > FAQs - Technical > Date / Time change in Event Log |
Comfort Automation/ Security System Forums > Support > FAQs - Technical > Date / Time change in Event Log |
| Moderated by: admin | ||
| Author | Post | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
mikeinnc Member
|
When I read my Comfort Event Log, I see that it records a Date / Time change just about every hour of every day! Of course, this fills the Event Log with a lot of entries that are really not at all interesting....... So, my question is - is there any way I can stop a 'Date / Time Change' being logged. It will make reading the log far easier! Many thanks, as usual. |
|||||||||
|
slychiu Administrator 
|
Are you using the UCM/ETH03 which is able to synchronise the time wth an Internet Time Server? This could be what is correcting the Comfort time when it becomes a little out The SNTP (Simple Network Time Protocol) button below  The SNTP setting page is below  The NTP synchronise interval is the time between syncs.It is shown as 30 minutes above. If there is a time difference at the time of sync then the time is updated and iit may be recorded to the event log Upgrade to the latest Comfort firmware to reduce the number of events logged In the current firmware, if the time difference is less than 4 seconds, the time is updated but it is not recorded in the event log. 30 or 60 minutes as the update interval should work, as the comfort time will not be so inaccurate as to be out by 4 seconds during this time interval |
|||||||||
|
mikeinnc Member
|
Thanks very much for that! I've just upgraded to the latest firmware, and, yes, I do use a UCM/ETH03 synchronised to an Australian NTP pool server. I believe this will be a significant improvement - the event log really didn't need all those date/time change events!  |
|||||||||
|
mikeinnc Member
|
Well, now that the new firmware has been in place for > 24 hrs, I thought I'd check in the event log.....and it hasn't made a scrap of difference! Here's a sample of the log AFTER the new firmware has been installed. 09/05 18:57 Date/Time Change 18 09/05 20:07 Date/Time Change 18 09/05 21:18 Date/Time Change 18 09/05 22:28 Date/Time Change 18 09/05 23:39 Date/Time Change 18 09/06 00:49 Date/Time Change 18 09/06 01:59 Date/Time Change 18 09/06 03:10 Date/Time Change 18 09/06 04:20 Date/Time Change 18 09/06 05:31 Date/Time Change 18 09/06 06:41 Date/Time Change 18 09/06 07:51 Date/Time Change 18 09/06 09:02 Date/Time Change 18 09/06 10:12 Date/Time Change 18 09/06 11:23 Date/Time Change 18 Nearly every hour there is an entry - just as before. So either my Comfort clock is very poor at keeping time - or the firmware update hasn't worked! Is there any manual way to stop these entries - other than turning off the NTP Synch? Attachment: ComfortNTP.jpg (Downloaded 40 times) |
|||||||||
|
juwi_uk Member 
|
I must admit I unchecked the box after a while too on mine as otherwise 90% of my log file were these. Last edited on Sunday Sep 6th, 2015 04:58 pm by juwi_uk |
|||||||||
|
juwi_uk Member
|
I originally raised this in this thread: http://www.comfortforums.com/forum25/4146-2.html Last edited on Sunday Sep 6th, 2015 04:57 pm by juwi_uk |
|||||||||
|
slychiu Administrator
|
Your Comfort clock is probably inaccurate so that if you wait 1 hour the error is too much Can you change the setting to 10 minutes and see what is the result? |
|||||||||
|
juwi_uk Member
|
Already IS set to 10 mins. But OK i'll; enable and monitor again. Will clear down the log first though. J Attachment: 2015-09-06_14-15-26.png (Downloaded 35 times) |
|||||||||
|
juwi_uk Member
|
Yep you can set your watch by an entry going in the log. I knew there was a reason I turned it off again. You cant tell me this isnt a bug. Something is wrong here big time. It is a daylight savings issue? I think I'll turn it off again Julian Attachment: 2015-09-06_15-50-16.png (Downloaded 34 times) |
|||||||||
|
Ingo UCM Pi Users 
|
I tend to agree with Julian, something is wrong. If NTP adjusted the time then it stands to good reason that the time can run in the corrected state for at least the 10 minutes before the next NTP check. If however there is really something wrong with the RTC then I agree that NTP will keep correcting the time. If however Julian has disabled NTP, and he can verify that the time is correct to within the 4s, or 10s I can't remember, of NTP time then we know there is a bug somewhere. Too many people complain about the same thing to be a coincidence. Julian, do a check for us. Set the time to NTP time and check it exactly 24H later to see how far the time drifted. My guess is that it shouldn't drift at all because Comforts RTC is very accurate on its own. I will do the same this side. Ingo |
|||||||||
|
mikeinnc Member
|
Well, I've just set my interval to 15 minutes and I'll monitor what happens. It shouldn't be a daylight saving issue - we don't have summer time / winter time in Western Australia. The voters won't accept it! (We've had 3 votes in some 20 years and they have all failed so in summer we are 3 hrs behind Eastern States and in winter, 2 hrs.) But I'm tending to agree there is a bug somewhere. Cheap and cheerful $2.00 watches can keep accurate time, so I'm certain the Comfort RTC can!! |
|||||||||
|
juwi_uk Member
|
I've just done some tests by having the SNTP window open and doing a "DT" command to Comfort. I also tried "Dt" as well. Both are returning the time to the same second as the SNTP realtime update field. From what I can see they are both totally in sync yet Comfort doesnt think so itself. Ju |
|||||||||
|
slychiu Administrator
|
Can you disable the tome update after synchornising the time After 24 hours check how many seconds is Comfort time out compared to the corect time |
|||||||||
|
juwi_uk Member
|
Why is that going to make any difference when it thinks it is out after only 10 minutes? I ran side by side for an hour and time same to the second. |
|||||||||
|
slychiu Administrator
|
We want to see if the time is realy out There is also a adjust time parameter in Configuration > Modules and Srttings to compensate for time innacuacry on a daily basis |
|||||||||
|
tman Comfort Distributors
|
I'm getting the Date/Time Change message every hour as well on the installs we have here. They're all running the latest Comfort and ETH03 firmware. Last edited on Monday Sep 7th, 2015 06:28 pm by tman |
|||||||||
|
Ingo UCM Pi Users
|
I also did a test for 18 hours and Comfort didn't gain/lose one second. The RTC has proven itself to be be accurate over this time but I will let it run for another 24H just to see if it really gains/loses anything. |
|||||||||
|
mikeinnc Member
|
Some 24 hours now since I set the update time interval to 15 minutes, and the event log is still showing a Date/Time change event virtually every hour. Yes, it skipped the occasional hour but still irritatingly - and it would appear unnecessarily - frequent. This is certainly looking like a bug. I note the comment about the adjust time parameter, but I'd be really reluctant to adjust this without a detailed analysis of the RTC accuracy. And, as Ingo has confirmed, I'm very confident that the RTC IS accurate. |
|||||||||
|
Ingo UCM Pi Users
|
30H, lost 1s only. |
|||||||||
|
slychiu Administrator
|
That is without the ETH03 update time? Are you sure? Our RTC should not even be this accurate? |
|||||||||
|
Ingo UCM Pi Users
|
Correct yes. Eth03 Updates disabled. NTP checked and sync'd on my PC before every test. I have changed my RTC setting from 0 to 1 to see what the accuracy will be for the next 24H test. Even with 1s out over 30H it still doesn't explain the DT changes every 10 minutes for some users. I will enable mine again in 24H to see what happens. |
|||||||||
|
juwi_uk Member
|
Mine is actually showing it is 23 seconds behind this morning if i do a DT command while watching the SNTP field readout. How can the RTC be that far our after 24 hours when as somebody else mentioned cheap $1 watches dont do that. What do I need to adjust? Julian |
|||||||||
|
Ingo UCM Pi Users
|
Julian, also take note that every Comfort reset will set the clock back a few seconds. On my test system it's 3s. This is probably because the HW doesn't use a dedicated RTC chip but rather the CPU for the clock - I'm just guessing by looking at the design. That said, the CPU is additionally clocked by a 32,768khz crystal for RTC applications so while running normally it 'should' be very accurate depending on the code. |
|||||||||
|
slychiu Administrator
|
Enter +23 into the Time Adjust fieldThis speeds up the clock by 23 seconds per day Keep the SNTP update disabled and see the results after a day tuning fork crystals are delicate They may drift due to force or knocks, as it is not locked away like in a watch |
|||||||||
|
juwi_uk Member
|
I still don't understand where this is getting me. Even if it is out 30 secs a day it is not out more than a second in 10 minutes so why does it try to change every 10 minutes. |
|||||||||
|
slychiu Administrator
|
we do not understand this That is why we need more information It does not happen in our systems that we see |
|||||||||
|
juwi_uk Member
|
Checking 12 hours after my last post and it's 8secs behind. I have set the adjust to 23 (12 hours ago) and sync'd the clock when I uploaded to Comfort so assume that applies in one go at some stage (at midnight?). How accurate should a normal clock be; do I need to get the hardware repaired? Julian |
|||||||||
|
slychiu Administrator
|
Try entering 39 instead of 23 assuming it is 39 seconds slowIt seems to be too much if it is out by 39 seconds a dayWith the UCM/ETH03 time adjustment and the daily time offset feature, it should not be a big problem, but we will be happy to change the crystal if you return the Comfort. But I do not think it is worthwhile |
|||||||||
|
juwi_uk Member
|
Yesterday it was 23 seconds behind. This morning it is 18 seconds ahead (but obviously the 23 sec adjustment was applied) Dont know what to make of this. Going to zero the adjustment again. Last edited on Wednesday Sep 9th, 2015 10:15 am by juwi_uk |
|||||||||
|
juwi_uk Member
|
Perhaps you can relax the NTP Synchronize interval from it's max of 60 minutes so we can set to 1 day? ...or as this post started don't write these to the event log in the first place. Last edited on Wednesday Sep 9th, 2015 10:20 am by juwi_uk |
|||||||||
|
Ingo UCM Pi Users
|
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. Last edited on Wednesday Sep 9th, 2015 04:18 pm by Ingo |
|||||||||
|
slychiu Administrator
|
Reset would add quote a lot of seconds as the firmware does not run during reset |
|||||||||
|
Ingo UCM Pi Users
|
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 Member
|
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 Administrator
|
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 UCM Pi Users
|
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 Administrator
|
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 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: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 UCM Pi Users
|
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 Administrator
|
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 UCM Pi Users
|
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. |
|||||||||
|
slychiu Administrator
|
Thanks for the useful summary. It is quite a complex matter which we must study |
|||||||||