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.
I've been observing devices that won't reply to ZDO node descriptor requests,
at least not on the first attempt as well as out-of-spec devices which claim
to have an endpoint x but then won't reply on getting the endpoint descriptor.
I have a Lumi (lumi.sensor_switch.aq2) button here which allows to reproduce
both of those. It will never reply on the first attemt.
Anyhow, it happens that the ZDO, waiting on the data indication never finishes
because there does not seem to be a timeout connected to it and it fails initialisation.
Adding a timeout, the code retries and it seems to succeed on the second attempt.
Starting/stopping the permit joining duration timer is not something
each backend should do on it's own. So making the timer a private
member of ZigbeeNetwork and taking control over it internally.
Also reduce some logic about the remaining duration by merging the
related methods into one and hiding the "remaining" duration from
backend implementations completely.
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.
