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 may happen on very rare occations after a nymea restart
if the controller is taking too long to initialize but still succeeds
in the end. Also increases the timeout for the procedure.
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.
* Prevent resetting the duration repeatedly by not calling setPermitJoiningState
in the timer any more
* Added signal emissions for when remaining changes in an unexpected manner.
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.
jenkins
Michael Zanetti
Simon Stürz
Jenkins nymea