Sonoff S60ZBTPF on_time don't work (FW : 1.0.2, 2.0.2, 2.0.3)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 15.7k
- Forks
- 2k
- Avg merge
- 18h 55m
- Merged PRs (30d)
- 35
Description
What happened?
I try to use this mqtt message to set my plug on for 300 seconds
{"state" : "ON", "on_time" : 300}
What did you expect to happen?
The plug should turn on then turn itself off after 300 seconds
How to reproduce it (minimal and precise)
Publish a mqtt message to the topic : zigbee2mqtt/{you device id}/set
Payload : {"state" : "ON", "on_time" : 300}
Zigbee2MQTT version
2.12.1-1
Adapter firmware version
1.0.2 and i also tried on 2.0.2
Adapter
S60ZBTPF
Setup
virch on a dedicated optiplex hardware
cpu:
Intel(R) Core(TM) i5-7500T CPU @ 2.70GHz, 3194 MHz
Intel(R) Core(TM) i5-7500T CPU @ 2.70GHz, 3200 MHz
Intel(R) Core(TM) i5-7500T CPU @ 2.70GHz, 3194 MHz
Intel(R) Core(TM) i5-7500T CPU @ 2.70GHz, 3100 MHz
monitor:
22W_LCD_TV
graphics card:
Intel HD Graphics 630
sound:
Intel 200 Series PCH HD Audio
storage:
Intel 200 Series PCH SATA controller [AHCI mode]
SK hynix Non-Volatile memory controller
network:
enp2s0 Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
network interface:
enp2s0 Ethernet network interface
veth2b96081 Ethernet network interface
br0 Ethernet network interface
vnet0 Ethernet network interface
virbr0 Ethernet network interface
br-b7e268e4fc86 Ethernet network interface
lo Loopback network interface
docker0 Ethernet network interface
disk:
/dev/nvme0n1 SK hynix Disk
partition:
/dev/nvme0n1p1 Partition
/dev/nvme0n1p2 Partition
usb controller:
Intel 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller
bios:
BIOS
bridge:
Intel 200 Series PCH PCI Express Root Port #5
Intel 200 Series PCH LPC Controller (B250)
Intel 200 Series PCH PCI Express Root Port #21
Intel Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers
hub:
Linux Foundation 2.0 root hub
Linux Foundation 3.0 root hub
memory:
Main Memory
unknown:
FPU
DMA controller
PIC
Keyboard controller
Intel 200 Series/Z370 Chipset Family Power Management Controller
Intel 200 Series PCH CSME HECI #1
Intel 200 Series PCH Thermal Subsystem
Intel 200 Series/Z370 Chipset Family SMBus Controller
Serial controller
Future Technology Devices International Bridge(I2C/SPI/UART/FIFO)
Silicon CP210x UART Bridge
Linux homeserver 6.17.0-23-generic #23-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 11 23:29:57 UTC 2026 x86_64 GNU/Linux
Ubuntu 25.10
Device database.db entry
No response
Debug log
FOR FIRMWARE 1.02
[7/3/2026, 8:30:34 PM] z2m:mqtt: Received MQTT message on 'zigbee2mqtt/0xa4c13806f23cffff/set' with data '{"state" : "ON", "on_time": 300, "off_wait_time": 120}'
[7/3/2026, 8:30:34 PM] z2m: Publishing 'set' 'state' to '0xa4c13806f23cffff'
[7/3/2026, 8:30:34 PM] zh:controller:endpoint: ZCL command 0xa4c13806f23cffff/1 genOnOff.onWithTimedOff({"ctrlbits":0,"ontime":3000,"offwaittime":1200}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false})
[7/3/2026, 8:30:34 PM] zh:ember: ~~~> [ZCL to=0xa4c13806f23cffff:56705 apsFrame={"profileId":260,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":1,"options":4416,"groupId":0,"sequence":0} header={"frameControl":{"reservedBits":0,"frameType":1,"direction":0,"disableDefaultResponse":false,"manufacturerSpecific":false},"transactionSequenceNumber":181,"commandIdentifier":66}]
[7/3/2026, 8:30:37 PM] z2m: Received Zigbee message from '0xa4c13806f23cffff', type 'attributeReport', cluster 'customClusterEwelink', data '{"acCurrentPowerValue":0}' from endpoint 1 with groupID 0
[7/3/2026, 8:30:37 PM] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0xa4c13806f23cffff', payload '{"current":0,"energy":0,"energy_month":0,"energy_today":0,"energy_yesterday":0,"linkquality":100,"network_indicator":false,"outlet_control_protect":false,"overload_protection":{"enable_max_voltage":"DISABLE","enable_min_current":"DISABLE","enable_min_power":"DISABLE","enable_min_voltage":"DISABLE","max_current":0,"max_power":0,"max_voltage":0,"min_current":0,"min_power":0,"min_voltage":0},"power":0,"power_on_behavior":"off","state":"OFF","update":{"installed_version":-1,"latest_version":-1,"state":null},"voltage":0}'
FOR FIRMWARE 2.0.2
[7/3/2026, 8:14:44 PM] z2m:mqtt: Received MQTT message on 'zigbee2mqtt/Prise Pompe New/set' with data '{"state" : "ON", "on_time": 400}'
[7/3/2026, 8:14:44 PM] z2m: Publishing 'set' 'state' to 'Prise Pompe New'
[7/3/2026, 8:14:46 PM] z2m: Received Zigbee message from 'Prise Pompe New', type 'attributeReport', cluster 'customClusterEwelink', data '{"acCurrentPowerValue":710395}' from endpoint 1 with groupID 0
[7/3/2026, 8:14:46 PM] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Prise Pompe New', payload '{"current":0,"energy":0,"energy_month":0,"energy_today":0,"energy_yesterday":0,"linkquality":168,"network_indicator":true,"outlet_control_protect":false,"overload_protection":{"enable_max_voltage":"DISABLE","enable_min_current":"DISABLE","enable_min_power":"DISABLE","enable_min_voltage":"DISABLE","max_current":0,"max_power":0,"max_voltage":0,"min_current":0,"min_power":0,"min_voltage":0},"power":0,"power_on_behavior":"off","state":"OFF","update":{"installed_version":8194,"latest_release_notes":null,"latest_source":null,"latest_version":8194,"state":"idle"},"voltage":238.56}'
Notes
The SONOFF S60ZBTPF supports "On with timed off" per its Zigbee2MQTT device page https://www.zigbee2mqtt.io/devices/S60ZBTPF.html (on_time / off_wait_time payload properties, mapped to the genOnOff.onWithTimedOff ZCL command).
Plain {"state": "ON"} and {"state": "OFF"} always work correctly. As soon as on_time is added to the payload (with or without off_wait_time) the relay does not turn on at all, and no error is reported anywhere (frontend, MQTT, or logs).
This happens on both firmware versions I tested (1.0.2, 2.0.2), but the underlying behavior differs:
On firmware 1.0.2, Zigbee2MQTT correctly builds and sends the onWithTimedOff ZCL command (visible in debug logs), but the device does not react to it.
On firmware 2.0.2, the onWithTimedOff ZCL debug line does not appear at all, and the device stays off
From ClaudeAI (Do what you want about this part)
The SN-TLSR8656-S60-01-v2.0.2 OTA release notes state that when the device triggers an overload condition, it will not respond to the relay state change but will still return a control-success response, and that an extra status report was added to resync the real state in that case.
The 2.0.2 log above matches this pattern closely (ON commanded → bogus power spike → resynced to OFF), which suggests the extended onWithTimedOff command itself may be mishandled internally as some kind of fault/overload condition, independent of the user-configured overload thresholds (all disabled here).
This does not explain the 1.0.2 case, where the command is sent as a well-formed standard ZCL command with no fault reporting at all — the device there just doesn't act on it, similar to a previously reported issue on a different device (Woox R7060, #23845) where onWithTimedOff was silently ignored while plain ON/OFF worked.
Related issues
#23845 – Woox R7060: on_time/off_wait_time silently ignored, no error, same symptom as observed here on firmware 1.0.2.
#25323 – onWithTimedOff on_time scaling and range limits (confirms the ×10 conversion behavior seen in the 1.0.2 log is expected/correct).
#31481 – Other regressions reported after updating S60ZBTPF to firmware 2.0.2 (overload protection settings reset/incorrect in the dashboard).
sub Notes :
The plug '0xa4c13806f23cffff' is a test plug with a small load (led light of 14W)
The plug 'Prise Pompe New' is controlling a 700W water pump for my garden.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the MQTT set request for S60ZBTPF and compare the logged genOnOff.onWithTimedOff command across firmware versions 1.0.2 and 2.0.2. Done means determining whether Zigbee2MQTT or the device firmware drops the command, with the relay turning on and then off after the requested duration or a documented device limitation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 38/100