Did you install again or repair the device?
i deleted and reinstalled the driver. then I paired the device
Date
application: 43
endpointId: 01
manufacturer: _TYZB01_b1ngbmlm
model: TS0112
zigbeeNodeType: ROUTER
Raw Description
01 0104 0051 00 07 0000 0003 0004 0005 0006 0702 0B04 01 0019
Could you also add this device?
It only has two endpoints 1 and 2
Based on the raw description, it seems completely different from the others.
0702 = Simple Metering
0B04 = Electrical Measurement
I don’t have any device with these clusters. Can’t help you this time.
It could have the basic functionalities, but it would lose others.
No it Orly dual plug on off. Main and child
Just found it already is supported by this driver…
Let’s concentrate the thread to the subject about missing endpoints.
Not resolved yet? I am waiting because it is the same case.
The key question is why is the platform only discovering 4 instead of 5 endpoints. I’m also seeing the same issue with another device, it’s missing the discovery of an entire endpoint. I can communicate with the endpoint manually by reading it but the hub won’t bind to it because it appear my can’t discover the endpoint so I don’t get regular updates from it.
That is the point.
Historically, SmartThings has a bad design habit of setting maximums based on a particular device sitting in front of the designer, rather than checking the protocol specification.
Anyway, for the record, here are the endpoint maximums from the independent third party specs:
Zwave
The theoretical end point value is in the range of 0…127.
So 128. (0 is an address.)
However, there is a separate issue in that only the first 7 can be reached with a multicast. So many resources will incorrectly (or correctly, but you have to understand the context) state 7, but you can still reach the others individually.
The Multi Channel multicast feature may be used to send a Set command to the first 7 End Points. Alternatively, one may communicate to each individual End Point. This works for Set as well as Get commands.
Zigbee
In Zigbee the “node address” is the physical device (the radio). Each physical device can contain up to 240 “logical” devices (endpoints).
So since SmartThings is a multi protocol platform, the architecture should be designed to handle up to 240 endpoints per device.
We should also note that some designers think of endpoints as only being used for actionable sub components, like switch buttons or powerstrip sockets. But they are also used to receive data from sensors. Thermostats are historically multi endpoint: one ep to receive actionable commands, and another to send current room temperature.
I’m checking the progress with the team but for now, you can use the workaround shared by @w35l3y at the beginning of this thread:
The team mentioned it is a great option until the issue is resolved:
CC: @RBoy
Thank you for sharing the info above, @JDRoberts I already shared it with the team.
I can also confirm this behavior, I’m also noticing that devices with more than 4 endpoints are only registering the first 4 endpoints in the device.zigbee_endpoints
and then it can’t bind or complete configure_reporting on the non discovered endpoints. I have a device with 7 endpoints, only the 4 of them are showing up.
1={
client_clusters={},
device_id=1,
id=1,
profile_id=49353,
server_clusters={
1=3,
2=5,
3=6,
},
},
34={
client_clusters={},
device_id=263,
id=34,
manufacturer="XXX",
model="XXX",
profile_id=260,
server_clusters={
1=0,
2=3,
3=1030,
},
},
35={
client_clusters={
1=10,
2=25,
},
device_id=1026,
id=35,
manufacturer="XXX",
model="XXX",
profile_id=260,
server_clusters={
1=0,
2=1,
3=3,
4=15,
5=32,
6=1280,
},
},
38={
client_clusters={
1=3,
},
device_id=770,
id=38,
manufacturer="XXX",
model="XXX",
profile_id=260,
server_clusters={
1=0,
2=3,
3=1026,
},
},
In the above it’s missing endpoints 0x27, 0x28 and 0x29 on the device (only the first 4 are showing up, 0x01, 0x22, 0x23 and 0x26)
In this case each of the missing endpoints represent new functionality (e.g. VOC endpoint, Illuminance endpoint etc) so I can’t just copy the structure from existing endpoints. Additionally the device_id
is different for each endpoint so I’m not sure if this workaround will work as expected.
I was asked about maximum endpoints for Thread and for Matter.
As far as I know, matter isn’t going to specify a maximum: it will just go with the maximums already set by each participating protocol.
I haven’t personally worked with thread. My understanding from Eve documents is that they use the term “endpoint“ differently: it’s used the same way as “child device“ would be used in Zigbee. With a Thread router as the parent. Each thread router can connect to up to 511 different “endpoints“ (children), but each endpoint device has its own unique address, so it’s just a whole different paradigm. Basically your light switch, smart bulb, and smart plug would each be an “endpoint” to the thread router.
I don’t know how they handle a multi component device like a thermostat or a multi sensor, so I don’t know what the maximums are for those.
The original thread protocol specifications called the child devices “end devices“ not “endpoints,“ which personally I prefer. I don’t know when it changed. Maybe somebody thought they were aligning it with IPv6 Terminology?
And I see that Google is still using the original “end device” terminology:
https://openthread.io/guides/thread-primer/node-roles-and-types
A friend of mine who has been looking at the Eve Thread products says that their environmental sensor only has one end device address. He says it uses “characteristic” codes to indicate whether it is sending the humidity or the temperature or the VOC count. Not The equivalent of separate Zigbee endpoints. But I don’t know if that’s going to be the standard.
@andresg Nayely asked me tag you on this
This workaround is a problem in my case. I’m noticing that devices with more than 4 endpoints are only registering the first 4 endpoints in the device.zigbee_endpoints
and then it can’t bind or complete configure_reporting on the non discovered endpoints. I have a device with 7 endpoints, only the 4 of them are showing up.
1={
client_clusters={},
device_id=1,
id=1,
profile_id=49353,
server_clusters={
1=3,
2=5,
3=6,
},
},
34={
client_clusters={},
device_id=263,
id=34,
manufacturer="XXX",
model="XXX",
profile_id=260,
server_clusters={
1=0,
2=3,
3=1030,
},
},
35={
client_clusters={
1=10,
2=25,
},
device_id=1026,
id=35,
manufacturer="XXX",
model="XXX",
profile_id=260,
server_clusters={
1=0,
2=1,
3=3,
4=15,
5=32,
6=1280,
},
},
38={
client_clusters={
1=3,
},
device_id=770,
id=38,
manufacturer="XXX",
model="XXX",
profile_id=260,
server_clusters={
1=0,
2=3,
3=1026,
},
},
In the above it’s missing endpoints 0x27, 0x28 and 0x29 on the device (only the first 4 are showing up, 0x01, 0x22, 0x23 and 0x26)
In this case each of the missing endpoints represent new functionality (e.g. VOC endpoint, Illuminance endpoint etc) so I can’t just copy the structure from existing endpoints as the server and client clusters are different for each endpoint. Additionally the device_id
is different for each endpoint.
I used this approach because I saw that the details of the fifth endpoint were equal to the others, but you can specify them by yourself without copying from anything.
I know this is not the best thing to do, but that is what we have for now.
You could start with one more endpoint and add the others later.
What about the device_id
, that’s unique to each endpoint, I haven’t dug into the libraries yet but I’m guessing it’s not random?
You are right. I always thought deviceId
were part of the fingerprint.
But now I think the deviceId
defined there is for the main endpoint.
I found this post: [ST Edge] DeviceId and Zigbee profileId in Edge driver's fingerprint - #2 by nayelyz
zigbeeGeneric:
- id: "dimmer-generic"
deviceLabel: "Zigbee Dimmer"
zigbeeProfiles:
- 0x0104 # HA or
- 0xC05E #ZLL
deviceIdentifiers:
- 0x0101 # Dimmable light
clusters:
server:
- 0x0006 # on/off cluster
- 0x0008 # level control cluster
client:
- 0x0019 # outCluster if needed
deviceProfileName: on-off-level-bulb
So deviceId
follows a pattern.
PS.: deviceId
is an excellent subject for a new thread.
Not deviceId
but device_id
. I believe they are different. One if for the profile and the other is an internal control structure member.
01 0104 010A 01 07 0000 0003 0004 0005 0006 E000 E001 02 0019 000A
A B C D E F G H
A = endpointId / id
B = profileId / profile_id / zigbeeProfiles
C = deviceId / device_id / deviceIdentifiers
D = ???
E = number of inClusters
F = inClusters / server_clusters / server clusters
G = number of outClusters
H = outClusters / client_clusters / client clusters
In the example of the topic, 266 (dec) = 010A (hexa)
Isn’t it typically the ZHA device type?
1 = 0x0001 On/Off Switch
263 = 0x0107 Light Sensor
770 = 0x0302 Thermostat
1026 = 0x0402 IAS Ancillary