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.
This alignes the OnOff cluster with the LevelControl cluster in terms
of signal behavior: Previously, the OnOff cluster would fire a generic
commandSent() signal for some commands and specific signals for others.
Effectively forcing the user to connect multiple signals even if only
the command would be of interest.
The LevelControl cluster instead always fired a generic commandSent()
signal and *additionally* more specific signals for parsed parameters.
This changes the OnOff cluster to be in line with the LevelCluster
as and making the API a bit simpler to use when parameters are not of
interest.
Also it completes the specific parsing for all 3 clusters.
jenkins
Michael Zanetti
Simon Stürz
Simon Stürz