DST problem

[Guest]

I have been having problems with Comfort failing to apply the hour DST offset since the clocks went forward on the weekend.
I checked the SNTP settings in CSM and all seems fine. The correct time is shown and it is set to send the time to Comfort every twenty minutes. It was necessary to use the \'Submit\' button before Comfort displayed the correct time. Unfortunately, it forgets again at the beginning of each day.\'The event log clearly shows what is happening. Up until midnight there are regular \'Date/Time Change UCM 1\' entries every 20 minutes with the final one logged at 23:52. The first one after midnight reveals the issue - it is logged at 23:12 so Comfort has clearly stopped applying the DST offset at this point. The time on the keypad confirms this. Curiously, further Date/Time changes also cease thereafter. To correct the time, it is necessary to manually submit it again via CSM, after which the regularly time updates recommence until just after midnight.
Any ideas what is going on?
I never had this problem last year but I have updated the firmware since which could account for the current problems.
The Controller firmware is 7.093 and the UCM firmware is 7.076 and Eth3GE-v2.20 
Craig

[slychiu]

The topic at http://www.comfortforums.com/view_topic.php?id=4026&forum_id=113 explains how the ETH03 works with Daylight savings

ETH03 sends the time without Daylight saving adjustments to Comfort. Comfort will make the adjustment for DST based on the Schedule> sunrise/sunset times. So make sure that you have the correct settings for your city/location in Sunrise/Sunset
You have the latest firmware for everything so it should work in this way

[Guest]

Thank you for your reply. I am aware of how the system is meant to work and my location is correctly programmed in Sunrise/Sunset.

The event log shows that Comfort is correctly applying the DST offset throughout the day until it crosses midnight but then reverts back upon the next Date/Time Change from the UCM. I studied this closely last night before reporting the issue and Comfort\'s time was correct before and after midnight until that Date/Time Change was received.

As I said before, the system was working perfectly last year before, during and after the DST period and the only thing that\'s changed is firmware.

[slychiu]

can you send your cclx file to support@cytech.biz please

[Guest]

Another curiosity. Despite the event log showing regular automatic Time/Date Change entries, I just found Comfort\'s time to be out by 43 seconds. I did a manual change using the submit button in CSM and it was then 50 seconds out! So I did another manual change after which it was 35 seconds out.


So it would appear there is something very odd going with time in general on my system, not just with DST.

[slychiu]

I think there may be a problem with sunday 27 March only where the time update is wrong
Do you still have the wrong time today?


does anyone else have this problem?

[Guest]

I observed the same thing earlier today - the time and date was correct both sides of midnight until the first Date/Time Change was received from the UCM. At that point, the time jumps back an hour.
I manually sent the date and time from Comfigurator to correct things and then disabled time updates from the UCM to prevent this recurring each day. This is only intended as a short term fix while a proper solution is found.

[slychiu]

that seems strange especially if nobody else sees the issue

can you re-upgrade the ETh03 to 2.20?

[Guest]

Yes, I\'ll try that and see how I get on.

[Guest]

Unfortunately, that didn\'t work.

However, I can shed some more light on what is going on. It\'s more complicated than I first thought. As before, the time jumped back an hour on receipt of the first Date/Time Change from CSM after midnight. What I hadn\'t realised though is that after it crosses midnight for the second time an hour later, the next Date/Time Change results in DST being correctly applied so the time jumps forward an hour.

Although I hadn\'t noticed this before, there is no doubt in my mind that it has been doing this all week because it explains why my heating was failing to turn off at 00.59 am since the clocks went forward. This would also possibly explain why other people haven\'t noticed this bug as the time is only wrong for around one hour a day and if they don\'t have anything timed to happen in that window, they would remain blissfully unaware of what is actually going on.