search

emsesp / EMS-ESP32

ESP32 firmware to read and control EMS and Heatronic compatible equipment such as boilers, thermostats, solar modules, and heat pumps
https://emsesp.github.io/docs
GNU Lesser General Public License v3.0
548 stars 96 forks source link

Wrong UTC time #412

Closed vmonkey closed 2 years ago

vmonkey commented 2 years ago

Bug description After installing the 3.4.0b9 version (updating from 3.3.1 today), ems-esp shows wrong UTC time. It is shifted by 1 hour, regardless of manual input or NTP. I am in the Prague/Europe time zone. I suspect this to be related to the change of winter-to-summer time.

Steps to reproduce Change time manually or turn on NTP.

Expected behavior Correct time to be shown. Currently, the time is shifted by 1 hour.

Screenshots Correct time is shown in the statusbar. Correct UTC is that time minus 2 hours. Screenshot_2022-03-27-11-33-14-695_com android chrome

Device information { "System": { "version": "3.4.0b9", "uptime": "000+06:14:35.078", "uptime (seconds)": 22475, "freemem": 152, "reset reason": "Software reset CPU / Software reset CPU", "temperature sensors": 0 }, "Network": { "connection": "WiFi", "hostname": "ems-esp", "SSID": "hodnekrabic", "BSSID": "D8:07:B6:C8:96:B6", "RSSI": -53, "MAC": "7C:87:CE:49:A3:14", "IPv4 address": "192.168.68.113/255.255.255.0", "IPv4 gateway": "192.168.68.1", "IPv4 nameserver": "0.0.0.0" }, "Status": { "bus status": "connected", "bus protocol": "HT3", "bus telegrams received (rx)": 25378, "bus reads (tx)": 6422, "bus writes (tx)": 19, "bus incomplete telegrams": 0, "bus reads failed": 0, "bus writes failed": 0, "bus rx line quality": 100, "bus tx line quality": 100, "MQTT status": "connected", "MQTT publishes": 10066, "MQTT publish fails": 0, "temperature sensors": 0, "temperature sensor reads": 0, "temperature sensor fails": 0, "analog sensors": 0, "API calls": 2, "API fails": 0 }, "Devices": [ { "type": "Boiler", "name": "Condens 2500/Logamax/Logomatic/Cerapur Top/Greenstar/Generic HT3", "device id": "0x08", "product id": 95, "version": "18.14", "entities": 64, "handlers received": "0x10 0x11 0x15 0x1C 0x18 0x19 0x1A 0x35 0x34", "handlers fetched": "0x14 0x16 0x33", "handlers pending": "0xC2 0x26 0x2A" }, { "type": "Thermostat", "name": "RC300/RC310/Moduline 3000/1010H/CW400/Sense II", "device id": "0x10", "product id": 158, "version": "18.05", "entities": 64, "handlers received": "0x06 0xA2 0x02BB 0x02BC 0x02BD 0x02BE 0x02BF 0x02C0 0x031D 0x0267", "handlers fetched": "0x02A5 0x02B9 0x02AF 0x029B 0x02A6 0x02BA 0x02B0 0x029C 0x02F5 0x031B 0x023A 0x0240", "handlers pending": "0xA3 0x12 0x0471 0x0472 0x02A7 0x02B1 0x029D 0x0473 0x02A8 0x02B2 0x029E 0x0474 0x02A9 0x02B3 0x029F 0x0475 0x02AA 0x02B4 0x02A0 0x0476 0x02AB 0x02B5 0x02A1 0x0477 0x02AC 0x02B6 0x02A2 0x0478 0x031E" }, { "type": "Mixer", "name": "MM100", "device id": "0x21", "product id": 160, "version": "24.05", "entities": 4, "handlers received": "0x02D8" }, { "type": "Controller", "name": "HT3", "device id": "0x09", "product id": 95, "version": "18.14", "entities": 0 } ] }

Additional context None

Ferenc- commented 2 years ago

Currently I can see the exact same problem on an on older version namely v3.3.0. So I think the issue is not limited to the aforementioned versions.

Ferenc- commented 2 years ago

After reading this comment, I concuded, that the clock on my RC30 thermostat also seems to be unaware of the daylight saving time, and I guess that needs to be manually corrected?

proddy commented 2 years ago

I can only say that on 3.3.1 I did not observe the issue yesterday.

its the same code since v3.0 and I'm sure after 2am you would have seen the same issue. Can you try a different NTP server like one from https://www.pool.ntp.org/zone/europe

vmonkey commented 2 years ago

@proddy Thanks, cz.pool.ntp.org works fine for me.

MichaelDvP commented 2 years ago

Regarding the manual time setting the dst is not calculated and give wrong setting. I'm not sure if it is better/possible to extract this from timezone-setting or add a checkbox to set dst.

vmonkey commented 2 years ago

@MichaelDvP I believe that having a reliable default NTP time would also be welcome since the time syncs with thermostats and, as a consequence, predefined heating schedule shifts. And such shift/incorrect time is hard to recognize and can not be fixed by correcting time on the physical termostat (it syncs back).

MichaelDvP commented 2 years ago

I've fixed the manual setting with dst. I can not reproduce the NTP issue, it's working for me. I've tried different servers, internal and external, always the time is correct. The only small issue it the NTP status is show active it service is started, there is no check if the time is received. If i set a non-existing server the status shows active, but time is never set.