Comfort Automation/ Security System Forums
Date & Time wrong set and repeatedly lost - Printable Version

+- Comfort Automation/ Security System Forums (https://www.comfortforums.com)
+-- Forum: Support (https://www.comfortforums.com/forum-2.html)
+--- Forum: Problems & Troubleshooting (https://www.comfortforums.com/forum-36.html)
+--- Thread: Date & Time wrong set and repeatedly lost (/thread-3974.html)

Pages: 1 2

- Stefan - 09-18-2014

Hello,

I am experiencing a strange issue with the date and time settings of Comfort:
  • I use Windows 7 in an Oracle Virtualbox environment with Comfigurator 3.8.10.0
  • In [font=\"courier new\"]Configuration - Modules and Settings[/font] [font=\"courier new\"]\"UTC+1 Vienna\"[/font] is set as timezone, and the daylight saving (Schedule - ) is set to be active until end of October. UCM-KNX is set to send date and time from Comfort to KNX.
  • Comfort was programmed yesterday evening to display the correct date and time using the [font=\"courier new\"]Transfer - Set Date & Time[/font] option
  • Sometimes during the night an hour was lost, at 06:15 a.m. the Keypad only displayed 05:15 a.m.
  • It is now 09:20 a.m. - I started Comfigurator, and the answer to DT? is:
    DT2014010508203700
Reading the Keypad confirms that also the date is wrong. I am not sure whether this changed simultaneously with the time. But there is more:
  • [font=\"courier new\"]Transfer - PC-->Comfort[/font] (with the Option [font=\"courier new\"]Set Date & Time[/font] selected)
--> Comfigurator gives this pop-up: https://flic.kr/p/oZorcw

...so that would mean all is fine, but differs from the output of DT? and the Keypad display. Clicking YES results in the following conversation on the I/O monitor (excerpts only):

[font=\"courier new\"]> DT20140918092207
< OK[/font]
[font=\"courier new\"][...][/font]
[font=\"courier new\"]> RS
< OK
> LI
< LU00
> LI****
< LU01
> LT01
< OK
> DT
< DT2014010508482700
[/font]
[font=\"courier new\"][...][/font]
[font=\"courier new\"]> DT?
< DT2014010508484200[/font]

Again date and time is not correct. Trying [font=\"courier new\"]Transfer - Set Comfort Date & Time:[/font]
[font=\"courier new\"]> DT20140918095717
< OK
> DT?
< DT2014091809572601
[/font]
[font=\"courier new\"][font=\"verdana\"]This worked.[/font][/font]
Bottomline:
  1. [font=\"courier new\"]Transfer - PC-->Comfort[/font] (with the Option [font=\"courier new\"]Set Date & Time[/font] selected) sets a wrong date (5. Jan 2014) and time (1 hour back).
  2. [font=\"courier new\"]Transfer - Set Comfort Date & Time[font=\"verdana\"] works[/font][/font]
  3. [font=\"courier new\"][font=\"verdana\"]During the night, the time somehow was set back 1 hour without any programming
    [/font][/font]
  4. [font=\"courier new\"][font=\"verdana\"]Simultaneously or later also the date was set back to January[/font][/font]
I can live with 1 and 2, but 3 and 4 make we worry. Any input would be highly appreciated.

Thanks!
Stefan



- Ingo - 09-18-2014

If you have an Eth03 then also make sure it\'s the latest firmware and that the timezone match your PC/VM.

Ingo

- Stefan - 09-18-2014

...a very good point, thanks!  I just saw there is a new NTP sync feature in ETH03, which is configured via the Comfort Server Manager - but my ETH03 is not detected there. I will go on fiddling around with that. Smile

- ident - 09-18-2014

It does look like the ETH03 is changing the time and date due to the wrong settings in STNP

The difference between the 2 methods of settng date and time are when you write to Comfort, there is a reset, and the ETH03 sets the time and date

In Transfer Date and Time to PC there is no reset so the ETH03 does not set the date and time

ETH03 latest firmware is 2.12

Check that Comfort and UCM also are updated to the latest


- Stefan - 09-19-2014

Thank you both for your help, it works now! The following was necessary:
  • Connecting the PC directly to the LAN subnet where Comfort is (so the Server Manager would find the ETH03 interface via 224.0.0.1 multicast packets)
  • In the Virtualbox network setup I had to use  \"Bridge \"instead of \"NAT\" mode (same reason)
  • Upgrade of the ETH03 firmware from 2.09 to 2.12 (resolved the issue with the changing date)
  • Setup of the SNTP function of ETH03: GMT+2 is correct (although I live in a UTC+1 timezone, but we have daylight saving)
The issue was a bit tricky to solve because the Server Manager is quite hidden, the ETH03 interface was not shown (and therefore not configured), and despite lacking configuration the SNTP function of ETH03 was active by default. Additionally, this was overlayed by the 2.09 firmware bug crippling the date.

Thanks again for pointing me to the ETH03!
Stefan



- CTx - 05-26-2020

I am having the same problem (Eth03 sets back time one hour less).
Firmware v2.23. And all the others at latest version.
SNTP configured for europe.ntp.pool.org
Time Zone set for Lisbon,London.

Of course I can change the Timezone, but preferable to set things regularly.
My mistake or Eth03?

- slychiu - 05-26-2020

ETH03 2.23 should have fixed the old problem with time update a few years ago
The time in the UK should have gone forward on SundayETH03 should update the DST setting at 2 AM on SundayCan you check what is the NTP Synchronise Interval and check that the checkbox is checked for Send Time to Comfort
also double check that the settings in Sunset/Sunrise Properties . Set Tines u Latitude/Longitude have the correct settings


- CTx - 05-26-2020

For this testing phase I have set NTP sync interval to 10 min.
I had not previously set Sunset/Sunrise but have set now to my nearest village on the list, and checked the DST.
But, no effect.
I updated Comfort with the changes and set time again.

After 10 min, the time gets back 1 hour.

- slychiu - 05-27-2020

Can someone else in the UK confirm of they have the same problem?


- CTx - 05-27-2020

I should have waited a bit more time !!!

On the keypad on one moment I saw 00.05 (at 01.05) and then the next moment I looked it was 01:18.

So, it seems there was something happening in between (not me, I did not touch it) that adjusted the time to the correct hour value.

Thanks again.