What does IDE: Raw Description mean?

I am trying to understand how to create a device type.

I am currently using using a home built Device type.

Regarding the device type current installed and running:

My Hot water Heater is connected as “ZigBee Load Control Switch” (the home built device type.)

The thing (Leviton 73A00-3ZB LCM) is connected as “Hot Water Heater.”)

From the home built device type:

fingerprint profileId: “0104”, inClusters: “0000,0003,0006”, outClusters: “000A”

The “Hot Water Heater” Raw Description (from IDE) is 09 0104 0002 70 03 0000 0003 0006 01 000A

What does the Raw Description tell me?

Hey @NickHark

This is the raw fingerprint for the device. It tells you which command classes it can communicate on and what it’s devices ID is. Unless you are developing device types it won’t really mean much. :smile:

Also see here for a more detailed description: http://docs.smartthings.com/en/latest/device-type-developers-guide/definition-metadata.html#fingerprinting

Followup to @slagle

I have spent hours with the voodoo of Zigbee clusters and I feel like the kid watching a baseball game through a knothole…

  1. Is there a community forum somewhere with in depth analyses of ZigBee clusters so that we could learn how to create a device type? I.E. if there is no template of a device type that has been created before, there appears to be no help from ST.

  2. Is there a company that will sniff the ZigBee compatible devices to provide the raw data so we can design the finger print to use with our ST hubs? I note that there are USB+software solutions that sniff ZigBee devices, but they appear to be beyond the reach of hobbyists.

  3. Is there a company that will create a device type of a ZigBee compatible device to use with our ST hubs.

It has become obvious that ST does not want to do this, especially after its acquisition by Samsung. I cannot believe that Samsung will activly pursue the openness of ST. ST appears only to provide the hardware to enable geeks everywhere to connect devices that ST has determined to justify their effort to design a device type. This leaves those who have ZigBee compatible devices that are on the fringe, out in the cold. This is not a slam on ST, it is (IMO) a realistic look at their business model.

So, I am still trying to create a device type, that doesn’t have a template on IDE.

You don’t need a sniffer to create a device fingerprint. As @tslagle13 mentioned above this information is offered in the Raw Description after pairing.

Once you have the fingerprint the next step is to determine the ZigBee support for that particular device. If you haven’t already reviewed our primer, start here.

Short of writing the device type for you what types of resources are you looking for? I’d be happy to do some research or ask around internally.

1 Like

Here are a couple additional resources that helped me tinker with Zigbee device types.

http://www.everyhue.com/wp-content/uploads/2012/12/ZigBee_Cluster_Library.pdf

The raw description for your device looks to be simply a switch. The inClusters are the Basic, Identify and On/Off clusters. The lone outCluster is the Time cluster.

All of the ST device types are out on GitHub now, so you might want to look at the GE Zigbee Switch device type as a template, and then start removing features that this device doesn’t have like the Power Meter. The on()/off() methods should work as is, which is pretty much all your Leviton device can use.

You don’t need a zigbee sniffer for devices that will pair to ST. Use Live Logging and add a log statements to the parse section to see the incoming data. Then you can test what messages look like using read attribute/write attribute calls to various clusters based on the developer documentation from ST for syntax of commands and the pdf I linked to for what’s available in each cluster.

The 0006 cluster is the on/off cluster. You can use the smartpower outlet DTH (device type handler) in github as a reference. Couple of other useful things, if you are building zigbee DTH:

put this in your refresh method to get the manufacturer and model info:

def refresh() {
    zigbee.refreshData("0", "4") + zigbee.refreshData("0", "5")
}

That is cluster 0 (Basic cluster), attribute 4 (ManufacturerName) and attribute 5(ModelIdentifier). The reply for those commands will be in the parse method. In there you could use the command

log.debug zigbee.parseDescriptionAsMap(description)

The above command will print out the map version of the reply to your basic cluster query. The value returned is the in hex and you could use this link: (rapidtables.com/convert/number/hex-to-ascii.htm) to get the ascii value.

Bonus: Want you to support multiple device in the same DTH with different model names. Just add one more field in the fingerprint called deviceJoinName. Look for the examples in the git project.

1 Like

Thanks @Tyler @Sticks18

@workmonk gave me some clarification. I hope you don’t think I was playing “hide-the-ball.” Just trying to clarify what I need.

The reason I am asking about this Leviton switch and its device type is because when I attempted to connect another device which is also not on the ST template list, over a period of 4 days, 1480 “ZigBee Load Control Switch” devices connected to my hub and essential brought its functionality to a halt. I was able to delete these and my hub is now clean.

I did try to make a device handler for this other device, and it functions, but this makes no difference.

Whenever I turn on the other device it will begins to connect to this hub with the “ZigBee Load Control Switch” device handler.

I assumed it was this device handler that was causing the problem.

Can the device handler be modified to permit it to connect only to this one Leviton switch? This should be the subject of a thread, perhaps.

I note:

but this doesn’t help me.

As a further question that may be helpful: What is it about the footprint I am using that allows the other devices to connect without human intervention?

To reiterate:
The ZLCS uses: fingerprint profileId: “0104”, inClusters: “0000,0003,0006”, outClusters: "000A"
Raw Description (from IDE) is 09 0104 0002 70 03 0000 0003 0006 01 000A

If I’m understanding your issue correctly, I think your fingerprint is not specific enough, so many devices could fit it and choose it as a default. Any Zigbee HA switch will include those same 4 clusters and profile id.

I’d look at what @workmonk response about determining manufacturer and model info if you want the device handler to only apply to a single device.

There was a similar issue with the zwave fan control because it’s really just a dimmer switch, so the wrong devicetype was being defaulted. The creator of the fan devicetype purposely modified the fingerprint so no devices would auto-apply it and the user had to manually update the device in the IDE.

I have no idea how you got almost 1,500 devices of the same type connected somehow. That sounds like an issue to talk to support about.

@Sticks18 I submitted a support ticket and communicated with “the engineers” but apparently it blew their minds and it was over a week before I got a response, and that was that they missed the entire point and after I had deleted the 1480 devices and got the hub back, they merely reset my hub requiring me to reset, through them, the welcome code; overall unhappy with support… (I had built a kludgy script using AutoIT to methodically delete each device, which consumed almost 20 hours of processing and babysitting as there is no way (apparently) to perform a root canal on a runaway hub.)

Otherwise, I am sure you have pointed me in the right direction.

Going underground to get further intelligence.

Thanks

George Richards (FalcoGeorge) is the device handler designer whose device handler I use for my troublesome Leviton 73A00-3ZB Wireless 30A Load Control Module.

While poking around on his website I came across his page titled: “Using an Xbee to communicate with a Leviton 73A00-3ZB Wireless 30A Load Control Module.” This is how he designed his LCM device handler, which I use.

This page provides a lot of information only an electrical engineer would love, but it may provide (hopefully) some clues/answers to resolving my issue.

He also has a page called “Connecting an Xbee 24ZB to Smartthings Hub.”

Since he lives in New Zealand he had to get real deep into ZigBee to figure this stuff out. He is an airline and general aviation pilot (and an electrical engineer, I believe) and his blog about flying his home-built Falco to the Oshkosh fly-in is a delight.

Part 1: http://www.falco.co.nz/smr-oshkosh-blog/ Note: Starts at bottom

Part 2: https://kiwifalcoadventure.wordpress.com/page/8/ Note: Starts at bottom works up to page 1

1 Like

Can you provide or share the device type code you are using?

I would like to disable my well pump when I leave the home to not come back to a flood or at least turn off when i get alert there is a flood happening.

1 Like

Sure.

I caution you about what I had said earlier, above. The bottom line is that when I connected another ZigBee device (an Orbit drip timer that is also ZigBee controlled, and purchased from Lowes) 1480 extraneous devices were automatically added which required me to manually delete them to get my hub back. Not only that, when I took my drip valve to Las Vegas NV and connected it to a hub which is in my account but 10 hours away, these unwanted devices connected even though the device type was not installed on that hub at all. All of these unwanted devices connected as a ZigBee Load Control Switch, as defined in the included device type.

Also note that I still use this device type and do not have any problems with it as designed, but I have not attempted to screw around with the Orbit valve since.

I do have several other ZigBee devices on both hubs with no problems encountered.

Here’s the device type code:

[CODE]
metadata {

// Automatically generated. Make future change here.

definition (name: “Zigbee Load Control Switch”, namespace: “GR_Load_Control”, author: “George Richards”, oauth: true) {
capability “Switch”

command "on"
command "off"


fingerprint  profileId: "0104", inClusters: "0000,0003,0006", outClusters: "000A"

}

simulator {
// simulator metedata
status “on”:"on/off: 1"
status “off”:“on/off: 0”

reply "zcl on-off on":"on/off: 1"
reply "zcl on-off off":"on/off: 0"

}

tiles {
standardTile(“switch”, “device.switch”, width: 2, height: 2, canChangeIcon: true) {
state “off”, label: ‘Off’, action: “switch.on”, icon: “st.Outdoor.outdoor16”, backgroundColor: "#ffffff"
state “on”, label: ‘On’, action: “switch.off”, icon: “st.Outdoor.outdoor16”, backgroundColor: “#53a7c0
}
main "switch"
details([“switch”])
}

}

// parse events into attributes
def parse(String description) {
log.info description
if (description?.startsWith(“catchall:”)) {
def value = name == “switch” ? (description?.endsWith(" 1") ? “on” : “off”) : null
def result = createEvent(name: name, value: value)
def msg = zigbee.parse(description)
log.debug "Parse returned ${result?.descriptionText}"
return result
log.trace msg
log.trace “data: $msg.data”

}
else {
def name = description?.startsWith(“on/off: “) ? “switch” : null
def value = name == “switch” ? (description?.endsWith(” 1”) ? “on” : “off”) : null
def result = createEvent(name: name, value: value)
log.debug "Parse returned ${result?.descriptionText}"
return result
}
}

// handle commands
def on() {
log.debug "Executing ‘on()’"
sendEvent(name: “switch”, value: “on”)
“st cmd 0x${device.deviceNetworkId} ${endpointId} 6 1 {}”
‘zcl on-off on’
}

def off() {
log.debug "Executing ‘off’"
sendEvent(name: “switch”, value: “off”)
“st cmd 0x${device.deviceNetworkId} ${endpointId} 6 0 {}”
‘zcl on-off off’
}
[/CODE]

Best of Luck.

1 Like