Zigbee EndpointId set as null on pairing

🚧 Developers Coding Questions
1

Continuing the discussion from [RELEASE] Aqara (B1) Smart Curtain Motor (ZNCLDJ11LM & ZNCLDJ12LM) Driver:

@mike.maxwell In short, when pairing this particular Zigbee curtain the endpointId is set to null instead of 01 as expected. I have the exact same device and when pairing it (all of mine actually) I always get them with the expected endpointId 01.

The questions:

  • Is there a way to set the correct endpointId from inside a driver in case it is wrong?
  • If not, why does this happen? Is it a mesh issue with corrupt data being received? But the same corrupt data every time the device is paired? Is data "cached" even if the device is removed and re-paired?
2

As part of the discovery process the device is queried for a list of endpoints and clusters.
So in this case for whatever reason it is not returning this value.
If you say this is a one off situation, then I would say it's a broken device and just replace it.
It's difficult to say exactly what it's doing without sniffing the frames while it's joining.
This is the first time I've ever heard of this issue, hence me thinking this specific device isn't working properly.

1 Like
3

I should have mentioned it earlier, but when on ST he does get the correct Endpoint Id for this curtain. The only real difference is that he has two different Zigbee meshes.
Having him sniff the frames is probably a bit outside of what he can do, so I guess we're stuck with my ugly "patch" of the zigbee commands replacing 0xnull with 0x01.
It is the first time I see this as well, so I was surprised when I saw 0xnull in the command strings.

So, in short, there is no real solution that can be tried at this point, right?

4

I suppose it's possible this issue is related to the channel the radio is on?, maybe that's the reason it works on ST?

We do the same things in the same order that ST does for zigbee discovery...
I beleive (but would need to confirm) that the endpoint id for the zigbee helper commands is read from the drivers data section, if so that value can be written to, if not then you would need to generate the commands using the cmd syntax where you can set the endpoint id manually.

1 Like
5

It could be, but he's on channel 20, so it is usually not an issue. As far as the device is concerned it doesn't have problems with that channel since it is one of the 3 channels Aqara use. So unless there is congestion in that frequency or he just hasn't built a very stong mesh yet, I wouldn't know.

It does end up in the Data section, but when I try to write there I get TWO instances of endpointId. I tried to move it to endpoint 02 on my own hub just to test it, it doesn't work.

That is what I did, or rather, I'm wrapping the commands building the strings and replacing 0xnull with 0x01.

ArrayList<String> zigbeeCommand(Integer cluster, Integer command, Map additionalParams, int delay = 2000, String... payload) {
    ArrayList<String> cmd = zigbee.command(cluster, command, additionalParams, delay, payload)
    cmd[0] = cmd[0].replace('0xnull', '0x01')
    return cmd
}

Thank you for looking at this! Another thing, how about that STRUCT-parsing that fails in zigbee.parseDescriptionAsMap?

6

My ST is also on channel 20. Also, I have no zigbee device on my ST (I only have HubConnect devices in fact because my wife likes the ST mobile app) so it's unlikely it's because of a better mesh on ST.

I tried it using 2 Aqara curtains and had the same issue with both so I doubt either of them is faulty.

7

@yototogblo which HE hub firmware version are you running?

8

It's on the todo list, however I wouldn't lie awake waiting for this to be fixed...

1 Like
9

@mike.maxwell As long as it's on the list :slight_smile: I have a workaround in place anyway

10

Was on 2.2.0.122. Upgrading to 2.2.0.125 now though