Resets may occur by unplugging the stick or calling a softReset() from
the software side.
Additionally resets the stick when 5 subsequent timeouts happen
as there are firmwares of the CC2652 available which tend to
crash occationally.
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.
Main reasoning behind this is actually that Tuya devices seem
to send a CancelMessage command every other minute and are currently
spamming the log with unhandled ZCL indication warnings.
Instead of just silencing the warning (which is very useful most of the times)
I decided to complete the implementation of the metering cluster and
actually make it a handled ZCL indication.
This is basically the same as #41 does with ZDO replies but for ZCL replies.
Working with a z-stack dongle and a Gewiss binary input device a lot of
timeouts happen during the device interview. While basic device interview
timeouts are caught by the ZDO timeouts, later interview steps like
cluster attribute reading run into the same issue with this device and
the interview process never finishes.
Renamed the SimpleMetering enum to Metering as that's what it is in the Zigbee
Alliance Spec. SimpleMetering seems to come from a NXP document which
isn't complete though and the upstream spec is what matters in the end.
Also adds some cluster ids which are in the Zigbee spec but missing in
the NXP document.
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
Jenkins nymea
Simon Stürz