So at last in this log, I think the reason that it stays pending is that the device never sends the confirmation report -:
The binding sends the code ok, and then sends a request to read back the code, and this does not get the required response. There are some timeouts here, so maybe that is contributing to the issues - it’s hard for me to comment on that.
The transaction I think is not retried as there was a low level ack to the secure transaction, so it then stays pending.
In the earlier log, the readback of the data was there. It’s hard to say why it’s not received this time - could be an RF lost packet in either direction. Security makes things a lot more difficult to work through as there is around twice the amount of traffic with the nonce requests that are also going on.
I’m really surprised at this since it is forbidden in the protocol. I know Fibaro was doing this at one point, but they had to remove it.
The nonce really doesn’t have anything to do with this issue. If the nonce is wrong, then the data will not be received and clearly the log shows that the report was received. The pending flag is just a binding feature.
Ok, agreed it could be anything … But the fact that it is so easily repeatable tends to point to something more specific. RF noise happens all the time and the protocol is designed to account for some level of interference - A single lost packet can’t possibly cause this process to fail.
I would agree with your interpretation - the device seems to be sending a report following the SET command. That’s not to say that is it correct, or allowed within the ZWave plus specifications, which state the following -:
