Michel2/Tasmota
1
0
Fork 0
mirror of https://github.com/arendst/Tasmota.git synced 2026-09-11 09:13:17 +00:00
Code Issues Releases Activity

Fix Zigbee multi-endpoint attribute suffix using insertion order instead of endpoint (#24948)

Browse Source 
Z_Data::toAttributes() added attributes with no explicit suffix, so
Z_attribute_list::addAttribute defaulted to key_suffix =
countAttribute(attr.key) - an insertion-order counter, not the
device's real endpoint. Since toAttributes() is called once per
device.data element, the suffix each endpoint's attribute landed on
depended on device.data's internal list order, which isn't guaranteed
to be endpoint-ascending. On a 4-gang relay whose endpoints were
discovered as [2,1,3,4], this mapped endpoint 2 to bare "Power" and
endpoint 1 to "Power2" - swapped - while 3 and 4 happened to land
correctly.

SetOption101 does not fix this: it's only applied in
Z_postProcessAttributes(), which runs on the live per-message
ZbReceived path and correctly uses the frame's true src_ep. That
corrected data does get merged into device.attr_list, but
zigbee.find(name).info()/ZbStatus2 read from the separate device.data
store via toAttributes(), a parallel path Z_postProcessAttributes()
never touches.

Fix: suffix by the record's true endpoint (Z_Data::getEndpoint()),
matching the same key_suffix = src_ep convention
Z_postProcessAttributes() already uses. getEndpoint() == 0 ("any
endpoint") falls back to the original count-based behavior, unchanged.

Verified on hardware: a Tuya TS0004 4-gang relay with a non-ascending
Config list now reports all 4 endpoints under their correct suffix,
with no regression on a naturally-ordered multi-endpoint device.
This commit is contained in:
LesNewell
2026-08-21 11:51:58 +02:00
committed by GitHub
parent c988ddfc2f
commit accf05b21b
1 changed files with 5 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tasmota/tasmota_xdrv_driver/xdrv_23_zigbee_5_2_converters.ino
+5 -1
View File
@@ -1757,7 +1757,11 @@ void Z_Data::toAttributes(Z_attribute_list & attr_list) const {
case Zint32: ival32 = *(int32_t*)attr_address; if (ival32 != -0x80000000) data_size = -32; break;
}
if (data_size != 0) {
Z_attribute & attr = attr_list.addAttribute(conv_name);
// suffix by true endpoint (matching Z_postProcessAttributes' src_ep convention), not by
// insertion-order count - device.data isn't guaranteed to be in endpoint order, so the
// default count-based suffix can mislabel attributes on devices with non-ascending
// per-endpoint data (e.g. a 4-gang relay reporting endpoints out of order).
Z_attribute & attr = attr_list.addAttribute(conv_name, false, getEndpoint());
float fval;
if (data_size > 0) { fval = uval32; }