Zigbee Source Endpoint of IAS "zone status" message

Devices & Integrations
,
1

How can I see the source Zigbee Endpoint of an IAS Zone Status message?

Background Info:
I’m building an 8-port IAS Zone contact sensor as a single Zigbee device - with a Zigbee Endpoint per contact sensor - so 8 Zigbee endpoints on the device.

When reading an endpoint attribute, the parse description of the device handler sees the raw Zigbee packet and I can parse out the Zigbee source endpoint to know which port is reporting it’s status. So this works fine.
for example: [raw:0104 0500 01 01 0C40 00 C2E4 00 00 0000 01 01 020000190000, profileId:0104, clusterId:0500, sourceEndpoint:01, destinationEndpoint:01, options:0C40, messageType:00, dni:C2E4, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, attrId:0002, resultCode:00, encoding:19, value:0000, isValidForDataType:true, data:[02, 00, 00, 19, 00, 00], clusterInt:1280, attrInt:2, commandInt:1]

However, when the device sends an IAS Zone Status update, the parse description of the device handler does not include the raw zigbee data, only the text “zone status 0x0001 – extended status 0xA1” which is the same text no matter which source endpoint (contact sensor) sent the status update.

So the question: How can I see the source Zigbee Endpoint of an IAS Zone Status message?

Thank you.

2

Most likely ST will need to do work on the backend to either not pre-parse the IAS Zone Status update or add the Source Endpoint to the pre-parsed message. This is a similar issue for Temperature reports and a couple other ZigBee message types that were common in the first couple ST devices. I think they made an update for Temp reporting to show the endpoint, but multiple endpoint devices are still a work in progress with ST. You might be able to use the “Composite Device” structure to do this, but probably not until you get that endpoint exposed in the parse message.

Maybe @tpmanley can shed some more light for you.

1 Like
3

Sticks18 has pretty much got it. Multi-endpoint devices are not well supported in our current system, and for legacy reasons it is very hard for us to change the shape of messages coming up. We always have to worry about self published DTHs that could break if we change what the message that is passed to parse looks like. It is certainly something we would like to support, but right now there isn’t a way to do what you want to do. I don’t know what level of “building” the device you are talking about, but if you are writing the firmware yourself, you could use custom attributes and report the values that way, but then you are straying from the ZCL spec just to work around our system. Currently any IAS Zone Status change will undergo the transformation that will lose the endpoint information, unfortunately.

1 Like