Ember and cc2531 don't work with sleepy tuya sensors, but ConBee does

[drondistortion]

Describe the bug

I don't know if this is a bug or expected behavior. I have three battery powered Tuya sensors (TS0203, TS0205 and TS0207_water_leak_detector) which work with conbee dongle, but totally don't with Ezsp and cc2531 driver.

To Reproduce

run console app with Ezsp or cc2531 driver, and try to join mentioned sensors:

> nodes
Total known nodes in network: 2
Network  Addr  IEEE Address      Logical Type  State       EP   Profile                    Device Type                          Manufacturer          Model          
      0  0000  00124B001DF41317  COORDINATOR   ONLINE    
  24586  600A  A4C13818D360698D  UNKNOWN       ONLINE    

Expected behavior

With conbee driver:

> nodes
Total known nodes in network: 2
Network  Addr  IEEE Address      Logical Type  State       EP   Profile                    Device Type                          Manufacturer          Model          
      0  0000  00212EFFFF04D977  COORDINATOR   ONLINE    
  42883  A783  A4C138BC16EBFB53  END_DEVICE    ONLINE       1  ZIGBEE_HOME_AUTOMATION     IAS_ZONE                                                                  

Additional context
I'm using master branch with 563cda0 commit
All logs are provides as files, joining TS0207 sensor

cc2531.log
conbee2.log
ember_ezspV7.log
ember_ezspV13.log

[cdjackson]

Please advise the versions you are using. If you have old firmware then it may not work with a ZigBee 3 join.Sent from my iPhoneOn 17 Mar 2025, at 19:17, drondistortion ***@***.***> wrote: Describe the bug I don't know if this is a bug or expected behavior. I have three battery powered Tuya sensors (TS0203, TS0205 and TS0207_water_leak_detector) which work with conbee dongle, but totally don't with Ezsp and cc2531 driver. To Reproduce run console app with Ezsp or cc2531 driver, and try to join mentioned sensors:

nodes

Total known nodes in network: 2 Network Addr IEEE Address Logical Type State EP Profile Device Type Manufacturer Model 0 0000 00124B001DF41317 COORDINATOR ONLINE 24586 600A A4C13818D360698D UNKNOWN ONLINE Expected behavior With conbee driver:

nodes

Total known nodes in network: 2 Network Addr IEEE Address Logical Type State EP Profile Device Type Manufacturer Model 0 0000 00212EFFFF04D977 COORDINATOR ONLINE 42883 A783 A4C138BC16EBFB53 END_DEVICE ONLINE 1 ZIGBEE_HOME_AUTOMATION IAS_ZONE Additional context I'm using master branch with 563cda0 commit All logs are provides as files, joining TS0207 sensor cc2531.log conbee2.log ember_ezspV7.log ember_ezspV13.log—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> drondistortion created an issue (zsmartsystems/com.zsmartsystems.zigbee#1458) Describe the bug I don't know if this is a bug or expected behavior. I have three battery powered Tuya sensors (TS0203, TS0205 and TS0207_water_leak_detector) which work with conbee dongle, but totally don't with Ezsp and cc2531 driver. To Reproduce run console app with Ezsp or cc2531 driver, and try to join mentioned sensors:

nodes

Total known nodes in network: 2 Network Addr IEEE Address Logical Type State EP Profile Device Type Manufacturer Model 0 0000 00124B001DF41317 COORDINATOR ONLINE 24586 600A A4C13818D360698D UNKNOWN ONLINE Expected behavior With conbee driver:

nodes

Total known nodes in network: 2 Network Addr IEEE Address Logical Type State EP Profile Device Type Manufacturer Model 0 0000 00212EFFFF04D977 COORDINATOR ONLINE 42883 A783 A4C138BC16EBFB53 END_DEVICE ONLINE 1 ZIGBEE_HOME_AUTOMATION IAS_ZONE Additional context I'm using master branch with 563cda0 commit All logs are provides as files, joining TS0207 sensor cc2531.log conbee2.log ember_ezspV7.log ember_ezspV13.log —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[drondistortion]

here's the rundown (those that don't work):
EFR32MG13 based dongle: protocolVersion=7, stackType=2, stackVersion=6500
EFR32MG21 based dongle: protocolVersion=13, stackType=2, stackVersion=7440
CC2531 based dongle: Software=2.6 Product=0 Hardware=3 Transport=2

[drondistortion]

I have some new info
I managed to get endpoints from the sensors on older ezsp firmware (6.5.5.0), but they never complete join and go offline...

> nodes
Total known nodes in network: 3
Network  Addr  IEEE Address      Logical Type  State       EP   Profile                    Device Type                          Manufacturer          Model          
      0  0000  E8E07EFFFE556EA7  COORDINATOR   ONLINE    
  25091  6203  A4C13838B32A2338  END_DEVICE    OFFLINE      1  ZIGBEE_HOME_AUTOMATION     IAS_ZONE                                                                  
  45268  B0D4  A4C138BC16EBFB53  END_DEVICE    OFFLINE      1  ZIGBEE_HOME_AUTOMATION     IAS_ZONE                                                                  

if I do this (strangely enough it only works if join mode AND link key changed):

diff --git a/com.zsmartsystems.zigbee.console.main/src/main/java/com/zsmartsystems/zigbee/console/main/ZigBeeConsoleMain.java b/com.zsmartsystems.zigbee.console.main/src/main/java/com/zsmartsystems/zigbee/console/main/ZigBeeConsoleMain.java
index 797b0ef6..30b6f6b2 100644
--- a/com.zsmartsystems.zigbee.console.main/src/main/java/com/zsmartsystems/zigbee/console/main/ZigBeeConsoleMain.java
+++ b/com.zsmartsystems.zigbee.console.main/src/main/java/com/zsmartsystems/zigbee/console/main/ZigBeeConsoleMain.java
@@ -405,14 +405,14 @@ public class ZigBeeConsoleMain {
 
         networkManager.setDefaultProfileId(defaultProfileId);
 
-        transportOptions.addOption(TransportConfigOption.TRUST_CENTRE_JOIN_MODE, TrustCentreJoinMode.TC_JOIN_SECURE);
+        transportOptions.addOption(TransportConfigOption.TRUST_CENTRE_JOIN_MODE, TrustCentreJoinMode.TC_JOIN_INSECURE);
 
         // Add the default ZigBeeAlliance09 HA link key
 
-        transportOptions.addOption(TransportConfigOption.TRUST_CENTRE_LINK_KEY, new ZigBeeKey(new int[] { 0x5A, 0x69,
-                0x67, 0x42, 0x65, 0x65, 0x41, 0x6C, 0x6C, 0x69, 0x61, 0x6E, 0x63, 0x65, 0x30, 0x39 }));
-        // transportOptions.addOption(TransportConfigOption.TRUST_CENTRE_LINK_KEY, new ZigBeeKey(new int[] { 0x41, 0x61,
-        // 0x8F, 0xC0, 0xC8, 0x3B, 0x0E, 0x14, 0xA5, 0x89, 0x95, 0x4B, 0x16, 0xE3, 0x14, 0x66 }));
+        //transportOptions.addOption(TransportConfigOption.TRUST_CENTRE_LINK_KEY, new ZigBeeKey(new int[] { 0x5A, 0x69,
+                //0x67, 0x42, 0x65, 0x65, 0x41, 0x6C, 0x6C, 0x69, 0x61, 0x6E, 0x63, 0x65, 0x30, 0x39 }));
+         transportOptions.addOption(TransportConfigOption.TRUST_CENTRE_LINK_KEY, new ZigBeeKey(new int[] { 0x41, 0x61,
+                  0x8F, 0xC0, 0xC8, 0x3B, 0x0E, 0x14, 0xA5, 0x89, 0x95, 0x4B, 0x16, 0xE3, 0x14, 0x66 }));
 
         dongle.updateTransportConfig(transportOptions);

full log:

ezspV7_incomplete_join.log

[cdjackson]

I don't understand what this link key is that you're using. The Alliance defines the well known link key and Tuya also uses that as far as I'm aware, and certainly I've had no problem with joining Tuya devices with the standard link key.

[drondistortion]

you're right link key is not an issue, it's TC_JOIN_INSECURE that got me to this. But still, I cannot fathom why those sensors go offline or why they do not answer to node requests when it's a secure join...

[cdjackson]

Maybe you should describe the problem you actually have here? If you are seeing the endpoints, then the devices are joining. If they don't respond to requests, that's a very different issue. In general Tuya battery devices will not respond to requests since they sleep - this is normal for an end device. The fact that the library marks them as OFFLINE is not really relevant and it's not indicative of the network state in any way.

[drondistortion]

the problem I described in OP stands correct, sensors work with conbee, don't work with ember or cc2531. Everything else is just guess work. And, as I said, I don't know if it is a bug or not. What I really want is to figure out why or at least an advise where to look why they aren't giving node descriptors with latter drivers.

[cdjackson]

the problem I described in OP stands correct, sensors work with conbee, don't work with ember or cc2531.

So firstly, I don't believe that this library works with the Conbee stick. This statement of the "problem" is just too broad for anyone to be able to assist with - this is a low level library used in a number of commercial and open source products. You probably need to be doing some debug to work out what's wrong and provide a more detailed explanation of the issuee.

In the OP, your statement of what's wrong was .

which work with conbee dongle, but totally don't with Ezsp and cc2531 driver.

This really isn't a description of the problem - "it totally doesn't work". At least it's not a description that I'm able to help solve.

You say they don't "completely join" - but clearly they are joining. It either joins the network or it doesn't - there's no partial join.

want is to figure out why or at least an advise where to look why they aren't giving node descriptors with latter drivers.

It seems to me that you are getting descriptors -:

Total known nodes in network: 3
Network  Addr  IEEE Address      Logical Type  State       EP   Profile                    Device Type                          Manufacturer          Model          
      0  0000  E8E07EFFFE556EA7  COORDINATOR   ONLINE    
  25091  6203  A4C13838B32A2338  END_DEVICE    OFFLINE      1  ZIGBEE_HOME_AUTOMATION     IAS_ZONE                                                                  
  45268  B0D4  A4C138BC16EBFB53  END_DEVICE    OFFLINE      1  ZIGBEE_HOME_AUTOMATION     IAS_ZONE                                                                  

This information comes from the descriptors provided by the device.

I cannot fathom why those sensors go offline or why they do not answer to node requests when it's a secure join...

As I've said, battery devices will not answer requests - they will go to sleep. If you're not waking them up, then they will not respond. The ONLINE / OFFLINE status provided by the library is only an internal indicator and is not reliable in all cases. It does not in any way indicate that the device has left the network or anything like that. You should ignore this.

So, maybe the problem is clear to you, but from my side I don't know. It looks like the devices are joining the network, and working fine and you will need to provide more information to help me help you.

[drondistortion]

I get back when I have more understanding.