Cree Bulb Driver minor annoying issue

📢 Feedback
1

@mike.maxwell

Mike,

You seem to be the go-to-guy for Zigbee/Z-Wave Drivers support. So, here is an easy one. I have noticed that the “Cree Bulb” Driver does not properly update the “switch” attribute to “on” when it is turned on via a “Set Dim Level” type of command. I have a Button Controller which I was testing out when I found the issue.

This can be demonstrated very easily by bringing up the device page in Hubitat, Make sure the “switch” attribute is set to “off” and that the device is truly off. Then, using the manual “Set Level” button on the screen, set the dim level to any value above zero. The light will turn on successfully, but the “switch” attribute stays “off”.

I also have a few “GE Link Bulb” devices using the native Hubitat driver. These behave correctly, so it appears to be specific to the “Cree Bulb” driver.

Hopefully there is a quick fix for this.

Thanks,

Dan

2

Ha, it figures, I didn’t test that driver…
Thanks, should be a quick fix.

1 Like
3

fix in the next release!

4

Thank you! Any ETA on when the next release is going to be available? Is Hubitat planning on a regular schedule for releases? Or just when the team feels it is time? Just curious…

5

Hi Mike. Just loaded the new 698 firmware and this bug appears to still be present… actually it may have gotten worse.

Now the GE Link Driver, and the Zigbee Dimmer Driver, as well as the Cree Bulb Driver are all misbehaving the same.

Again, if the dimmer switch is OFF, setting the DIM Level above zero does turn on the bulb to the correct level, however the ‘switch’ attribute still is shown as ‘off’

Also, none of these drivers now show the ‘level’ attribute at all.

Hopefully you can get these drivers fixed for the next firmware version.

Thanks,
Dan

6

Thanks for the heads up, looks like the changes didn’t make it in this release. I swear I committed them, I swear…

2 Likes
7

i loaded each of these drivers on a Osram A19, none of them are behaving as you describe.
What bulb(s) devices are you seeing this issue on?

8

I have 4 Cree bulbs and 2 GE Link bulbs.

9

Are these drivers expecting a Zigbee response from the bulb before ever updating the ‘level’ attribute? And if so, does this also cause the ‘switch’ attribute to be updated?

Perhaps these bulbs do not properly handshake? Should the driver just update these attributes upon issuing the command, instead of waiting for the response?

I am just guessing out loud… I am no Zigbee expert.

If I can provide any data to help understand and correct this, I’d be happy to.

10

yes...

it's possible that the reporting configuration settings are incorrect, we try to avoid setting attribute states without confirmation from the device..

I've ordered these bulbs, so that I can see exactly what they're doing.

2 Likes
11

Thanks Mike!

12

Mike,

I have been doing some experimenting this morning, and thought I’d pass along my findings. I appreciate the fact that you’ve ordered some of these bulbs, and I am patient. No rush. Just wanted to provide as much information as possible.

Using the GE Link Bulb, with the Hubitat “GE Link Bulb” Driver, I am able to get the driver to properly update the ‘switch’ attribute after I pressed the “CONFIGURE” button in the Device Page. So, now the bulb properly reflects the ‘switch’ attribute status in most cases.

  • Press the “CONFIGURE” button
  • Press the “ON” button, ‘switch’ attribute changes to ‘on’
  • Press the “OFF” button, ‘switch’ attribute changes to ‘off’
  • with the bulb ‘off’, pressing the “SET LEVEL” button with value greater than 0, causes the bulb to turn on, and the ‘switch’ attribute changes to ‘on’ correctly.
  • with the bulb 'on, pressing the “SET LEVEL” button with value = 0, causes no change. (Not sure what the correct behavior is in this case. I would hope setting the ‘level’ to zero would simply turn ‘off’ the bulb, but not sure what the spec says.)

In all cases above, there is NEVER a ‘level’ attribute displayed on the device page.

Using the Cree Bulb, with the Hubitat “Cree Bulb” Driver, I am not able to get the driver to properly update the ‘switch’ attribute, even after I pressed the “CONFIGURE” button in the Device Page, in all cases. See below:

  • Press the “CONFIGURE” button
  • Press the “ON” button, ‘switch’ attribute changes to ‘on’
  • Press the “OFF” button, ‘switch’ attribute changes to ‘off’
  • with the bulb ‘off’, pressing the “SET LEVEL” button with value greater than 0, causes the bulb to turn on, BUT the ‘switch’ attribute remains showing ‘off’
  • with the bulb 'on, pressing the “SET LEVEL” button with value = 0, causes no change. (Not sure what the correct behavior is in this case. I would hope setting the ‘level’ to zero would simply turn ‘off’ the bulb, but not sure what the spec says.)

In all cases above, there is NEVER a ‘level’ attribute displayed on the device page.

I tried using the Hubitat “GE Link Bulb” & the “Zigbee Dimmer” Driver on the Cree Bulb with the same results.

When I press “CONFIGURE” using the Cree Bulb (with the native Cree Bulb Driver), I get the following in the new Zigbee Logs and the normal Logs:

In new Zigbee Logs

[Upstairs Hallway](http://192.168.1.144/hub/zigbeeLogs#zigbeeRx10881)2018-02-25 12:22:05.942 profileId:0x104, clusterId:0x8, sourceEndpoint:0, destinationEndpoint:1 , groupId:0, lastHopLqi:177, lastHopRssi:-52

[Upstairs Hallway](http://192.168.1.144/hub/zigbeeLogs#zigbeeRx10881)2018-02-25 12:22:03.928 profileId:0x0, clusterId:0x8021, sourceEndpoint:0, destinationEndpoint:0 , groupId:0, lastHopLqi:183, lastHopRssi:-52

[Upstairs Hallway](http://192.168.1.144/hub/zigbeeLogs#zigbeeRx10881)2018-02-25 12:22:02.013 profileId:0x104, clusterId:0x6, sourceEndpoint:0, destinationEndpoint:1 , groupId:0, lastHopLqi:159, lastHopRssi:-52

[Upstairs Hallway](http://192.168.1.144/hub/zigbeeLogs#zigbeeRx10881)2018-02-25 12:21:59.995 profileId:0x0, clusterId:0x8021, sourceEndpoint:0, destinationEndpoint:0 , groupId:0, lastHopLqi:196, lastHopRssi:-52

In the normal Logs

[dev:1](http://192.168.1.144/logs#dev1)2018-02-25 12:22:05.922:debug[raw:catchall: 0104 0008 00 01 0040 00 2A81 00 00 0000 07 01 85000000, profileId:0104, clusterId:0008, clusterInt:8, sourceEndpoint:00, destinationEndpoint:01, options:0040, messageType:00, dni:2A81, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[85, 00, 00, 00]]

[dev:1](http://192.168.1.144/logs#dev1)2018-02-25 12:22:05.920:debugDID NOT PARSE MESSAGE for description : catchall: 0104 0008 00 01 0040 00 2A81 00 00 0000 07 01 85000000

[dev:1](http://192.168.1.144/logs#dev1)2018-02-25 12:22:01.926:debug[raw:catchall: 0104 0006 00 01 0040 00 2A81 00 00 0000 07 01 00000000, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:01, options:0040, messageType:00, dni:2A81, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00, 00, 00, 00]]

[dev:1](http://192.168.1.144/logs#dev1)2018-02-25 12:22:01.925:debugDID NOT PARSE MESSAGE for description : catchall: 0104 0006 00 01 0040 00 2A81 00 00 0000 07 01 00000000

[dev:1](http://192.168.1.144/logs#dev1)2018-02-25 12:21:59.828:debugConfiguring Reporting and Bindings.

I am sure once you get the bulbs you will be able to sort this out. Thanks again for your hard work making this platform a great one!

1 Like
13

@mike.maxwell

Mike,

The new Generic Zigbee Bulb driver in 701 is working great with my Cree and GE Link bulbs.

Thank you, thank you, thank you!

Dan

3 Likes
14

What advantage do they have over the specific drivers?

15

The specific drivers didn’t work as well as they should have, and in the end there was no need for separate drivers for this device type.

1 Like
16

Dumb question, but is is possible to write the generic Zigbee bulb driver to report offline bulbs as OFF instead of last state (typically ON)?? I’m asking because I have found that this will lock up rules if they are looking for a bulb to be in the off state but it was turned off by a physical switch and is therefore offline, but it will continue to report as ON and stop any rules from running otherwise. (I have a series of “cascade” rules tied to single Zigbee buttons)
I think with bulbs, this is a credible request since they can be installed in lamps that have physical switches. I kinda want to please the rest of the family, and they really like the “cascade” rules I made but they stop working of someone simply switches a light of with a “real” switch.

17

If you use Sengled smart bulbs, along with the Sengled Bulb drivers, these bulbs actually report their status as “off” as a last gasp transmission when power is cut to these bulbs.

2 Likes
18

This isn't possible unless the bulb supports this, and only sengleds do.
Trying to figure this out with any level of accuracy requires some level of polling, which we just aren't going to implement for this situation.

If you're using bulbs (with the exception of singleds), they need to have a constant supply of power, placing them on the end of a switch is going to cause you nothing but issues, as you have already noticed.

2 Likes
19

An easy way to solve this is to get some Sylvania Lightify Dimmers. They go over the existing light switch, this preventing someone from cutting power to the bulb. I have one in every room where I don't have a neutral wire to put an actual smart switch.

Sylvania Smart Home 73743 Lightify Smart Dimming Switch, Dimmer, White https://www.amazon.com/dp/B0196M620Y/ref=cm_sw_r_cp_apa_i_MEUVDbVG4E8ZY