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
* original Health check implementation did not send refresh() commands to hub and thus the device. This fixes that problem.
* updated() does not have its return value processed as a list of hub commands. These must be sent explicitly
* Explicit returns rock
This adds support for ETI devices which have a firmware bug in which the
binding table is not properly cleared on network leave. So the DTH will
on configure (and refresh) look at the binding table and remove any
entries to not the current hub.
This resolves: https://smartthings.atlassian.net/browse/DVCSMP-2175
Currently these DTHs return null when they parse a message that they
don't have specific handling for. This ends up sending the message up
to the cloud as an event, which prevented us from potentially parsing
that message in the cloud. By instead returning an empty map we can
instead send the message up to the cloud to be parsed there. This
allows us to add handling in the cloud for new message without requiring
and AppEngine deploy for them to work.
This resolves: https://smartthings.atlassian.net/browse/DPROT-200
