Originally the intention was to add the commandReceived() signal to
the ColorControl cluster but noticing differences in various clusters
wrt commandSent() and commandReceived() namings of those signals.
Decided to commandReceived() as it feels more natural to use
and also the Zigbee cluster spec uses that wording.
Instead of having 2 methods (setAttribute and addOrUpdateAttribute)
to allow specific cluster implementations to override behavior,
merge them into one, setAttribute, and use standard C++ syntax for
calling a base class implementation.
This patch separates the transactionSequenceNumber used for sending from the
one received. According to the specification, the transactionSequenceNumber is
not meant to equally increase on both ends, but instead really just be a "random"
number which allows to match a reply to a request. Syncing them on both ends
has the outcome to increase the likelyhood of collisions if a device sends
a notification at the same time we send a request and thus even may wrongly
interpret that incoming command as a reply to the request. In fact, ideally TSNs for
outgoing messages would stay away as far as possible from incoming ones.
The old code additionally had the problem that it would re-use the last received
TSN for outgoing requests, given it used a post-increment when reading
m_transactionSequenceNumber after setting it to the last received TSN.
The new code will use a single static upcounting TSN for all outgoing requests
but will still allow overriding it with a custom TSN of for some reason a certain
device requires a specific TSN (apparently those exist).
It will not do anything with incoming TSNs but forward them now to the application
layer which may decide to use it match its own transactions or to deduplicate packets.
This allows fixing the issue in nymea that remote controls sometimes produce duplicate
pressed events (seen most often with the Tradfri Symfonisk) by discarding commands that
didn't increase the TSN.
Simon Stürz
Michael Zanetti
Simon Stürz