Device type needed - 45857GE Zigbee dimmer

In the first shot was joining. Second shot was on and off at app.

I’ll do the others now.

In app: off > on > 100 > 75 > 50 > 25 > 100 > off

c9e9df93-410f-4a35-8b34-836053b18844 9:10:45 PM CDT: trace data: [0, 0]
c9e9df93-410f-4a35-8b34-836053b18844 9:10:45 PM CDT: trace SmartShield(clusterId: 0x0006, command: 0x0b, data: [0x00, 0x00], destinationEndpoint: 0x01, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0xc0b8, sourceEndpoint: 0x01, text: null)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:45 PM CDT: info catchall: 0104 0006 01 01 0140 00 C0B8 00 00 0000 0B 01 0000
c9e9df93-410f-4a35-8b34-836053b18844 9:10:45 PM CDT: debug off()
c9e9df93-410f-4a35-8b34-836053b18844 9:10:44 PM CDT: trace data: [4, 0]
c9e9df93-410f-4a35-8b34-836053b18844 9:10:44 PM CDT: trace SmartShield(clusterId: 0x0008, command: 0x0b, data: [0x04, 0x00], destinationEndpoint: 0x01, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0xc0b8, sourceEndpoint: 0x01, text: null)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:44 PM CDT: info catchall: 0104 0008 01 01 0140 00 C0B8 00 00 0000 0B 01 0400
c9e9df93-410f-4a35-8b34-836053b18844 9:10:43 PM CDT: trace setLevel(99)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:37 PM CDT: trace data: [4, 0]
c9e9df93-410f-4a35-8b34-836053b18844 9:10:37 PM CDT: trace SmartShield(clusterId: 0x0008, command: 0x0b, data: [0x04, 0x00], destinationEndpoint: 0x01, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0xc0b8, sourceEndpoint: 0x01, text: null)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:37 PM CDT: info catchall: 0104 0008 01 01 0140 00 C0B8 00 00 0000 0B 01 0400
c9e9df93-410f-4a35-8b34-836053b18844 9:10:37 PM CDT: trace setLevel(25)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:31 PM CDT: trace data: [4, 0]
c9e9df93-410f-4a35-8b34-836053b18844 9:10:31 PM CDT: trace SmartShield(clusterId: 0x0008, command: 0x0b, data: [0x04, 0x00], destinationEndpoint: 0x01, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0xc0b8, sourceEndpoint: 0x01, text: null)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:31 PM CDT: info catchall: 0104 0008 01 01 0140 00 C0B8 00 00 0000 0B 01 0400
c9e9df93-410f-4a35-8b34-836053b18844 9:10:30 PM CDT: trace setLevel(50)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:26 PM CDT: trace data: [4, 0]
c9e9df93-410f-4a35-8b34-836053b18844 9:10:26 PM CDT: trace SmartShield(clusterId: 0x0008, command: 0x0b, data: [0x04, 0x00], destinationEndpoint: 0x01, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0xc0b8, sourceEndpoint: 0x01, text: null)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:26 PM CDT: info catchall: 0104 0008 01 01 0140 00 C0B8 00 00 0000 0B 01 0400
c9e9df93-410f-4a35-8b34-836053b18844 9:10:26 PM CDT: trace setLevel(75)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:16 PM CDT: trace data: [1, 0]
c9e9df93-410f-4a35-8b34-836053b18844 9:10:16 PM CDT: trace SmartShield(clusterId: 0x0006, command: 0x0b, data: [0x01, 0x00], destinationEndpoint: 0x01, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0xc0b8, sourceEndpoint: 0x01, text: null)
c9e9df93-410f-4a35-8b34-836053b18844 9:10:16 PM CDT: info catchall: 0104 0006 01 01 0140 00 C0B8 00 00 0000 0B 01 0100
c9e9df93-410f-4a35-8b34-836053b18844 9:10:16 PM CDT: debug on()
 9:10:13 PM: info Waiting on events...
 9:10:13 PM: info For past logs for individual things go to the My Devices section, find the device and click on the Events link on the device information page.
 9:10:13 PM: info This console provides live logging of your SmartThings.

From Switch: Nothing logged with physical activity at the switch

Hmm, that’s a bummer nothing responds when the switch is pressed or dimmed. Might have to zdo bind to something to make that happen.

Also, based on the set level above, it appears the default dimmer endpoint is not responding with dimmer level.

Still missing the join command and the getclusters command, but it is possible it reports nothing.

Thanks for the logs, I’m not sure what I can do from here. I might just have to order one of these and see if it can be made better.

How is the basic functionality so far? It works but doesn’t report status back of switch state?

Does it have any regular polling log / catchall if you let it sit idle for 5-10 minutes?

It basically works. From app: on, off, dims.

It does not report the switch state back to ST. ST only thinks it’s on when ST turns it on.

That model doesn’t support instant update, so in order to update the hub status you have to bind it to the hub or poll it occasionally.

Yeah, it will need a zdo bind to get status to report back to ST from button actions. the reality is I have no idea what that command could look like.

Check to see if the device type you are using has a refresh section with the following code:

def refresh() {
    [
    "st rattr 0x${device.deviceNetworkId} 1 6 0", "delay 200",
    "st rattr 0x${device.deviceNetworkId} 1 8 0"
    ]
}

and what happens if the refresh button is pressed in the ide in the logs?

also, what is in the configure section?

try this:

def configure() {

    String zigbeeId = swapEndianHex(device.hub.zigbeeId)
    log.debug "Configuring Reporting and Bindings."
    def configCmds = [    
  
        //Switch Reporting
        "zcl global send-me-a-report 6 0 0x10 0 3600 {01}", "delay 500",
        "send 0x${device.deviceNetworkId} ${endpointId} 1", "delay 1000",
        
        //Level Control Reporting
        "zcl global send-me-a-report 8 0 0x20 5 3600 {0010}", "delay 200",
        "send 0x${device.deviceNetworkId} ${endpointId} 1", "delay 1500",
        
        "zdo bind 0x${device.deviceNetworkId} 1 1 6 {${device.zigbeeId}} {}", "delay 1000",
        "zdo bind 0x${device.deviceNetworkId} 1 1 8 {${devicezigbeeId}} {}", "delay 500",
    ]
    return configCmds + refresh() // send refresh cmds as part of config
}

and run the configuration action in the ide as well and see what returns and if anything changes with the device when the dimmer is pressed, etc.

The stock zigbee dimmer device doesn’t have much in the configure section and no level parsing, so it can definitely be improved.

@cmfraz can you look at the device in the IDE? (Click My Devices, then click on the switch) And there is a section called Raw Description that is hopefully populated. Copy that here. That lists the clusters that the device uses. With that we can start building a better devicetype including the configure section that @pstuart has above.

1 Like

Raw Description 01 0104 0101 00 08 0000 0003 0004 0005 0006 0008 0B05 0702 02 000A 0019

Interesting combination of clusters. I would have expected 0001 for the energy monitoring. I don’t know what 0B05 and 0702 are. I see 0B05 in a lot of zigbee devices though. @pstuart any idea what either of those are used for?

I can’t read what was posted (I use a text to speech reader), but 0B05 is usually the diagnostics cluster.

0702 is Simple Metering.

Thanks JD! Is there a resource you have or used to find out what those clusters are used for? I’ve typically used a zigbee cluster library reference that is HA specific and it doesn’t list either one. If 0702 is simple metering then it probably handles the energy monitoring, but I don’t know what attributes to read or how to interpret them.

0B05 is one every field tech knows, it’s how you check relative signal strength. :wink:

A Zigbee Pro reference should have everything except ZLL. Try NXP’s chip documentation, that’s usually good.

edited to add Here, try this one:

This is good news.

Surprising it doesn’t have the 0001 endpoint, but it appears that 0702 is going to be our endpoint.

Reading this Raw Desc…
01 0104 0101 00 basically tells us it follows the HA profile
08 # of inbound endpoints
0000
0003
0004
0005
0006 = switch on/off
0008 = dimmer level
0B05 = diagnostic
0702 = simple energy report

02 = number of outbound endpoints
000A
0019

So, with two outbound endpoints to bind to, we might be able to get polling working and a few other features reading the other inbound endpoints and see if we can find the right clusters and attributes.

Too bad a spec doesn’t exist already for this. I wonder if anyone knows someone at Jasco / GE to provide the docs for a driver / devicetype.

Otherwise, it’s pretty much trial and error until something works without the docs. But that is what makes ST great. We can build it, hack it, break it, etc. until it works.

1 Like

Sounds promising :smile:

nice work! will this device type likely work with any zigbee switch then (or should work?)

I’d love to replace my physical switches with zigbee ones to control my lifx (as a last resort outside of motion automation).

FYI, GE ZigBee Switch Device Type is published by SmartThings, but still I cannot get instant updates from manual switching on/off.

This should be fixed before we officially publish support for these devices. Should be within a few weeks.

Shall I continue to use this code? How do I know the code is finalized and updated?

The only thing it does NOT work is the status update from using physical switch. Even monitoring report works beautifully.

“instant status update” for light switches, regardless of whether they are zigbee or zwave, is covered by the Lutron patent. Companies which do not license this patent, which GE has not done for this switch, are not legally allowed to provide instant status updates to the hub.

Lutron sued Control4 for patent infringement on their zigbee dimmer switches and won. Control4 now pays the patent fee.

http://www.cepro.com/article/lutron_crestron_settle_on_patent-infringement_claims/

So I don’t think you’ll ever get instant status update from this particular model. It’s not a matter of device handler, the device itself doesn’t send it.

Completely true. Some devices work around this issue though. I can attest that when I manually turn the Jasco Pluggable ZigBee Dimmer off the app reports that it is off within 1 second.

We have a few updates planned for this device type before we announce compatibility. You’ll know the code is ready when we announce official support for the GE/Jasco ZigBee devices. We usually put up a blog post and a forum post. I estimate it will be about 3 weeks.

1 Like