Feature Request: dedicated TZ option for setting thermostat time

[ralfbergs]

DESCRIPTION

I run my EMS-ESP on timezone UTC to avoid "time warps" when the time switches between DST and standard time. (I do this for all my "servers" or other devices that log into my central logging solution, Graylog.)

When I want to set my thermostat's time to the current NTP time, it uses the same timezone which is obviously undesired, because on the thermostat for sure I want to have the localtime.

So my feature request is to have an extra timezone field for the timezone to be used when updating the thermostat time.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Searched the issue in issues
• Searched the issue in discussions
• Searched the issue in the docs
• Searched the issue in the chat
• Provide the System information in the area below, taken from http://<IP>/api/system

{"system":{"version":"3.8.3-dev.8","uptime":"001+02:16:55.689","uptimeSec":94615,"resetReason":"Software reset CPU / Software reset CPU","platform":"ESP32","cpuType":"ESP32-D0WD-V3","arduino":"ESP32 Arduino v2.0.17","sdk":"v4.4.7-dirty","freeMem":147,"maxAlloc":107,"freeCaps":4163,"usedApp":2381,"freeApp":2291,"partition":"app1","flash_chip_size":16384,"psram":true,"psramSize":4093,"freePsram":4049,"model":"BBQKees Electronics E32V2.2 rev.2.2/2025081","txpause":false,"gpios_allowed":"2, 4, 5, 14, 32, 34, 36, 39","gpios_in_use":"4, 5, 14, 32, 34, 36, 39","gpios_available":"2"},"network":{"network":"WiFi","hostname":"ems-esp","RSSI":-50,"WIFIReconnects":0,"BSSID":"set","TxPowerSetting":0,"staticIP":false,"lowBandwidth":false,"disableSleep":true,"enableMDNS":true,"enableCORS":false},"ntp":{"NTPstatus":"connected","enabled":true,"server":"time.google.com","tzLabel":"Europe/Berlin","timestamp":1782757544,"NTPStatus":"connected"},"ap":{"provisionMode":"disconnected","ssid":"ems-esp","security":"wpa2","channel":7,"ssidHidden":false,"maxClients":4,"localIP":"192.168.4.1","gatewayIP":"192.168.4.1","subnetMask":"255.255.255.0"},"mqtt":{"MQTTStatus":"connected","MQTTPublishes":58529,"MQTTQueued":0,"MQTTPublishFails":0,"MQTTReconnects":0,"enabled":true,"clientID":"esp32-b9ffc9ec","keepAlive":60,"cleanSession":false,"entityFormat":3,"base":"ems-esp","discoveryPrefix":"homeassistant","discoveryType":0,"nestedFormat":1,"haEnabled":true,"mqttQos":0,"mqttRetain":false,"publishTimeHeartbeat":60,"publishTimeBoiler":10,"publishTimeThermostat":10,"publishTimeSolar":10,"publishTimeMixer":10,"publishTimeWater":10,"publishTimeOther":60,"publishTimeSensor":10,"publishSingle":false,"publish2command":false,"sendResponse":false},"syslog":{"enabled":true,"syslogStarted":true,"syslogLevel":"debug","syslogIP":"192.168.2.7","syslogQueue":0},"modbus":{"enabled":false},"sensor":{"temperatureSensors":1,"temperatureSensorReads":18922,"temperatureSensorFails":0},"analog":{"enabled":true,"analogSensors":2,"analogSensorReads":10,"analogSensorFails":0},"api":{"APICalls":0,"APIFails":0},"bus":{"busStatus":"connected","busProtocol":"HT3","busTelegramsReceived":126432,"busReads":25231,"busWrites":2,"busIncompleteTelegrams":0,"busReadsFailed":2,"busWritesFailed":0,"busRxLineQuality":100,"busTxLineQuality":100},"settings":{"boardProfile":"E32V2_2","locale":"en","txMode":1,"emsBusID":11,"showerTimer":false,"showerMinDuration":180,"showerAlert":false,"hideLed":false,"noTokenApi":false,"readonlyMode":false,"fahrenheit":false,"dallasParasite":false,"boolFormat":1,"boolDashboard":1,"enumFormat":1,"analogEnabled":true,"telnetEnabled":true,"maxWebLogBuffer":100,"modbusEnabled":false,"forceHeatingOff":false,"developerMode":true},"devices":[{"type":"boiler","name":"Cerapur ZSB 14-3 A ..","deviceID":"0x08","productID":95,"brand":"Junkers","version":"18.08","entities":69,"handlersReceived":"0x10 0x11 0x15 0x1C 0x18 0x19 0x34 0x04","handlersFetched":"0x14 0x16 0x33","handlersPending":"0xBF 0xC2 0xC6 0x1A 0x35 0x27 0x2A 0x2E 0x3B","handlersIgnored":"0x1E 0x23"},{"type":"thermostat","name":"FW200","deviceID":"0x10","productID":106,"brand":"Junkers","version":"12.12","entities":48,"handlersReceived":"0x06","handlersFetched":"0x016F 0x0170 0x0165 0x0166 0x01D3 0x011E","handlersPending":"0xA3 0xA2 0x12 0x13 0x0171 0x0172 0x0167 0x0168 0xBB 0x23","handlersIgnored":"0xBE"},{"type":"mixer","name":"IPM","deviceID":"0x21","productID":100,"brand":"Junkers","version":"20.07","entities":4,"handlersReceived":"0x010C","handlersPending":"0x011E","handlersIgnored":"0x23 0xBE 0x010B"},{"type":"solar","name":"ISM1","deviceID":"0x30","productID":101,"brand":"Junkers","version":"23.03","entities":8,"handlersFetched":"0x0103 0x0101","handlersPending":"0x0104","handlersIgnored":"0xBE"},{"type":"controller","name":"HT3","deviceID":"0x09","productID":95,"brand":"","version":"18.08","entities":0},{"type":"temperaturesensor","name":"temperaturesensor","entities":1},{"type":"analogsensor","name":"analogsensor","entities":2}]}

TO REPRODUCE

Steps to reproduce the behavior:

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.

SCREENSHOTS

If applicable, add screenshots to help explain your issue.

ADDITIONAL CONTEXT

Add any other context about the issue here.

(Please remember to close the issue when it has been addressed)

[proddy]

how about if we adjust the date/time command to also accept ntp[+,-]<n> so you could send ntp-1 ?

[ralfbergs]

how about if we adjust the date/time command to also accept ntp[+,-]<n> so you could send ntp-1 ?

Would be a pragmatic solution (work-around) and definitely better than the current status quo, but not as comfortable as a fully automatic solution that does the calculation itself (as the calculation is different in DST than it is in standard time)... ;-)

I'll leave it up to you as I can't make any "demands".

[MichaelDvP]

The clocks are automatic synced both ways, so it's not easy to just add a command.

1. If thermostat clock is not set after powercut it is set from NTP. Important because the heating stays off until clock is set. Bad if you're not at home after a powercut.
2. If emsesp does not have a time setting and thermostat clock is set, emsesp clock is set to thermostat clock value.
3. On every clock telegram the clocks are compared and on difference > 15 sec and NTP active the thermostat clock is corrected.

We can remove the 3. point, but the first two are important and should not be removed.

[ralfbergs]

Thank you for your response.

Before I respond to your comments, let me mention that I don't have a lot of experience with this topic, so I might be missing something.

My use case is the following: I noticed that my heating's internal clock was off by several minutes, which is why I wanted to change it via Home Assistant and its EMS-ESP integration.

The clocks are automatic synced both ways, so it's not easy to just add a command.

I'm not sure what you mean. Which "clocks" (plural) are you talking about? The heating's internal clock and EMS-EPS's internal clock? Why would they be synced "both ways?"

My understanding is that "clock syncing" should only occur as follows:

1. If enabled and if available, EMS-ESP's internal clock should be synced by NTP.
2. If triggered by the user, the heating's internal clock should be synced by EMS-ESP (i. e. the EMS-ESP time should be sent to the heating and applied there)

Is that what you mean?

I'm not asking for a fully automatic, unattended, periodic sync in the direction of step 2 above. (Don't get me wrong, it would great to have, but I'm not asking for it. It may simply be too much, if we want to keep EMS-ESP as light-weight as possible.)

1. If thermostat clock is not set after powercut it is set from NTP. Important because the heating stays off until clock is set. Bad if you're not at home after a powercut.

You mean it is set once if for whatever reason it doesn't seem to have the current time?

2. If emsesp does not have a time setting and thermostat clock is set, emsesp clock is set to thermostat clock value.

Ah, really? I wasn't aware. So this is what you mean by "two-way-sync?" Well, it seems to be a proper naming then. ;-)

3. On every clock telegram the clocks are compared and on difference > 15 sec and NTP active the thermostat clock is corrected.

In that case I'm even more confused. How can it happen under the above circumstances that the heating's time is off by several minutes, while the EMS-ESP has the correct time via NTP?

(And, BTW, it is great to have that level of clock syncing, I wasn't aware of it!)

(Sorry for the length of my response...)

[VlastiBroucek]

3. On every clock telegram the clocks are compared and on difference > 15 sec and NTP active the thermostat clock is corrected.
   We can remove the 3. point, but the first two are important and should not be removed.

OMG, please NO! Most thermostats would never get really correct time!!!

1. If thermostat clock is not set after powercut it is set from NTP. Important because the heating stays off until clock is set. Bad if you're not at home after a powercut.

I do not think this statement is correct. How could thermostat that is not connected to internet (lots of thermostats are "dumb") set time via NTP??? My CR50 holds clock ticking for several hours during power outage.

[MichaelDvP]

I do not think this statement is correct.

It's shortend: emsesp sets thermostat clock if (a) the thermostat clock has not-valid bit set, and (b) emsesp has NTP connection.

[VlastiBroucek]

Now it makes sense...

Still my CR50 was holding time for reasonable long power cut periods even before I started using EMS-ESP.

[MichaelDvP]

till my CR50 was holding time for reasonable long power cut periods even before I started using EMS-ESP.

MY RC35 buffers the clock for some hours, but after a 5h power cut some years ago i have to set the clock (and than add the automatic setting for this case).

I think the best solution is to add a global TZ setting for the thermostat and convert timezones before comparing the emsesp- and thermostat time. And leave command and corrections unchanged, only using the different zones. Maybe this way:

Testing with this settings the automatic correction (thermostat clock was manually set wrong before)

2026-07-03T09:16:31.322 D 52: [telegram] New Rx telegram, message length 8
2026-07-03T09:16:31.325 I 54: [thermostat] thermostat time correction of 34 sec from ntp
2026-07-03T09:16:31.325 I 55: [thermostat] Setting date and time: 03.07.2026-10:16:31-4-2

[VlastiBroucek]

To be honest, I am not sure why should EMS-ESP get another (in my opinion) unnecessary complication just because one user wants to keep everything on UTC. I can hardly think about any other IoT device that would accommodate such a request.

EDIT: Also, AFAIK, GrayLog unlike Syslog (although IETF Syslog format makes it better) is capable of fixing mixed time zones internally (Pipeline Processors).

rule "Fix US-West Firewall Timezone"
when
    has_field("message") && regex("^us-west-", to_string($message.source)).matches == true
then
    // Parse the legacy date string but explicitly force the America/Los_Angeles zone
    let fixed_timestamp = parse_date(
        value: to_string($message.timestamp), 
        pattern: "MMM dd HH:mm:ss", 
        timezone: "America/Los_Angeles"
    );
    set_field("timestamp", fixed_timestamp);
end

[MichaelDvP]

To be honest, I am not sure why should EMS-ESP get another (in my opinion) unnecessary complication just because one user wants to keep everything on UTC.

I agree, but i want to avoid that a command ntp[+,-]<n> leads to removing the automatic corrections.
Setting two timezones in the ntp-setting mask will confuse a lot of users. I guess there should be checkbox like [ ] use different timezone for thermostat to activate the input, but adding the lot of translations it too nasty.

[VlastiBroucek]

Sorry, but I have to say this.

You two, @MichaelDvP and @proddy , need to learn how to say strictly NO to more fringe and sometimes ridiculous functionality requests and concentrate more on fixing bugs. The code is becoming more and more fragmented by quickly adding fixes and improvements. I just asked claude to compare dev.6 and dev.8 - cannot do because the way the dev releases are done 😭

One example is my own #3146. There clearly must be some critical change between dev.6 and dev.8 My system has been extremely stable until then. Now it's horrible. Did power cycle (cool reboot) yesterday evening, crashed four times in 12 hours.

I wish I could go back to dev.6. But the way you do your releases, there is no easy way - I would have to set up my own dev environment and compile for myself... From now on, I am going to keep copies of all BINs I ever install, so I can easily downgrade if something like this happens. I'm now going back to stable and see if I will have no crashes just to rule out HW causing the crashes/restarts.

[ralfbergs]

3. On every clock telegram the clocks are compared and on difference > 15 sec and NTP active the thermostat clock is corrected.
   We can remove the 3. point, but the first two are important and should not be removed.

OMG, please NO! Most thermostats would never get really correct time!!!

I just remembered that my heating has a DCF77 receiver, so it will automatically get the current time itself without any internet connection. The receiver is connected to the heating central unit (boiler controller, whatever the proper naming be), and that seems to set the time in the FW200 thermostat.

[ralfbergs]

To be honest, I am not sure why should EMS-ESP get another (in my opinion) unnecessary complication just because one user wants to keep everything on UTC. I can hardly think about any other IoT device that would accommodate such a request.

I definitely agree that my request is a "niche request" which most users will never have, so if you want to decline it because of that, it's fine for me.

EDIT: Also, AFAIK, GrayLog unlike Syslog (although IETF Syslog format makes it better) is capable of fixing mixed time zones internally (Pipeline Processors).

I admit that I hadn't even thought about this, but yes, I could do this. Thanks for suggesting it.

[ralfbergs]

You two, @MichaelDvP and @proddy , need to learn how to say strictly NO to more fringe and sometimes ridiculous functionality requests and concentrate more on fixing bugs. The code is becoming more and more fragmented by quickly adding fixes and improvements.

I definitely support this view. "Stability over feature creep" is a very important value that should always be kept in the backs of our minds.

Should we close this FR now?

[MichaelDvP]

I just remembered that my heating has a DCF77 receiver, so it will automatically get the current time itself without any internet connection.

Check your log in emsesp. Hopefully the module and emsesp does not play ping-pong with setting the clock. Maybe for this case we need to add an option to disable the automatic sync.

[ralfbergs]

I just remembered that my heating has a DCF77 receiver, so it will automatically get the current time itself without any internet connection.

Check your log in emsesp. Hopefully the module and emsesp does not play ping-pong with setting the clock. Maybe for this case we need to add an option to disable the automatic sync.

There is no trace about such "ping-pong" in the log.

Also, if there was some kind of such ping-pong, a time drift of several minutes (which I have observed) could not possibly occur, right?

[ralfbergs]

Here's the logs (failed to attach them in my previous reply, as the GitHub JavaScript was blocked by NoScript):

1st try.csv 2nd try.csv

@MichaelDvP Have you checked the logs? Are the TX errors indeed from trying to set the thermostat time? Can you find out why it caused an error? And then, in the 2nd try, it seems it was successful. But why 3 tries to update the time (or so it seems)?

[MichaelDvP]

Ok, i've found the bug. Please try new build from my repo, it's still dev.10, but updated.

[ralfbergs]

Ok, i've found the bug. Please try new build from my repo, it's still dev.10, but updated.

It's amazing how quickly it fixed the incorrect time -- I thought I'd not "confirmed" the incorrect time I'd set via the thermostat's knob, but it's simply that EMS-ESP was so fast that it corrected the time right away... ;-)

2026-07-06T17:34:39.402 I 24: [thermostat] thermostat time correction 22 seconds from ntp
2026-07-06T17:36:04.981 I 25: [thermostat] thermostat time correction 784 seconds from ntp
2026-07-06T17:36:30.037 I 26: [thermostat] thermostat time correction 629 seconds from ntp
2026-07-06T17:36:30.687 E 27: [emsesp] Last Tx write host reply: 0x4D

I think there may still be some error, I'll attach a logfile snippet to this comment...

20260706T1736.csv

[MichaelDvP]

The write errors are timing issues. You have a Junkers HT3 system, but using EMS Tx-timing. Switch tx-mode to ht3 or auto.

[ralfbergs]

The write errors are timing issues. You have a Junkers HT3 system, but using EMS Tx-timing. Switch tx-mode to ht3 or auto.

Thanks. I think I've never written to the bus so far, this is why I haven't had such issues. ;-)

I've set it to HT3 now, and surprisingly there's no error anymore. ;-)

Many thanks for your great work.

[proddy]

I'll move this Feature Request to Discussions. We hadn't committed to implementing anything, at this point we were just exploring possibilities.