hmm, that looks like a dimmer function setlevel response, 0104 is the HA cluster, 0008 is the dimmer level and a bunch of code I can’t remember, but the last part is the payload portion that appears to contain more then set level.
861000 is interesting, this might be a combined dimmer level and energy usage.
Can you log a few more events that start with catchall: 0104 0008… that might have different values at the end?
Please also let me know the state of the dimmer and what’s hooked up to the dimmer? CFL, LED? incandescent? How many?
What were you doing that specifically got the previous catachall to log? Was this setting a dimmer level?
Ultimately, we need to see a few actions logged and let me know where in the logs these are done.
Pairing / joining logs
At dimmer:
On
Off
Dim to 50%, 25%, 75%
At app:
On
Off
Dim to 50%, 25%, 75%
Any polling or every X minutes without doing anything logs as well.
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.
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. 
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.
Sounds promising 
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.