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
The bug causing level events not to be created happens when the setLevel
command runs in the cloud but the Device Type Handler is running locally
in the hub. Since state is not synced from the cloud to the hub the
`state.trigger` value was never set to `"setLevel"` on the hub which means
no level events would be created. The change is to not be reliant on state.
Instead we just don't create level events if the level is 0 since there is
no legitimate way for the level to be 0.
https://smartthings.atlassian.net/browse/DVCSMP-2219
