SONOFF SWV irrigation start/end timestamps encode local time as UTC

What happened?

I have a SONOFF SWV Zigbee smart water valve, firmware 1.0.4 (4100), connected through Zigbee2MQTT 2.14.1.

The irrigation_start_time and irrigation_end_time values are exposed as Unix timestamps, but the SWV appears to encode local wall-clock time as though it were UTC.

My timezone is Africa/Johannesburg (SAST, UTC+2).

For example:

irrigation_start_time: 1789290006
irrigation_end_time: 1789290606

The actual local irrigation times were 09:00:06 and 09:10:06 SAST.

However, 1789290006 represents 09:00:06 UTC. The correct UTC time corresponding to 09:00:06 SAST is 07:00:06 UTC.

The timestamp supplied by the SWV is therefore 7200 seconds ahead of the true Unix epoch. Software treating it as a genuine Unix timestamp consequently displays the irrigation time two hours late.

I enabled Zigbee2MQTT debug logging to establish where the timestamp originates.

For irrigation start, the SWV sends an attributeReport on customClusterEwelink:

attrId: 20493 (0x500D)
dataType: 35 (UINT32)
attrData: 1789211479

Zigbee2MQTT receives:

cluster 'customClusterEwelink'
data '{"20493":1789211479}'

and publishes the same value as:

"irrigation_start_time":1789211479

For irrigation end, the SWV sends:

attrId: 20494 (0x500E)
dataType: 35 (UINT32)
attrData: 1789211484

Zigbee2MQTT receives:

cluster 'customClusterEwelink'
data '{"20494":1789211484}'

and publishes the same value as:

"irrigation_end_time":1789211484

This indicates that Zigbee2MQTT is passing through the timestamp supplied by the SWV unchanged.

I also searched the debug log for genTime, timeZone and localTime and found no corresponding traffic. An attempted manual read of the genTime/timeZone attribute on endpoint 1 resulted in a ZCL error.

What did you expect to happen?

irrigation_start_time and irrigation_end_time should represent the actual instant in time.

For example, an irrigation session starting at 09:00:06 SAST (UTC+2) should correspond to 07:00:06 UTC, not 09:00:06 UTC.

I would expect the SONOFF SWV converter to account for the device's apparent local-wall-clock timestamp behaviour, or otherwise expose the values so that consumers such as Home Assistant can interpret them correctly.

How to reproduce it (minimal and precise)

1. Set the local timezone to Africa/Johannesburg (UTC+2).
2. Pair a SONOFF SWV with Zigbee2MQTT.
3. Enable Zigbee2MQTT debug logging.
4. Start an irrigation session and note the actual local start time.
5. Stop the irrigation session and note the actual local end time.
6. Compare those times with irrigation_start_time and irrigation_end_time reported by Zigbee2MQTT.
7. Convert the reported values as standard Unix timestamps.

The resulting times are 2 hours later than the actual local irrigation times.

Debug logging shows that attributes 0x500D and 0x500E containing these values originate in attribute reports from the SWV.

Zigbee2MQTT version

2.14.1

Adapter firmware version

6.10.3.0 build 297

Adapter

EZSP

Setup

Zigbee2MQTT Home Assistant App
Home Assistant OS running as a virtual machine on Proxmox
Timezone: Africa/Johannesburg (SAST / UTC+2)

Device database.db entry

No response

Debug log

Relevant Zigbee2MQTT debug output:

Irrigation start:

Received Zigbee message from 'Sonoff watering valve',
type 'attributeReport',
cluster 'customClusterEwelink',
data '{"20493":1789211479}'

Zigbee2MQTT subsequently published:

"irrigation_start_time":1789211479

Irrigation end:

Received Zigbee message from 'Sonoff watering valve',
type 'attributeReport',
cluster 'customClusterEwelink',
data '{"20494":1789211484}'

Zigbee2MQTT subsequently published:

"irrigation_end_time":1789211484

log.log

Notes

No response

Start at the SONOFF SWV handling for customClusterEwelink, focusing on attributes 0x500D and 0x500E and the published irrigation_start_time and irrigation_end_time values. Reproduce the report with the supplied debug log and Africa/Johannesburg timezone, then verify that the exposed timestamps represent the actual instant rather than the device's local wall-clock value.