Cree to offer Zigbee LED smart bulb

Devices & Integrations
123

Great to hear! Let me know if you have issues with the on/off status updating correctly or see the level go to zero unexpectedly. Without testing, those are the two most likely issues if I got the clusterId logic wrong.

124

Thanks a lot, Scott. I’ll try out the new code tonight…however, can I ask what user visible problem this will solve (if any), or is it just an internal optimization that will reduce events happening during a refresh?

125

Based on the event messages issue and the logs, the on/off status should have been reporting incorrectly. Every level message in the “catchall” format should have triggered an “off” status event, which would result in the fluctuating messages. It didn’t sound like users were reporting status sync issues where the bulb was on, but the app thought it was off, but this code should make sure that doesn’t happen by properly parsing the on/off and level clusters separately.

One of these days, I’ll spend more time and update the parse() for this and the GE Link; so it’s easier to follow. This is a bit of patching holes with new conditionals instead of taking a step back and rewriting from ground up.

126

Getting the following when trying to create new device from code - I’m too n00b to know how to troubleshoot. I tried some basic pattern matching but can’t figure out where the issue may be coming from.

Org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [physicalgraph.device.Capability#98]

EDIT: nm, appeared to be copy/paste error. copying from original reply message worked.

127

Ditto to Jeremy J’s comment!

128

Getting this error from device type:

1:06:59 PM MST: error java.lang.NumberFormatException: For input string: "1 " @ line 145
1:06:59 PM MST: debug Level message
1:06:59 PM MST: trace catchall: 0104 0008 0A 01 0140 00 48D4 00 00 0000 0B 01 0400
1:06:58 PM MST: debug [st cmd 0x48D4 10 8 4 {85 1500}]

129

Thanks for the bug report Bruce! That’s just a default message that only tells us the bulb received the command. I’ve added a check for that in the parse and we’ll ignore it. Below is a link for the GitHub version of this device-type. Going forward, I will update the GitHub version with any bug fixes, so grab it from there and you’ll always get the most recent version (Use the Raw button to ensure clean copy/paste into ST).

https://github.com/sticks18/My-Cree-Bulb-beta/blob/master/My_Cree_Bulb_beta.groovy

1 Like
Is there a SmartApp to create and trigger lighting scenes?
130

I’m seeing some strange behaviour when hitting refresh the cree. It will alternate between reporting 99% and 52%.
The actual light level doesn’t change through.
Any suggestions?

    2015-02-08 6:58:54.262 PM CST
moments ago	DEVICE		switch.setLevel	52		Hallway Cree set level is 52	true
2015-02-08 6:58:54.243 PM CST
moments ago	DEVICE		level	52		Hallway Cree level is 52	true
2015-02-08 6:58:53.719 PM CST
moments ago	DEVICE		switch.setLevel	98		Hallway Cree set level is 98	true
2015-02-08 6:58:53.701 PM CST
moments ago	DEVICE		level	98		Hallway Cree level is 98	true
2015-02-08 6:58:52.989 PM CST
moments ago	COMMAND			refresh		refresh command was sent to Hallway Cree	true
2015-02-08 6:58:35.461 PM CST
moments ago	COMMAND			setLevel		setLevel(99) command was sent to Hallway Cree	true
131

The parse is getting something wrong. If you turn on live logging in the IDE and hit refresh, you should get more debugging info that could help troubleshoot.

132

@Sticks18
Here is the debug info for sequence:

  1. Set level 99

  2. Refresh

    3936ac6a-bac5-409c-ba35-096dcd43ae80 11:14:34 AM: debug Level message
    3936ac6a-bac5-409c-ba35-096dcd43ae80 11:14:34 AM: trace catchall: 0104 0008 0A 01 0140 00 5F04 00 00 0000 04 01 861000
    3936ac6a-bac5-409c-ba35-096dcd43ae80 11:14:33 AM: trace read attr - raw: 5F040A00080A00000020FC, dni: 5F04, endpoint: 0A, cluster: 0008, size: 0A, attrId: 0000, result: success, encoding: 20, value: fc
    3936ac6a-bac5-409c-ba35-096dcd43ae80 11:14:33 AM: debug Hallway Cree switch is on
    3936ac6a-bac5-409c-ba35-096dcd43ae80 11:14:33 AM: trace catchall: 0104 0006 0A 01 0140 00 5F04 00 00 0000 01 01 0000001001
    3936ac6a-bac5-409c-ba35-096dcd43ae80 11:14:30 AM: trace catchall: 0104 0008 0A 01 0140 00 5F04 00 00 0000 0B 01 0400
    3936ac6a-bac5-409c-ba35-096dcd43ae80 11:14:29 AM: debug [st cmd 0x5F04 10 8 4 {fc 0000}]

133

Thanks! It looks like we’re getting an “unsupported attribute” response back from the bulb, and it’s positioning suggests it has to do with the write attempt we make to the OnOffTransitionTime attribute. This let’s the bulb transition when on/off commands are given instead of instantly turning on/off. After changing to this device type, did you go into preferences and set the new two new fields for Dim Rate and Dim On/Off? When you turn the bulb ‘on’ or ‘off’ (not adjusting level slider), does it dim up/down slowly?

@dckirker, in building the ST device type for the Cree, do you know if it supports the OnOffTransitionTime attribute?

134

@Sticks18
Of course I messed with those settings :wink:

I have observed slow transitions for on/off.

They are currently set to:
DimRate: Instant
Dim transitions: No

Changing to:
DimRate: Normal
Dim transition: Yes

Yields:

3936ac6a-bac5-409c-ba35-096dcd43ae80 1:10:25 PM: debug Level message
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:10:25 PM: trace catchall: 0104 0008 0A 01 0140 00 5F04 00 00 0000 04 01 861000
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:10:25 PM: trace read attr - raw: 5F040A00080A00000020FC, dni: 5F04, endpoint: 0A, cluster: 0008, size: 0A, attrId: 0000, result: success, encoding: 20, value: fc
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:10:24 PM: debug Hallway Cree switch is on
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:10:24 PM: trace catchall: 0104 0006 0A 01 0140 00 5F04 00 00 0000 01 01 0000001001
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:10:21 PM: trace catchall: 0104 0008 0A 01 0140 00 5F04 00 00 0000 0B 01 0400
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:10:21 PM: debug [st cmd 0x5F04 10 8 4 {fc 1500}]

Changing to:
DimRate: Normal
DimTrans: No

3936ac6a-bac5-409c-ba35-096dcd43ae80 1:12:21 PM: debug Level message
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:12:21 PM: trace catchall: 0104 0008 0A 01 0140 00 5F04 00 00 0000 04 01 861000
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:12:20 PM: trace read attr - raw: 5F040A00080A00000020FC, dni: 5F04, endpoint: 0A, cluster: 0008, size: 0A, attrId: 0000, result: success, encoding: 20, value: fc
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:12:20 PM: debug Hallway Cree switch is on
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:12:20 PM: trace catchall: 0104 0006 0A 01 0140 00 5F04 00 00 0000 01 01 0000001001
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:12:16 PM: trace catchall: 0104 0008 0A 01 0140 00 5F04 00 00 0000 0B 01 0400
3936ac6a-bac5-409c-ba35-096dcd43ae80 1:12:16 PM: debug [st cmd 0x5F04 10 8 4 {fc 1500}]
135

So even when “Dim transitions” is set to “No”, you still see slow transitions for on/off?

136

Yeah, I’m seeing the same issue with the dimmer level jumping up and back down when I refresh. My settings are Dim Rate: Normal, Dim Transistion on/off: Yes

137

@Sticks18
Sorry, I was unclear.
I can’t check now but I believe I don’t see slow transition when DimTransitions: off.

138

Try commenting out the last command in the refresh() and poll() sections (I’ve included an example below). If it’s the attribute I think it is, then that will fix the issue.

[
    "st rattr 0x${device.deviceNetworkId} 10 6 0", "delay 500",
    "st rattr 0x${device.deviceNetworkId} 10 8 0" /* , "delay 500",
    "st wattr 0x${device.deviceNetworkId} 10 8 0x10 0x21 {${state.dOnOff}}" */
]
139

@Sticks18
Thank you, that fixed it :grinning: :grinning:

Just a question why is refresh issuing the same commands as poll() and then calling poll()?

    def poll() {
        [
        "st rattr 0x${device.deviceNetworkId} 10 6 0", "delay 500",
        "st rattr 0x${device.deviceNetworkId} 10 8 0" /*, "delay 500",
        "st wattr 0x${device.deviceNetworkId} 10 8 0x10 0x21 {${state.dOnOff}}" */
        ]   
    }

def refresh() {
    [
    "st rattr 0x${device.deviceNetworkId} 10 6 0", "delay 500",
    "st rattr 0x${device.deviceNetworkId} 10 8 0" /*, "delay 500",
    "st wattr 0x${device.deviceNetworkId} 10 8 0x10 0x21 {${state.dOnOff}}" */
    ]
    poll()   
}
140

I’ll adjust the GitHub code tonight to reflect that the Cree bulb doesn’t support writing to that attribute.

I’m not sure. This code was a group effort for the GE Link, so at some point it might have been added to get better response by issuing the same refresh() commands twice. If it ain’t broke, I try not to touch it.

141

Thank you to the contributors to the code.

I got it working on the second try.

It appears on the first try, after the bulb reset, the ST hub automatically saw the bulb and added it automatically but had no control.

The bulb was previously added as unknown in my case and I deleted it from the Android app. Maybe there was a bit of a delay in deleting it and saw it before adding it the first time.

142

Added my first device type successfully. I can turn on/off and dim without any issues. I would like to schedule the bulb to go on and off at a certain time. I don’t see any options or smartapps to do that. Is this something currently being worked on or am i missing something? I am new to ST and loving it! Thanks!