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

Time sync in event log
 Moderated by: ident Page:    1  2  Next Page Last Page  
 New Topic   Reply   Printer Friendly 
 Rate Topic 
AuthorPost
 Posted: Thursday Apr 30th, 2015 11:24 pm
   PM  Quote  Reply 
1st Post
Pgordon
Member
 

Joined: Saturday Sep 23rd, 2006
Location: London, United Kingdom
Posts: 237
Status: 
Offline

  back to top

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



 Posted: Friday May 1st, 2015 01:50 am
   PM  Quote  Reply 
2nd Post
cc_uk
Member
 

Joined: Friday Mar 28th, 2014
Location:  
Posts: 66
Status: 
Offline

  back to top

I have noticed the same - would be good to not log this unless say time correction is greater than a threshold



 Posted: Friday May 1st, 2015 05:53 am
   PM  Quote  Reply 
3rd Post
admin
Administrator


Joined: Saturday Mar 3rd, 2007
Location: Singapore
Posts: 1200
Status: 
Offline

  back to top

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



 Posted: Friday May 1st, 2015 08:34 am
   PM  Quote  Reply 
4th Post
Ingo
UCM Pi Users


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

  back to top

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



 Posted: Friday May 1st, 2015 08:20 pm
   PM  Quote  Reply 
5th Post
Ingo
UCM Pi Users


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

  back to top

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

 





 Posted: Saturday May 2nd, 2015 07:41 am
   PM  Quote  Reply 
6th Post
admin
Administrator


Joined: Saturday Mar 3rd, 2007
Location: Singapore
Posts: 1200
Status: 
Offline

  back to top

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. 

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

Last edited on Saturday May 2nd, 2015 01:04 pm by admin



 Posted: Saturday May 2nd, 2015 03:35 pm
   PM  Quote  Reply 
7th Post
Ingo
UCM Pi Users


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

  back to top

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

Last edited on Saturday May 2nd, 2015 06:39 pm by Ingo



 Posted: Sunday May 3rd, 2015 10:07 am
   PM  Quote  Reply 
8th Post
admin
Administrator


Joined: Saturday Mar 3rd, 2007
Location: Singapore
Posts: 1200
Status: 
Offline

  back to top

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



 Posted: Sunday May 3rd, 2015 10:36 am
   PM  Quote  Reply 
9th Post
Ingo
UCM Pi Users


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

  back to top

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... :-)



 Posted: Wednesday Nov 25th, 2015 03:26 am
   PM  Quote  Reply 
10th Post
mikeinnc
Member
 

Joined: Wednesday Mar 18th, 2015
Location: Perth, Australia
Posts: 69
Status: 
Offline

  back to top

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......



 Posted: Wednesday Nov 25th, 2015 06:23 am
   PM  Quote  Reply 
11th Post
slychiu
Administrator


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

  back to top

ULT 7092 (beta) has a looser threshold of +/- 15 seconds time change before it recorss in the event log
Can you try this firmware and let us know 



 Posted: Wednesday Nov 25th, 2015 05:35 pm
   PM  Quote  Reply 
12th Post
mikeinnc
Member
 

Joined: Wednesday Mar 18th, 2015
Location: Perth, Australia
Posts: 69
Status: 
Offline

  back to top

Sorry to say it doesn't appear to have made a scrap of difference! I upgraded to 7092 (beta) - and also Comfigurator to 3.10.9.0 - and cleared the event log. That was at about 4pm. Just looked at event log (it's about 21:30 here) and date/time changes UCM2 entries are at:

17:12
18:23
19:33
20:43

That suggests some 20+ events every day that are just date / time changes. Not what I would have expected!



 Posted: Thursday Nov 26th, 2015 02:25 am
   PM  Quote  Reply 
13th Post
mikeinnc
Member
 

Joined: Wednesday Mar 18th, 2015
Location: Perth, Australia
Posts: 69
Status: 
Offline

  back to top

More information. After writing last night, I checked the UCM02 module - a CBus2 v7.054 module - and noticed the 'Built-in CBus Applications - Clocks/Timekeeping' was checked ON. Thinking about this, my CBus is only used for lighting control, and any timing for lights is done from Comfort. So I turned it OFF. And this morning, 9 or so hours later - not one change time event has been registered since! So, is this correct? Should the CBus module timekeeping be switched off? Will Comfort still keep correct time, corrected as necessary from my NTP settings?

Thanks for all your help.



 Posted: Thursday Nov 26th, 2015 07:01 am
   PM  Quote  Reply 
14th Post
Ingo
UCM Pi Users


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

  back to top

Yes, Comfort will keep time via NTP. The question is how will Cbus keep time...

With the checkbox unchecked the Cbus network will keep time on its own but if the time changes there is nothing to correct it. I was curious about your 70 minute time updates and that points to Cbus' Time Protocol broadcasting a Time Update at that interval - thats normal.

What 'should' happen is that your Eth03 should be set at < 70 minute updates which in turns disables Cbus as the Time Master and it will be Slave to Comfort. I doubt if that happens but anyway, the Cbus Time Protocol Broadcasts time at 70 minute intervals and that causes a Time Change event log entry even though there was no time change and that is where all the updates come from.



 Posted: Thursday Nov 26th, 2015 11:11 am
   PM  Quote  Reply 
15th Post
mikeinnc
Member
 

Joined: Wednesday Mar 18th, 2015
Location: Perth, Australia
Posts: 69
Status: 
Offline

  back to top

Thanks for that explanation, Ingo. I'm not sure that I do need CBus to keep time? My CBus is exclusively used for lighting - the only time 'elements' are a couple of outside sensors which use light levels rather than 'time' to determine what function they perform. My eth03 is set at 60 minutes for time updates - well, I guess it is? I suppose you mean the parameter in the 'Comfort Server Manager' NTP tab? It was always set at 60 - less than the 70 you suggest CBus was using, so something doesn't sound quite right! I think I can live with no RTC on my CBus system - well, unless I'm missing something. And, if it stops those annoying 'every 70 minutes' entries in the log, I'm super happy! But I agree with you - it does sound as though we are masking a more fundamental problem? Not critical, I agree, but one of those irritating issues we'd rather do without......:)

Mike



 Posted: Thursday Nov 26th, 2015 12:21 pm
   PM  Quote  Reply 
16th Post
Ingo
UCM Pi Users


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

  back to top

Yip, you might not need time sync for lighting only. I agree that Comfort should have some or other check to see if the time actually changed when receiving a Cbus Time/Date broadcast. I'll move my Eth03 from Dev to Prod to see how bad it really is. Currently my Eth03 is in my Dev environment without Cbus.



 Posted: Thursday Nov 26th, 2015 04:20 pm
   PM  Quote  Reply 
17th Post
slychiu
Administrator


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

  back to top

The cbus clocks and timekeeping application describes the behaviour of 2 Time masters on the bus
http://training.clipsal.com/downloads/OpenCBus/Clock%20and%20Timekeeping%20Application.pdf

UCM/Cbus complies to this specification

The Long wait time is fixed at 80 minutes and the short wait time is 40 seconds

Hence if Cbus has a long wait time at 70 minutes it becomes a bus master and will send time to Comfort.

Ingo suggest to set the eth03 update interval < 70 minutes. However if the Comfort clock is accurate, the eth03 time update may not change the clock and hence may not send its time to Cbus, leaving Cbus as the bus master

In future eth03 time updates may have to be broadcast to cbus regardless of the time correction so that the ucm/cbus can be maintained as master. Or some other solution



 Posted: Thursday Nov 26th, 2015 04:41 pm
   PM  Quote  Reply 
18th Post
Ingo
UCM Pi Users


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

  back to top

I agree, if you want the Eth03 to become the Master then it needs to broadcast the time back to Cbus at < 70 which is currently my PAC update time. I think Cbus has a 60minute device, it could be a Touch with it's own NTP or perhaps a Wiser with NTP. So < 60 if you want Comfort to be the Master.

The other things is that Comfort needs to do a check on the received NTP time from the Eth03 BEFORE it logs it as a change. It has now been proven that Comfort clocks can drift a little so a change would eventually be required. That said, could we have the offset as a variable? Some people, like me, would want the time to be fairly accurate but I am not interested in logging DT changes unless it's EG.> 15s.

Here is my suggestion: Either hardcode, or make it settable, the delta allowed for the time to be out before you LOG a change to the event log. That said, if the time is out by EG. more than 4s, or even 2s, then update Comfort irrespective, just don't log it unless it's more than the previously mentioned 15s.

This will serve both worlds. The world that wants to know if someone sets the time out by hours/days/years, like most of us, and also satisfies the people who are not interested if the time is adjusted 2s but want their systems in perfect sync, again like most of us.

Ingo
Arhh... before I forget. The same 'test' of the time must be done to all devices updating Comfort time EG. the UCM/Cbus we are discussing also because you can also choose your Cbus to be Master and then you will get updates broadcast back to Comfort every 60 or 70 minutes.

Last edited on Thursday Nov 26th, 2015 04:44 pm by Ingo



 Posted: Friday Nov 27th, 2015 06:18 am
   PM  Quote  Reply 
19th Post
slychiu
Administrator


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

  back to top

Here is my suggestion: Either hardcode, or make it settable, the delta allowed for the time to be out before you LOG a change to the event log. That said, if the time is out by EG. more than 4s, or even 2s, then update Comfort irrespective, just don't log it unless it's more than the previously mentioned 15s.




To be clear, the time difference of +/- 15 seconds is to determine whether this is recorded in the event log. Any time difference even 1 second will update the Comfort time
Previously it used to be 4 seconds. It was increased in order to reduce the number of events in the event log



 Posted: Friday Nov 27th, 2015 06:34 am
   PM  Quote  Reply 
20th Post
Ingo
UCM Pi Users


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

  back to top

Excellent, thanks. Does that apply to updates from UCM/Cbus also as that is what is causing lots of entries in the log at regular intervals.



 Current time is 08:28 pmPage:    1  2  Next Page Last Page  
Top




UltraBB 1.172 Copyright © 2007-2014 Data 1 Systems