The router broadcast address 0xFFFC is not a group addres, but a
"regular" address. Setting the destinationAddressMode to GroupAddress
caused the message to not be broadcastet and permit joining was only
enabled on the coordinator.
This caused mainly the issue that joining a network would not work
if the coordinator is out of reach.
In addition to that, there are quite a bit of end devices out there
which behave badly in finding new parents and will stick to the node
they joined in the first place forever, causing them to have bad
signal if further away from the coordinator, even though there
would be routers with much better LQI.
Additionally it fixes a permit joining issue in the TI backend which would
prevent a call to setPermitJoining(0) to explicitly allow joining
only on the coordinator.
The change of radius from 10 to 30 probably isn't needed for 99% of the
networks, however, it may still help for that one percent that does
indeed have a network depth of > 10. Looking at other implementations
out there, 30 seems to be the common sense.
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.
