Comfort Home Automation/ Security System Forums Home
Home Search search Menu menu Not logged in - Login | Register

Date / Time change in Event Log
 Moderated by: admin Page:  First Page Previous Page  1  2  3  Next Page Last Page  
 New Topic   Reply   Printer Friendly 
 Rating:  Rating
AuthorPost
 Posted: Tuesday Sep 8th, 2015 10:05 am
   PM  Quote  Reply 
21st Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 546
Status: 
Offline

  back to top

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.



 Posted: Tuesday Sep 8th, 2015 12:06 pm
   PM  Quote  Reply 
22nd Post
juwi_uk
Member


Joined: Friday May 25th, 2007
Location: Newbury, United Kingdom
Posts: 1246
Status: 
Offline

  back to top

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

 

 



 Posted: Tuesday Sep 8th, 2015 12:20 pm
   PM  Quote  Reply 
23rd Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 546
Status: 
Offline

  back to top

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.



 Posted: Tuesday Sep 8th, 2015 12:35 pm
   PM  Quote  Reply 
24th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 4339
Status: 
Offline

  back to top

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



 Posted: Tuesday Sep 8th, 2015 02:24 pm
   PM  Quote  Reply 
25th Post
juwi_uk
Member


Joined: Friday May 25th, 2007
Location: Newbury, United Kingdom
Posts: 1246
Status: 
Offline

  back to top

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.

 



 Posted: Tuesday Sep 8th, 2015 06:18 pm
   PM  Quote  Reply 
26th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 4339
Status: 
Offline

  back to top

we do not understand this
That is why we need more information
It does not happen in our systems that we see



 Posted: Wednesday Sep 9th, 2015 12:07 am
   PM  Quote  Reply 
27th Post
juwi_uk
Member


Joined: Friday May 25th, 2007
Location: Newbury, United Kingdom
Posts: 1246
Status: 
Offline

  back to top

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

 



 Posted: Wednesday Sep 9th, 2015 08:02 am
   PM  Quote  Reply 
28th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 4339
Status: 
Offline

  back to top

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



 Posted: Wednesday Sep 9th, 2015 11:14 am
   PM  Quote  Reply 
29th Post
juwi_uk
Member


Joined: Friday May 25th, 2007
Location: Newbury, United Kingdom
Posts: 1246
Status: 
Offline

  back to top

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 11:15 am by juwi_uk



 Posted: Wednesday Sep 9th, 2015 11:19 am
   PM  Quote  Reply 
30th Post
juwi_uk
Member


Joined: Friday May 25th, 2007
Location: Newbury, United Kingdom
Posts: 1246
Status: 
Offline

  back to top

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 11:20 am by juwi_uk



 Posted: Wednesday Sep 9th, 2015 05:11 pm
   PM  Quote  Reply 
31st Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 546
Status: 
Offline

  back to top

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 05:18 pm by Ingo



 Posted: Wednesday Sep 9th, 2015 05:39 pm
   PM  Quote  Reply 
32nd Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 4339
Status: 
Offline

  back to top

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



 Posted: Wednesday Sep 9th, 2015 05:47 pm
   PM  Quote  Reply 
33rd Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 546
Status: 
Offline

  back to top

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.



 Posted: Wednesday Sep 9th, 2015 07:40 pm
   PM  Quote  Reply 
34th Post
juwi_uk
Member


Joined: Friday May 25th, 2007
Location: Newbury, United Kingdom
Posts: 1246
Status: 
Offline

  back to top

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.

:)



 Posted: Thursday Sep 10th, 2015 11:34 am
   PM  Quote  Reply 
35th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 4339
Status: 
Offline

  back to top

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



 Posted: Thursday Sep 10th, 2015 10:47 pm
   PM  Quote  Reply 
36th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 546
Status: 
Offline

  back to top

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.



 Posted: Friday Sep 11th, 2015 06:33 am
   PM  Quote  Reply 
37th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 4339
Status: 
Offline

  back to top

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



 Posted: Friday Sep 11th, 2015 09:59 am
   PM  Quote  Reply 
38th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 546
Status: 
Offline

  back to top

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.



 Posted: Friday Sep 11th, 2015 12:52 pm
   PM  Quote  Reply 
39th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 4339
Status: 
Offline

  back to top

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



 Posted: Friday Sep 11th, 2015 04:35 pm
   PM  Quote  Reply 
40th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 546
Status: 
Offline

  back to top

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.



 Current time is 02:54 amPage:  First Page Previous Page  1  2  3  Next Page Last Page  
Top




UltraBB 1.172 Copyright © 2007-2014 Data 1 Systems