Zigbee time component not syncing with time

ESPHome
1

I am running zigbee on a seeed xiao_ble. I am using zigbee2mqtt. Everything works as expected except for the time component.

esphome:
name: nrf-light-sensor
friendly_name: nrf light sensor

nrf52:
board: xiao_ble

logger:
level: VERBOSE

zigbee:
id: nrf_lux_1
model: “XIAO-LuxSensor-1”

time:

  • platform: zigbee
    id: time_zigbee_1

On boot I see the incorrect time in the logs:

[11:41:39][C][zigbee:227]: Zigbee
[11:41:39][C][zigbee:227]: Wipe on boot: NO
[11:41:39][C][zigbee:227]: Device is joined to the network: YES
[11:41:39][C][zigbee:227]: Sleep time: 1s
[11:41:39][C][zigbee:227]: RX ON when idle: YES
[11:41:39][C][zigbee:227]: Current channel: 11
[11:41:39][C][zigbee:227]: Current page: 0
[11:41:39][C][zigbee:227]: Sleep threshold: 20ms
[11:41:39][C][zigbee:227]: Role: end device
[11:41:39][C][zigbee:227]: Long addr: 0xf4ce365d89e48318
[11:41:39][C][zigbee:227]: Short addr: 0x1388
[11:41:39][C][zigbee:227]: Long pan id: 0xa57b2faa8c3b7210
[11:41:39][C][zigbee:227]: Short pan id: 0x0263
[11:41:40][C][zigbee.time:033]: Zigbee Time
[11:41:40][C][zigbee.time:033]: Endpoint: 1
[11:41:40][C][time:055]: Current time: 1969-12-31 23:59:59

I I update the time via a mqtt message to zigbee2mqtt, I see the following in the logs:

[11:42:30][I][zigbee:114][0x20001f48]: zcl_device_cb id 0, cluster_id 10, attr_id 0, endpoint: 1
[11:42:30][I][zigbee.time:064][0x20001f48]: Synchronize time to 1786732950
[11:42:30][D][time:104]: Synchronized time: 1969-12-31 23:59:59
[11:42:30][D][zigbee.time:082][0x20001f48]: Zcl_device_cb_ status: 0

From the logs it appears that zigbee.time receives the correct unix time stamp of 1786732950. However, the synchronized time is still incorrect. zigbee.time appears to report that there were no issues (status: 0).

The zigbee2mqtt logs indicate that the mqtt message was sent and received. The problem appears to be between the zigbee.time component and the time component. I have tried restart/reset/reboot the various participating addons/integrations/ha etc …

Any thoughts?

2

Likely some conversion bug. Zigbee time doesn’t use unix time count, but starts from beginning 2000 instead of 1970.

3

The error appears to be in the function realtimeclock::synchronize_epoch (RTC_Sync for short). According to the inline documentation RTC_Sync always returns a successful sync regardless of whether or not the time has been updated. To update several conditionals have to succeed. The one of note is a test to see if the current time is >= a constant which the inline documentation suggests in the number of seconds corresponding to Jan 1, 2019. I don’t know why as it doesn’t correspond to the zigbee epoch of Jan 1, 2000 or the unix epoch.

If my hypothesis is correct the current time on an unsynchronized device is unix epoch which is < the constant so the check fails and the time is never updated either on boot as suggested by the zigbee time component documentation or when forced via a mqtt message via zigbee2mqtt. The time on the device remains unix epoch which is an invalid time when passed to the valid time function. It is possible that the same problem exists when using openthread instead of zigbee and the homeassistant time platform via the homeassitant api.

4

Thanks Karosm. Your suggested lead me to look at the actual zigbee time component code which I “think” was helpful.

5

Negative time travel? Backwards from Linux epoch?

Got to see a lot of this when doing Y2K consulting. Register or buffer overflow, or variable scoping, single vs double, etc.

Check the data content sent and received in MQTT. Are both ends configured the same?