search

klausahrenberg / WThermostatBeca

Replaces original Tuya firmware on Beca thermostat with ESP8266 wifi module
397 stars 97 forks source link

NTP time offset seems not to be set correctly #297

Closed Gulpman closed 1 year ago

Gulpman commented 1 year ago

Hi, I am having issues with the time being set via ntp and the time zone server. I am using Avatto ME81AH thermostats with firmware 1.25beta. Menu "configure clock" is set as following:

NTP server: de.pool.ntp.org (*) Get time zone via internet Time zone server: http://worldtimeapi.org/api/ip

Here is the reply from http://worldtimeapi.org/api/ip:

{
   "abbreviation":"CEST",
   "client_ip":"xxxx:xxxx:xxxx:x:xxxx:xxx:xxxx:xxxx",
   "datetime":"2023-03-26T16:05:33.877460+02:00",
   "day_of_week":0,
   "day_of_year":85,
   "dst":true,
   "dst_from":"2023-03-26T01:00:00+00:00",
   "dst_offset":3600,
   "dst_until":"2023-10-29T01:00:00+00:00",
   "raw_offset":3600,
   "timezone":"Europe/Berlin",
   "unixtime":1679839533,
   "utc_datetime":"2023-03-26T14:05:33.877460+00:00",
   "utc_offset":"+02:00",
   "week_number":12
}

where in "daytime" the correct local time, 16:05h is shown. If you take the unixtime, add the utc_offset of 7200 you get the local time as well, so the reply from http://worldtimeapi.org/api/ip seems to be fully correct., or where if you add 7200 seconds to the utc unixtime (1679839533) it results to a timestamp of 1679846733 which would be 16:05h as well.

However, if I compare this to what the thermostat is putting out via mqtt on topic thermostats/wc_Thermostat/clock/properties, the following payload is sent:

{
   "ntpServer":"de.pool.ntp.org",
   "timeZoneServer":"http://worldtimeapi.org/api/ip",
   "epochTime":1679843074,
   "epochTimeFormatted":"2023-03-26 15:04:34",
   "validTime":true,
   "timezone":"Europe/Berlin"
}

which is definitively wrong, as it is one hour behind.

It seems this issue has been also adressed in topic #16 but was closed.

Any help appreciated. Best, Sascha

dwarning commented 1 year ago

Can't not really contribute, but I have same problem with the fork from AlbertWeterings v1.0.11 Beta and the "Timezone via internet" setting.

Switching to "Fixed offset" and DST calculation show another issue ( #298 ).

klausahrenberg commented 1 year ago

'Fixed offset issue' is now fixed in v1.35. Request over 'http://worldtimeapi.org/api/ip' is not always successful - then the hour is not correct and you will only see the NTP server result. Look for error messages from Thermostat over MQTT. However, please also try v1.35 in this case - some issues at clock were fixed there too.

helmar74 commented 1 year ago

IF I update from 1.34 to 1.35 do I have to manual reconfigure the device, or are all settings (including wifi) kept?

Gulpman commented 1 year ago

'Fixed offset issue' is now fixed in v1.35. Request over 'http://worldtimeapi.org/api/ip' is not always successful - then the hour is not correct and you will only see the NTP server result. Look for error messages from Thermostat over MQTT. However, please also try v1.35 in this case - some issues at clock were fixed there too.

Hi @klausahrenberg thank you for the hint with V1.35 and adressing the issue there. I will give this a try when I'm back at home and let you know if that fixed the issue.

klausahrenberg commented 1 year ago

IF I update from 1.34 to 1.35 do I have to manual reconfigure the device, or are all settings (including wifi) kept?

Update from 1.34 to 1.35 > No WIFI settings update needed, but device configuration Update from older version than 1.34 to 1.35 > Wifi and device settings need to be reconfigured

Gulpman commented 1 year ago

To better understand the writings below: I did the update yesterday in the afternoon and am writing this the next morning :)

Afternoon

I updated all seven thermostats to v1.35: five of them do get the correct time, two don't (ku_Thermostat and sz_Thermostat). These two are one hour behind the correct local time.

I checked the output of http://worldtimeapi.org/api/ip (on my PC though): It constantly is returning the correct values. @klausahrenberg : as you are saying the request is sometimes not succsessful - that means the request from the sensor and not that the source (http://worldtimeapi.org/api/ip) is not answering? How can I check, what the sensor really got from the URL above?

Here's the mqtt-message from ku_Thermostat (sz_Thermostat was the same except the device specific stuff): topic: thermostats/ku_Thermostat/clock/properties

{
    "ntpServer":"de.pool.ntp.org",
    "timeZoneServer":"http://worldtimeapi.org/api/ip",
    "epochTimeFormatted":"2023-03-27 14:49:16",
    "validTime":true,
    "timezone":""
}

It seems these two sensors were missing the timezone value in the mqtt-message. They were displaying 13:49h on the display.

The other five sensors (which display the time correctly) have timezone: "Europe/Berlin" set in this message, resulting in the correct time (here 14:49:16).

Evening

Somehow one of the thermostats (sz_Thermostat) managed to get the correct time. Now the timezone setting is set correctly to Europe/Berlin in the mqtt message. ku_Thermostat still has the wrong time BUT the timezone vaule is also set correctly to Europe/Berlin in it's mqtt message!

next morning

When I woke up I checked the time at sz_Thermostat and it was still correct. ku_Thermostat was still showing the wrong time. After a few hours sz_Thermostat switched temporarily back to the wrong time (one hour back) whilst the timezone setting is sent correctly! (I checked all /clock/properties messages for this specific sensor!). Here's the message from when I recognized the time change: topic: thermostats/sz_Thermostat/clock/properties

{
   "ntpServer":"de.pool.ntp.org",
   "timeZoneServer":"http://worldtimeapi.org/api/ip",
   "epochTimeFormatted":"2023-03-28 09:12:43",
   "validTime":true,
   "timezone":"Europe/Berlin"
}

Whilst in the display 8:12h was shown.

After a while it switched back to the correct local time (e.g. it currently is 9:56h and the thermostat is showing 9:56h).

The thermostat in the kitchen (ku_Thermostat) is receiving the correct messages as well (with timezone) but lags constantly one hour behind.

Any idea how I can further debug to help finding the issue?

I tried to reboot it, in the hope it would get a new time package then but without success. Is there a possibility to force getting the time?

klausahrenberg commented 1 year ago

Please use the option "Use fixed offset to UTC time" and then "Calculate day saving time". Leave default values as it is, they are for "Europe/Berlin" zone by default. Values are: Fixed offset to UTC: 60 / Offset to standard time: 60 / Month: 10; 3 / Week: 0; 0 / Weekday: 0; 0 / Hour: 3; 2

Please test on your devices with these settings, if hour is still different between devices.

Gulpman commented 1 year ago

Please use the option "Use fixed offset to UTC time" and then "Calculate day saving time". Leave default values as it is, they are for "Europe/Berlin" zone by default. Values are: Fixed offset to UTC: 60 / Offset to standard time: 60 / Month: 10; 3 / Week: 0; 0 / Weekday: 0; 0 / Hour: 3; 2

Please test on your devices with these settings, if hour is still different between devices.

@klausahrenberg I did so... and a few things more ;-)

For the debugging process I alterend the time settings to see what happens. Topic - if not mentioned otherwise - is thermostats/sz_Thermostat/clock/properties

Automatic settings

{
   "ntpServer":"de.pool.ntp.org",
   "timeZoneServer":"http://worldtimeapi.org/api/ip",
   "epochTimeFormatted":"2023-04-03 11:34:38",
   "validTime":true,
   "timezone":"Europe/Berlin"
}

Display shows 10:34h

Manual settings

Fixed offset to UTC in minutes: 60 & Offset to standard time in minutes: 60

{
   "ntpServer":"de.pool.ntp.org",
   "epochTimeFormatted":"2023-04-03 11:36:43",
   "validTime":true
}

Display shows 10:34h

Fixed offset to UTC in minutes: 120 & Offset to standard time in minutes: 60

{
   "ntpServer":"de.pool.ntp.org",
   "epochTimeFormatted":"2023-04-03 12:39:11",
   "validTime":true
}

Display shows 10:34h

Fixed offset to UTC in minutes: 60 & Offset to standard time in minutes: 120

{
   "ntpServer":"de.pool.ntp.org",
   "epochTimeFormatted":"2023-04-03 12:45:12",
   "validTime":true
}

Display shows 10:34h

Fixed offset to UTC in minutes: 120 & Offset to standard time in minutes: 120

{
   "ntpServer":"de.pool.ntp.org",
   "epochTimeFormatted":"2023-04-03 13:47:33",
   "validTime":true
}

Display showed 13:47 for a while (30 secs to 90secs?). Then it switched back to 10:47 all of a sudden. No further mqtt message was received! When I returned to the room to look at the display it was at 13:47h and switched back to 10:47after a while again - where it resides stable to 10:xx since then... I double checked - no mqtt messages for thermostats/sz_Thermostat/clock/properties were received.

I honestly have no clue what's going on here. If the above test sequence gives you an idea, please let me know.

Would it make sense to add time related info to the info screen of the web interface? E.G: the currently received (set) UTC, local time and summer time (yes/no) info? For me I'm still not quite sure if the above mqtt message reflects what the thermostat received or what it is reading out internally.

Again, any help is appreciated.

Gulpman commented 1 year ago

I did some more tests. It seems that these two sensors only respond to a NTP time update when the sensor is physically separated from power. IF it gets the correct time then this time is kept stable (now for three days). If it DOES NOT get the time correct, I can try to modify it and reboot the thermostat but without any luck. If I then switch power off and on again there is at least the chance it gets the right time. If not - power off again and repeat until the correct NTP time is received. Hope it helps someone having the same strange issue.