This is a continuation of this ticket. nrf54l15 zigbee end-device is bound with its On/Off client cluster to a On/Off server cluster of another ZigBee smart lamp.
I can see with a wireshark sniffing that this device sends when appropriate On or Off commands to the short address it takes apparently from internal table.
Now it happened so that for some reason (irrelevant to this case) that smart lamp has changed its short address. So the one nrf54l15 is using is no more valid.
Old one: 0xb7cf, new one: 0x56a8
I can see from the sniffed traffic, that after a couple of failed attempts to send the command, nrf54l15 sends a broadcast request to resolve the short address by the IEEE MAC address.
And the lamp in question indeed answers that broadcast request, telling it's current short address (0x56a8) to which nrf54l15 also sends an ACK.
But that's it: no On/Off command with the correct short address is sent after this seemingly successful resolution. However what's worse: on the next event when on/off command is sent
it's sent to the same old address 0xb7cf, not the new one.
So apparently as the result of that broadcast request the new, correct short address was not properly updated in the binding table's entry.
Could devs check this code path, please?