Testing popular ZigBee devices (and coordinators)

no these are version 2 zigbee. the stick is version 3 zigbee.

Aqara has already released new versions (T1) in China using version 3. Just not available to us in Europe yet but these version 2 are.

Sonoff version 3 are available.

That information you have may explain the differences in what we see. It is hard to say what is and what will not work. I bought my motion sensor last week :wink:

Which field is the one that tells ?

Mine’s just some weeks old.

Got yours on Ali ? Not sure if you can get the China-only T1’s there.
Just ordered a Tuya switch similar to Aqara T1. Featured as ZigBee 3.0 but let’s see.

From my one version 3 device I think zigbee_zclversion.

I do not think these report but from reading they are old. I found even Amazon seller have has them reduced.

no I don’t think so yet

No then most of my devices would be version 1 :slight_smile: Chris will know

FWIW, I got the motion sensor to work with my Conbee stick/deCONZ binding. Just takes 5-10 seconds to pair. So I guess it’s not related to the device not being awake.
I also read over at the deCONZ GitHub about issues with that sensor and there was a mentioning of some vendor proprietary attribute… don’t find it any more but if you think it’s valuable information to get this working let me know.

Also finally got this Tuya thermostat to reset and to work with deCONZ, too (just minutes after I ordered another one - gnah …).
With our zigbee binding, it complained about handlers missing (“no supported clusters found”). Will post a pairing log of that asap.

It also points to a possible compatibility issues with the firmware on the I-Tead or the lack of good tuning of the RF on the I-Tead or the power amplifier on the Conbee.

No that’s shooting at the dark. Whenever I clicked a sensor I have seen the package arriving in OH so I have no reason to believe trouble is related to RF weakness.

Well, it’s a little unfair to blame Zigbee here - these devices have known issues :wink:

1 Like

I’m interested in how you draw this conclusion? I don’t personally know how the Dresden software works, but it migth not need the device to be awake as long as the OH binding does. I’ve said a couple of times that the way the binding works requires that the device be kept awake quite a long time.

which is similar to a lot of issues on z-wave and I assume would be the same on any mesh where devices fail to comply to the standard precisely

Absolutely. Due to the more closed nature of ZWave, there are less non-compliant ZWave devices and they mostly use the same firmware for the lower layers. Zigbee is built on open standards - 802.15.4 - and there are many different network layers built on this standard. Some companies use Zigbee on 802.15.4, others pick parts of Zigbee to use, but simplifying it to make it easier for their closed system. This does give “Zigbee” a bad name, and is exactly why ZWave remained closed for so long, but it’s not really a Zigbee issue - it’s just that many closes systems don’t follow all the standard, and their devices may therefore not fully work in a Zigbee system.

2 Likes

Well from what I was seeing as packets when attempting to pair with your binding, there were vast periods of no traffic and I think also a number of cancelled requests at times (those I didn’t check so I may be wrong on that).
So to me it was likely that it is not (well not only) the sheer amount of messages and data that need to be exchanged (sure, some of which Dresden may have cached/available in their code, speeding up their process), but some of their messages seem to be, well how to call it - more suitable ? Such that both sides can properly parse and process them so they all generate quick answers.
While with your binding there seem be periods of either side waiting for the other until some timeout occurs, and even keeping the device alive for a long time didn’t help.

Ok, so you have access to more information than me, so I have to leave it to you to understand the problem.

Like what? The binding is doing standard stuff - stuff that is REQUIRED by ZigBee Alliance. This has been through a level of Zigbee certification already. Again - you have access to more information here, but making these sort of comments is really useless unless you are going to provide the information.

Again - I’ve really no way to comment if you don’t provide the information. The binding passes the information on to the coordinator to send. This can take up to around 8 seconds to time out - it may be quicker, depending on the devices etc. I’m just speculating though - if you want me to help, then please provide information to back up your statements - not just one line points like this as I’m not completely sure that you are so familiar with how Zigbee works? (or maybe I’m wrong?).

I’m nowhere near as familiar with ZigBee as you are. To me binding, coordinator and network are a black box I can’t look into, and I don’t even know how a proper protocol exchange would need to look like.
All I’m doing is to observe and compare with another system and to speculate on possible reasons. Somewhere in the deCONZ plugin Github repo I read about some extraordinarily large vendor proprietary attribute or message causing issues with this sensor. That made me think of fragmentation
as a possible problem that is often seen with HTTP, too
I’m still searching but haven’t found it again. Other that I really don’t have any information, if I did I of course would love to share it with you.
Have you seen the log in my post #57 ?

That’s what I thought, but then it confuses me that you make comments like you do, saying what you think is right or wrong, but don’t provide the log that goes with your comments. Please provide the logs or things that you are commenting on so I can provide my thoughts if you want help.

Really? Fragmentation is very seldom used in Zigbee since most packets fit within a single frame. If you are seeing fragmentation in the logs, please provide the log so I can see what is happening. That said, fragmentation in the binding was tested as part of the certification, so it should be fine, but the only time I’ve ever seen it being used is when transferring large SEP certificates to smart meters - the OH binding should never send anything large enough as to require fragmentation.

Post 57 is by @robmac - there is a log in 55 where you talk about an exception - 58 has no log - I’m not really sure what you are looking at.

In any case, I don’t really want to be searching through random logs in random posts. What works best is that when you make a statement like “fragmentation is a problem”, then please provide the log that makes you thing this is an issue, and tell me what part of the log you are looking at. Otherwise I will likely search through loads of logs, looking at stuff to try and find what I think you might be talking about, and I suspect in this case I will not find any fragmented packets. I then go back and ask you why you think it’s fragmented, and it’s just quicker if you post the information right at the beginning.

Sorry if it sounds like I’m being difficult, but I’m trying to help, but to help you, you need to provide the information, and where you say something looks like XYZ, that you point me to what makes you think this.

#57 it is: Testing popular ZigBee devices (and coordinators) - #57 by mstormi

There’s a link to https://community.openhab.org/uploads/short-url/b9F8TfEpdep4kNbIjIf629mGmBp.txt right above the frame with the exception.

It’s a fairly low-noise log with mostly just the failing pairing attempt of the bespoken motion sensor.

But to make it clear I have NO idea why it fails so I cannot point you at anything special in this.
I only noticed this close to the beginning:

2021-04-28 13:08:42.352 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 00158D0006692CB7: Endpoint 1. Unknown remote endpoint
2021-04-28 13:08:42.353 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Incoming message from node 0E20 did not translate to command

Seems to be a bug in the forum which shows this as 56 in the slider on the side -:

I will try and take a look at this tomorrow.

All, please check out this post. @chris do you think you could respond on behalf of our community ? Dunno how many compatible devices you already know about and I doubt anyone to have an even lesser part of the big picture will stand in and respond, but we should not miss that opportunity.

@ blakadder himself now posted in this other thread asked for feedback from community before adding

https://community.openhab.org/t/supported-zigbee-devices-list/122479

1 Like