This is because ZLL bulbs do not report or allow for configuration of
reporting of attributes. As a result if we change a value, we have to
manually call a read of that attribute to update our status.
This is a part of: https://smartthings.atlassian.net/browse/DPROT-227
This changes our smartsense DTHs that don't use the ZigBee library for
everything to have larger delays between ZigBee messages. This is to
reduce the network load to try to work around some of the poorer
behaving ZigBee routers we support.
This resolves: https://smartthings.atlassian.net/browse/DPROT-223
With the changes made for
https://smartthings.atlassian.net/browse/DPROT-200 there were a few DTHs
that were using sendEvent to directly send events generated during
parse. However, because using sendEvent didn't result in parse
returning an event AppEngine would send the description up to the cloud
DTH to be handled. In some cases this resulted in multiple events for
the same device trigger.
This resolves: https://smartthings.atlassian.net/browse/DPROT-215
The configureHealthCheck method and therefore the configure method was
returning a boolean which was causing an exception during the initial
join that would prevent the device from showing up to the user.
https://smartthings.atlassian.net/browse/PROB-1428
(1) SYLVANIA Smart BR30 Softw White
(2) SYLVANIA Smart PAR38 Softw White
(3) SYLVANIA Smart Outdoor RGBW Flex
2. Modify deviceJoinName of NAFTA Lightify product, all the lightify product which use ZHA protocol will be named using "SYLVANIA Smart XXXX".
(1) OSRAM LIGHTIFY Gardenpole RGBW
(2) OSRAM LIGHTIFY Outdoor Flex RGBW
(3) OSRAM LIGHTIFY RGBW PAR 16 50
(4) OSRAM LIGHTIFY Flex RGBW, this product uses ZLL, so move it from zigbee-white-color-temperature-bulb to zll-white-color-temperature-bulb
(5) OSRAM LIGHTIFY Classic B40 Tunable White, this product uses ZLL, so move it from zigbee-white-color-temperature-bulb to zll-white-color-temperature-bulb
There was a bug when comparing the destination address for binding table
entries that would cause all binding table entries to be deleted. This
fixes that.
This is a fix for: https://smartthings.atlassian.net/browse/DVCSMP-2175
Previously the implementation of isKnownDescription didn't cover all
possible messages that could be parsed and this caused null pointer
exceptions with certain messages. This now handles all the
possibilities.
This resolves: https://smartthings.atlassian.net/browse/DVCSMP-2227
