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.
1 Like
Not resolved yet? I am waiting because it is the same case.
1 Like
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.
2 Likes
That is the point.
1 Like
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.
2 Likes
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.
1 Like
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.
2 Likes
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)
1 Like
Isn’t it typically the ZHA device type?
1 = 0x0001 On/Off Switch
263 = 0x0107 Light Sensor
770 = 0x0302 Thermostat
1026 = 0x0402 IAS Ancillary
1 Like
Thanks! Do you know any other complete list ?
I found this one…
I’m afraid not. I think the numbers look less random when formatted as hex and it is just more Zigbee. Certainly a profile ID of 260 written as 0x0104 is instantly familiar as ZHA.
Don’t know what the 49353 profile ID means. That is 0xC0C9 which looks vaguely familiar from somewhere. Unfortunately that somewhere is probably the last time I converted it to hex five minutes ago. No hang on it is a private profile for Develco. That must have been something that came up on the forum a little while back that I was Googling around out of curiosity.
1 Like
I see what you’re saying but this information is available during the discovery phase. From what I see (both in Groovy and Edge), that information isn’t reported by the hub.
@orangebucket if these are standard then I guess as a temporary workaround one could assign known endpoints a static device_id (honestly I do hope that the engineers fix the hub firmware to remove this arbitrary limit of 4 endpoints during discovery).
1 Like
Arbitrary and rather tiny given the maximum is about 240.
3 Likes