zsmartsystems
Ember and cc2531 don't work with sleepy tuya sensors, but ConBee does
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 563cda04bc971dd3fb76993ac784cfbc614864b5 commit All logs are provides as files, joining TS0207 sensor
cc2531.log conbee2.log ember_ezspV7.log ember_ezspV13.log
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: @.***>
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
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:
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.
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...
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.
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.
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.