Third Reality ZL1 Bulbs - Persistent Hidden TouchLink Group Bindings

jdmpike

Product: Third Reality Color Smart Bulb (3RCB01057Z / ZL1)
Firmware: 1.00.74 (multiple bulbs, same issue)
Coordinator: Zigbee2MQTT 2.6.3 with Ember adapter (SONOFF ZBDongle-E)

Issue Summary

Third Reality ZL1 bulbs accumulate hidden TouchLink group bindings that are not visible in Zigbee2MQTT and cannot be cleared through normal unbind operations. These bindings cause:

Group commands ignored - Bulb doesn’t respond to Zigbee group OFF commands
State bounce-back - Bulb turns OFF briefly, then immediately turns back ON
Message flooding - Single commands generate 4-40x duplicate MQTT state messages
Cross-talk - Turning one bulb ON causes other bulbs to turn ON

Technical Details

When attempting to unbind from default_bind_group, we discovered bulbs were bound to dozens of hidden groups (IDs 900-920+). These bindings are stored in bulb firmware but are invisible to the Zigbee coordinator.

Diagnosis command:
mosquitto_pub -t “zigbee2mqtt/bridge/request/device/unbind” \
-m ‘{“from”: “BULB_NAME”, “to”: “default_bind_group”}’

Error reveals: bound to unknown Group 901, 902, etc.

Evidence of hidden bindings:

Create temp group, then unbind succeeds (proving binding existed)

mosquitto_pub -t “zigbee2mqtt/bridge/request/group/add” \
-m ‘{“id”: 901, “friendly_name”: “TempGroup901”}’
mosquitto_pub -t “zigbee2mqtt/bridge/request/device/unbind” \
-m ‘{“from”: “BULB_NAME”, “to”: “TempGroup901”}’

Response: “status”:“ok”, clusters: genOnOff, genLevelCtrl, lightingColorCtrl

We found 6+ hidden group bindings per bulb across groups 900-920. Even after unbinding all discovered groups, some bulbs continued misbehaving.

Workaround

The only reliable fix is factory reset via power cycling (on/off 5-6 times rapidly until bulb flashes). This clears all firmware-level bindings. The bulb must then be re-paired and re-added to groups. This works for a few weeks, then the TouchLink Groups comeback and message flood.

Questions for Third Reality

Why do these bulbs accumulate so many hidden TouchLink bindings?
Is there a firmware command to clear all group bindings without factory reset?
Can future firmware updates prevent TouchLink binding accumulation?
Is there a way to disable TouchLink functionality entirely via Zigbee command?

Environment

18+ Third Reality ZL1 bulbs
Zigbee2MQTT 2.6.3
SONOFF ZBDongle-E (Ember/EZSP)
Channel 25
All bulbs on firmware 1.00.74

zhechen

jdmpike Thank you very much for sharing. We need to clarify some information. First, you mentioned “bind” but also referred to “TouchLink.” We should point out that TouchLink requires a distance of within 20 centimeters to occur reliably. Do you have any button-type devices near you that are constantly initiating binds or TouchLink? Given the large number of IDs you mentioned, we believe this is likely a standard bind issue rather than TouchLink, as the 20-centimeter distance restriction is relatively easy to avoid. Second, regarding standard bind, the ZL1 indeed had an issue in version 1.00.74 where it remained in a bindable state continuously. During use, if any device initiating a bind appeared, it would bind immediately. However, this issue has been fixed in the new version. Updating to the new version via OTA in Zigbee2MQTT will resolve it. In the new version, binding is only allowed for a few minutes after a reset/re-joining of the network or when manually enabled in the platform. It is also recommended to re-pair the bulbs after the OTA update to clear the previous IDs. I hope this information addresses your needs.

jdmpike

zhechen what firmware should I be able to find? all of my devices are on 1.00.74 with no new OTA updates available.

jdmpike

My z2m config has thirdreality_provider: true, but I don’t see new firmware available. Is there a link to the file or latest firmware?

zhechen

jdmpike We sincerely apologize. We have just checked again and confirmed that for the bulb’s firmware, starting from version 68, the design was updated so that binding is only possible within the first 3 minutes after a reset or re-pairing. Your current version should already include this feature. Is there any device in your home that is constantly attempting to initiate binding?

jdmpike

@zhechen The bulbs pair to the controller, but then they create these groups in the 900+ range on their own. With the number of devices I have in my network, having them all pair to one another is not a feature, it is a bug.

For example, I have six bulbs in my living room cans group. When I first configure them and set them up, they work great; after a few days/weeks, they create all these other groups and start flooding my mqtt with messages so that when I try to turn that group off, one light will stay on. If I was to try to go turn that individual bulb off, the entire group would bounce back on.

See the original issue summary. I will try to capture some raw log data if that is helpful.

jdmpike

Third Reality ZL1 Bulb Bug Report for @zhechen

Date: 2025-12-08
Model: 3RCB01057Z (Third Reality ZL1 Smart Light Bulb)
Firmware: 74 (latest)
Coordinator: EmberZNet 7.4.5 (Ember adapter)
Zigbee2MQTT Version: 2.x (latest)
Zigbee Channel: 25

Problem Summary

Third Reality ZL1 bulbs in a Zigbee group exhibit two problematic behaviors:

Bounce-back issue: When turning OFF a group, bulbs turn themselves back ON within milliseconds
Message flooding: Bulbs report their state 40-50+ times per single command (should be 1x)

Environment

6x Third Reality ZL1 bulbs in a single Zigbee2MQTT native group (Group ID: 1)
Group name: “Living Room Cans”
All bulbs on firmware v74
EmberZNet coordinator on channel 25
No other Zigbee traffic during test

Test Procedure

Sent group ON command via MQTT: zigbee2mqtt/Living Room Cans/set → {"state": "ON"}
Waited 4 seconds
Sent group OFF command via MQTT: zigbee2mqtt/Living Room Cans/set → {"state": "OFF"}
Observed lights physically turn back ON within ₁ second

Observed Behavior

Message Flooding During Test

Bulb	Messages Received	Expected
Middle Right	53	2 (ON + OFF)
Middle Left	52	2
Front Left	53	2
Front Right	39	2
Back Left	4	2
Back Right	4	2

State Transition Sequence (from MQTT log)

7x state: ON   (initial ON command)
7x state: OFF  (OFF command - all bulbs acknowledged)
148x state: ON (BOUNCE-BACK - bulbs turned themselves back ON!)

Critical Transition (Line 70-85 in attached log)

zigbee2mqtt/Living Room - Back Right ... "state":"OFF"  ← Last bulb confirms OFF
zigbee2mqtt/Living Room Cans ... "state":"ON"           ← GROUP reports ON (bounce!)
zigbee2mqtt/Living Room - Middle Left ... "state":"ON"  ← Flooding begins
zigbee2mqtt/Living Room - Middle Left ... "state":"ON"  ← Duplicate
zigbee2mqtt/Living Room - Middle Left ... "state":"ON"  ← Duplicate
zigbee2mqtt/Living Room - Middle Left ... "state":"ON"  ← Duplicate

Root Cause Hypothesis

Based on previous debugging sessions, we believe the bulbs accumulate hidden TouchLink group bindings in firmware that are not visible to Zigbee2MQTT. When the visible group (ID 1) receives an OFF command, the hidden binding to a phantom group triggers the bulb to turn back ON.

Evidence:

We previously found bindings to groups 900-999 that we never created
Unbinding from these “phantom” groups temporarily fixed the issue
Factory reset (power cycle 5-6x) clears the bindings but they return over time

Questions for Third Reality

Is there a known issue with TouchLink bindings persisting in firmware?
Why do bulbs send 40-50+ state reports per command instead of 1?
Is there a way to clear all group bindings via Zigbee command?
Is there a firmware update that addresses these issues?

Attached Files

thirdreality-bug-20251208-*.log - Full MQTT capture during test
Lines 70-100 contain the critical OFF→ON bounce-back transition

Device IEEE Addresses (for reference)

Living Room - Middle Left: 0×1c784ba0b25e0000
Living Room - Middle Right: 0xc890a81e9afe0000
Living Room - Front Left: 0xc890a81f11350000
Living Room - Front Right: 0xc890a81f4e200000
Living Room - Back Left: 0×1c784ba0c33e0000
Living Room - Back Right: 0×1c784ba107c00000

—

Clean Configuration Test (2025-12-08 23:14)

After removing all temporary diagnostic groups, the issue persists with identical behavior.

Groups present during test:

Living Room Cans (ID: 1) - contains 6 ZL1 bulbs
Bar Cans (ID: 2)
TV Cans (ID: 3)

State sequence from clean test:

7x ON   (initial ON command acknowledged)
7x OFF  (OFF command acknowledged by all 6 bulbs + group)
9x ON   (BOUNCE-BACK begins)
2x OFF  (brief resistance)
1x ON   
2x OFF  
113x ON (message flood - bulbs stuck reporting ON)

Conclusion: The bounce-back and message flooding occur with a completely clean Zigbee2MQTT configuration. This is not caused by any user configuration issues.

Attached Files (for support)

thirdreality-clean-20251208-231424.log - https://pastes.io/zigbee2mqtt-bridge-state-converters-and-info-dump

jdmpike

@zhechen any additional information you need here? I am happy to provide whatever I can to help you create a more resilient firmware for these devices I have invested in.

zhechen

jdmpike We have set up a similar environment to test whether the same issue occurs. Could you please let us know if there are any button-type devices in your home that can actively initiate binding?

jdmpike

Complete Zigbee Mesh Inventory for Third Reality Support for @zhechen

Date: 2025-12-17
Coordinator: SONOFF Dongle Plus MG24 (0xd4fe28fffe296feb)
Zigbee2MQTT Version: 2.7.1
OTA Config: thirdreality_provider: true, image_block_response_delay: 600

Device Summary

Type	Count
Third Reality ZL1 (3RCB01057Z)	22
AL001 Repeaters (WG001-Z01)	2
Groups	4
Total	28

All Devices

#	IEEE Address	Manufacturer	Model	FW	App Ver	Last Seen
1	`0xd4fe28fffe296feb`	— (Coordinator)	SONOFF MG24	—	—	2025-12-17
2	`0x7cb94c6b8cfd0000`	Third Reality, Inc	3RCB01057Z	1.00.74	48	2025-12-17
3	`0xb4e842866a040000`	Third Reality, Inc	3RCB01057Z	1.00.74	48	2025-12-07
4	`0x7cb94c6ba6670000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-12-17
5	`0x7cb94c6b9bc30000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-12-17
6	`0x7cb94c6b9d1d0000`	Third Reality, Inc	3RCB01057Z	1.00.74	48	2025-12-17
7	`0x7cb94c6ba1cf0000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-12-17
8	`0xb4e8428660130000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-11-26
9	`0xb4e8428679c30000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-11-28
10	`0x7cb94c6b9f770000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-12-17
13	`0xc890a81f11350000`	Third Reality, Inc	3RCB01057Z	1.00.74	66	2025-12-11
15	`0xc890a81e9afe0000`	Third Reality, Inc	3RCB01057Z	1.00.74	66	2025-12-11
17	`0x7cb94c631d910000`	Third Reality, Inc	3RCB01057Z	1.00.74	66	2025-12-14
18	`0x1c784ba0f54e0000`	Third Reality, Inc	3RCB01057Z	1.00.74	66	2025-12-14
19	`0xc890a81f08fc0000`	Third Reality, Inc	3RCB01057Z	1.00.74	66	2025-12-13
20	`0x7cb94c7905fc0000`	Third Reality, Inc	3RCB01057Z	1.00.74	66	2025-12-13
21	`0x1c784ba110d20000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-12-12
22	`0xb4e8428656850000`	Third Reality, Inc	3RCB01057Z	1.00.74	56	2025-12-17
23	`0x1c784ba12feb0000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-12-16
24	`0x1c784ba107c00000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-12-11
25	`0xc890a81f4e200000`	Third Reality, Inc	3RCB01057Z	1.00.74	66	2025-12-11
26	`0x1c784ba0c33e0000`	Third Reality, Inc	3RCB01057Z	1.00.74	74	2025-12-11
27	`0x1c784ba0b25e0000`	Third Reality, Inc	3RCB01057Z	1.00.74	66	2025-12-11
32	`0x8c8b48fffe958245`	AL001	WG001-Z01	—	67	2025-12-17
33	`0x94b216fffe07ef7c`	AL001	WG001-Z01	—	67	2025-12-17

App Version Distribution

App Version	Count
48	3
56	1
66	8
74	10

Groups Configuration

Group ID	Name	Purpose
0	TempGroup0	Debug/temp
1	Living Room Cans	Main room - 6 bulbs
2	Bar Cans	Subset of group 1
3	TV Cans	Subset of group 1

Bindings

Status: All bindings cleared (cleanup performed 2025-12-08)

No active device-to-device or device-to-group bindings currently configured.

Problem Device

IEEE: 0x1c784ba0b25e0000 (Device #27)
Behavior:

Primary instigator of bounce-back
Floods 50+ MQTT messages per command vs 4 for well-behaved bulbs
Was factory reset but issue returned over time

—

Issue Summary

All 22 Third Reality ZL1 bulbs on firmware 1.00.74 exhibit the “continuously bindable” bug.
OTA is configured with thirdreality_provider: true but Z2M still shows 1.00.74 as latest.

zhechen

jdmpike Your network currently uses two repeaters. Do they serve any practical purpose? Our bulbs also function as router devices.

jdmpike

I purchased them specifically because the Third Reality bulbs were not performing well as mesh routers when I had a high device count (22 bulbs).

Before adding the repeaters, I experienced:

Message flooding - Individual bulbs generating 40-50+ duplicate state reports per single command (vs the expected 4-5)
Network instability - Group commands causing bulbs to “fight” each other with cascading state changes
Unreliable routing - Commands getting lost or delayed

After adding the two Aeotec repeaters as dedicated router devices, the network became significantly more stable. The repeaters handle mesh routing responsibilities, which appears to reduce the load on the bulbs and improve overall reliability. At least it did initially; when we deployed the repeaters we did all the unbinding, etc in attempt to get bulbs to connect to them as dedicated routers.

That said, the bounce-back issue persists regardless of the repeaters - it’s clearly a firmware-level TouchLink binding problem as I’ve documented. The repeaters helped with general mesh stability, but they don’t fix the hidden group binding accumulation issue.