Timezone not properly read from config

[caco3]

Discussed in #2166

^{Originally posted by FastFrank March 12, 2023}

The Problem

Timezone in Configuration:

CET-1CEST,M3.5.0,M10.5.0/3

Log from MQTT last night: (12-03-2023)

JSON gewijzigd in { "value": "18839.45", "raw": "18839.45", "pre": "18839.45", "error": "no error", "rate": "0.008000", "timestamp": "2023-03-12T03:04:41+0200" }
02:06:01 - 8 uur geleden
JSON gewijzigd in { "value": "18839.41", "raw": "18839.41", "pre": "18839.41", "error": "no error", "rate": "0.004000", "timestamp": "2023-03-12T01:59:41+0100" }
02:01:00 - 8 uur geleden

Version

15.0.3

Logfile

[0d00h00m04s] 2023-03-12T08:52:26	<INF>	[SNTP] TimeServer: nl.pool.ntp.org
[0d00h00m04s] 2023-03-12T08:52:26	<INF>	[SNTP] Configuring NTP Client...
[0d00h00m04s] 2023-03-12T10:52:26	<INF>	[SNTP] Time zone set to CET-1CEST
[0d00h00m04s] 2023-03-12T10:52:26	<INF>	[SNTP] Time is already set: 2023-03-12 10:52:26

Expected Behavior

Change the +1:00 to +02:00 on Month 3 last week day 0

in the log:
[SNTP] Time zone set to CET-1CEST,M3.5.0,M10.5.0/3
instead of:
[SNTP] Time zone set to CET-1CEST

Screenshots

No response

Additional Context

No response

[FastFrank]

I was looking in other issues like #2150 and there the log was:

[0d00h00m04s] 2023-03-08T19:48:23 [SNTP] TimeZone not set, using default: CET-1CEST,M3.5.0,M10.5.0/3
[0d00h00m04s] 2023-03-08T19:48:23 [SNTP] Configuring NTP Client...
[0d00h00m04s] 2023-03-08T20:48:23 [SNTP] Time zone set to CET-1CEST,M3.5.0,M10.5.0/3
[0d00h00m04s] 2023-03-08T20:48:23 [SNTP] Time is already set: 2023-03-08 20:48:23

So i made the field Timezone empty but still checked and then my device kept on rebooting.
I had to remove the SD-card and put a ; in front of TimeZone =

[System]
TimeZone =

this will make the device unreachable...

[FastFrank]

Now it is not set... the log shows:

[0d00h00m04s] 2023-03-12T14:22:34 [SNTP] TimeServer: nl.pool.ntp.org
[0d00h00m04s] 2023-03-12T14:22:34 [SNTP] TimeZone not set, using default: CET-1CEST,M3.5.0,M10.5.0/3
[0d00h00m04s] 2023-03-12T14:22:34 [SNTP] Configuring NTP Client...
[0d00h00m04s] 2023-03-12T15:22:34 [SNTP] Time zone set to CET-1CEST,M3.5.0,M10.5.0/3
[0d00h00m04s] 2023-03-12T15:22:34 [SNTP] Time is already set: 2023-03-12 15:22:34

Remark that now it logs the full CET-1CEST,M3.5.0,M10.5.0/3 instead of only CET-1CEST...

[caco3]

The main problem is the config parser, it seems to split at the ,...

[caco3]

So i made the field Timezone empty but still checked and then my device kept on rebooting. I had to remove the SD-card and put a ; in front of TimeZone =

It then uses the default value which matches for Germany)

I think I fixed it now, please test https://github.com/jomjol/AI-on-the-edge-device/actions?query=branch%3Afix-timezone-config-parser and let me know.

this will make the device unreachable...

I can not reproduce this!
Do you have logs?

[FastFrank]

I left the Timezone empty in the configuration. In the config.ini it had:

[System]
TimeZone =
TimeServer = nl.pool.ntp.org

After that change it kept rebooting... the log is from the serial port:

16:05:04.809 -> I (3826) gpio: GPIO[25]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:2
16:05:04.809 -> I (3826) cam_hal: cam init ok
16:05:04.809 -> I (3826) sccb: pin_sda 26 pin_scl 27
16:05:04.809 -> I (3826) sccb: sccb_i2c_port=1
16:05:04.809 ->
16:05:04.809 -> I (3826) gpio: GPIO[32]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
16:05:04.842 -> I (3866) camera: Detected camera at address=0x30
16:05:04.842 -> I (3866) camera: Detected OV2640 camera
16:05:04.842 -> I (3866) camera: Camera PID=0x26 VER=0x42 MIDL=0x7f MIDH=0xa2
16:05:04.907 -> I (3946) cam_hal: buffer_size: 32768, half_buffer_size: 4096, node_buffer_size: 2048, node_cnt: 16, total_cnt: 15
16:05:04.939 -> I (3946) cam_hal: Allocating 61440 Byte frame buffer in PSRAM
16:05:04.939 -> I (3946) cam_hal: cam config ok
16:05:04.939 -> I (3956) ov2640: Set PLL: clk_2x: 0, clk_div: 0, pclk_auto: 0, pclk_div: 8
16:05:07.028 -> I (6066) MAIN: Using SDMMC peripheral
16:05:07.092 -> Name: APPSD
16:05:07.092 -> Type: SDHC/SDXC
16:05:07.092 -> Speed: 20 MHz
16:05:07.092 -> Size: luMB
16:05:07.158 ->
16:05:07.158 -> abort() was called at PC 0x401f108e on core 0
16:05:07.158 ->
16:05:07.158 ->
16:05:07.158 -> Backtrace:0x400837bd:0x3ffc2a600x4008e929:0x3ffc2a80 0x40095109:0x3ffc2aa0 0x401f108e:0x3ffc2b10 0x40188547:0x3ffc2b30 0x40174736:0x3ffc2b50 0x4017618b:0x3ffc2b70 0x401762db:0x3ffc2b90 0x400dc3df:0x3ffc2bc0 0x400d4ed4:0x3ffc2cc0 0x402145ce:0x3ffc2df0
16:05:07.158 ->
16:05:07.158 ->
16:05:07.158 ->
16:05:07.158 ->
16:05:07.158 -> ELF file SHA256: e177a49e545929ac
16:05:07.158 ->
16:05:07.158 -> Rebooting...
16:05:07.190 -> ets Jul 29 2019 12:21:46

[caco3]

Hmm, I cant see a correlation with your crash on the timezone.

[caco3]

ok, I got it now, please check the next build.

[FastFrank]

Thank you!

[friedpa]

tested the build, the time is back where it should be:

[TopGoalVl]

In October, measurement data may then be overwritten or saved twice. Does the time zone CET or UTC standard time work correctly when parsing in version 14.0.3? If so, I'll make the switch to UTC+1 immediately. Switch setup to UTC+1, turn off ESP for an hour, then restart.

TZ data string: UTC+1
The UTC+1 time zone applies to Central European Time.

This is not really important for the water meter, because perhaps no water is consumed during the time change. With gas and electricity meters, it is important to me that the data is saved correctly. I don't need summer / winter time when saving the measured values, UTC+1 is enough for me.

Will this work in version 14.0.3?

[caco3]

When using MQTT and Homeassistant, Homeassistant does not care about the devices time at all, it uses its own internal time. So the time overlapping due to the daylight saving time change must be handled there, although on a quick search I could not find out how they solve it.

When writing directly to InfuxDB, I think it uses UTC (see #1991 (comment)), so there again it should not be an issue.

[caco3]

As for your question regarding v14.0.3, please start switching to v15 as we are not going to do modification/fixing of older versions!

[TopGoalVl]

As for your question regarding v14.0.3, please start switching to v15 as we are not going to do modification/fixing of older versions!

I think the TZ string for UTC I need is UTC+1 or UTC+01:00:00. I understood that the comma was not processed correctly when parsing. But I don't need that for CET standard time. So it should work in V 14.0.3.

I'll only switch to version 15.x.x in April, otherwise I'll get the switch to daylight saving time again. I want to avoid that.

[caco3]

I'll only switch to version 15.x.x in April, otherwise I'll get the switch to daylight saving time again. I want to avoid that.

That is a valid point.
In current rolling it is solved and we will release a bugfix release in the next days which will include this fix.