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
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!
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.
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.
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
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.
The cbus clocks and timekeeping application describes the behaviour of 2 Time masters on the bus
http://training.clipsal.com/downloads/Op...cation.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
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.
Quote: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
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.