How to debug new Device Type code?

Hi,
I’m new to ST and I’m trying to write a Device Type for my Z-Wave MultiSensor: EZMultiPli Motion, Light and Temperature sensor that needs no batteries.

I have read thru the ST documentation, gone to ide.smarttings.com & can see my device, created the Device Type, Published it for Me, excluded the device and then re-added it to the ST hub.
But it appears that ST doesn’t match the fingerprint because it has not selected my new Device Type but comes up with some sort of generic Device.
There’s nothing in the log that helps:
a49d1047-baaf-499b-a3b6-5d3ffa0156c0 12:15:41 PM: error groovy.lang.MissingPropertyException: No such property: event for class: script14220181958642005058368
Possible solutions: parent @ line 68 a49d1047-baaf-499b-a3b6-5d3ffa0156c0 12:15:41 PM: error groovy.lang.MissingPropertyException: No such property: event for class: script14220325979102005058368
Possible solutions: parent @ line 68
11:47:43 AM: info Waiting on events…
11:47:43 AM: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.
11:47:43 AM: info This console provides live logging of your SmartThings

The Raw Description is: 0 0 0x0701 0 0 0 f 0x5E 0x71 0x31 0x33 0x72 0x86 0x59 0x85 0x70 0x77 0x5A 0x7A 0x73 0xEF 0x20
and my fingerprint code is:
fingerprint outClusters: “0x20”, inClusters: “0x5E, 0x71, 0x31, 0x33, 0x72, 0x86, 0x59, 0x85, 0x70, 0x77, 0x5A, 0x7A, 0x73, 0xEF”, deviceId: “0x0701”

Is there a bit more of a step-by-step guide on getting a new Device Type debugged?

I made a small change to the fingerprint after reading the fingerprint doc again but it still doesn’t pick up the device correctly.

metadata {
definition (name: “EZmultiPli”, namespace: “DrZWave”, author: “Eric Ryherd”, oauth: true) {
capability "Motion Sensor"
capability "Temperature Measurement"
capability "Illuminance Measurement"
capability "Color Control"
capability “Configuration”

    fingerprint inClusters: "0x5E, 0x71, 0x31, 0x33, 0x72, 0x86, 0x59, 0x85, 0x70, 0x77, 0x5A, 0x7A, 0x73, 0xEF, 0x20", deviceId: "0x0701"
}

I got rid of the OutCluster and put all 15 command classes in (previous version has 0x20 in the outcluster).

The Z-Wave example http://docs.smartthings.com/en/latest/device-type-developers-guide/building-z-wave-device-types/z-wave-device-reference.html shows:

metadata {
definition (name: “Z-Wave Device Reference”, author: “SmartThings”) {
capability "Actuator"
capability "Switch"
capability "Polling"
capability "Refresh"
capability "Temperature Measurement"
capability "Sensor"
capability “Battery”
}
Does not have the “FingerPrint” syntax in it. Where does the fingerprint go?
The ZigBee example looks like it should go here but it’s not clear.

The fingerprint should be in the definition section of metadata


metadata {
	definition (name: "EZmultiPli", namespace: "DrZWave", author: "Eric Ryherd", oauth: true) {
		capability "Motion Sensor"
		capability "Temperature Measurement"
		capability "Illuminance Measurement"
		capability "Color Control"
		capability "Configuration"

		fingerprint deviceId: "0x0701", inClusters: "0x5E 0x71 0x31 0x33 0x72 0x86 0x59 0x85 0x70 0x77 0x5A 0x7A 0x73 0xEF 0x20"
	}
}

Also be careful of the casing. FingerPrint is not the same as fingerprint
You may also want to try removing the commas in the inClusters

Thanks James,
See my 2nd post which has all the code in it and the fingerprint is inside the definition.
Note that I added a comma between each byte of the inClusters as the documentation says it should be.
Does the deviceID have to come first? before the inClusters?

Not sure. Welcome to old style debugging.

Log statements and trial and error.

1 Like

Changing the order of deviceID didn’t make any difference as I expected.
At this point I am dead in the water unable to make any progress because ST gives me no data to go on as far as what might be the problem.

Where can I go for help? The support group said they can’t help with coding.

http://docs.smartthings.com/en/latest/device-type-developers-guide/anatomy-of-a-device-type.html

Check this documentation if this helps.

Thanks Ron,
I’ve already read the documentation and I am able to write the code.
The problem is how to debug it.
There is nothing in the log when I join the device that says what Device Type it is trying to use and it appears that it is not using my newly coded and published Device Type.
I need SOME sort of Log entry or someone who knows the Device Type Fingerprint well enough to point out what the problem might be and why ST is not using my Device Type.

Did you publish your device to yourself? Stupid thing to ask. And when tried pairing the device did it recognize it as your device? No clue how to debug device types. :frowning:

Yes - I published. How long does it take to propagate? I would assume a minute or two but it its longer then maybe I didn’t wait long enough. But how would I know?

Well - I stumbled on the simulator.
in IDE.Smartthings.com clcik on My Device Types and select your new device.
The first thing that really helps is to look at all the other templates out there - upper right hand corner is Device Type Templates.
Pick one that is close to your device to start with.
Much each to make minor changes than try to write it all from scratch!
Next, you want to use the right icons - to see what’s available, check out - http://scripts.3dgo.net/smartthings/icons/
Once your code is ready, then you want to debug it so
click on PUBLISH first.
Then join the new device to the network.
Then in the My Device Types click on LOCATION and then SET LOCATION and then pick the device you just added.
Now you get a debug log at the bottom and you can see at least a little bit of whats going on.

Hope this helps all the other developers!

I know this thread is 5 months old, but I was dealing with something similar this weekend, and had run across this thread. I got my case working as far as fingerprint detection goes, but based on what I learned, I didn’t see a correct fingerprint for this device in the thread.

I assert that the fingerprint for this device would be:

fingerprint deviceId: "0x0701",  inClusters: "0x5E, 0x71, 0x31, 0x33, 0x72, 0x86, 0x59, 0x85, 0x70, 0x77, 0x5A, 0x7A, 0x73", outClusters: "0x20"

Here is my reasoning:

This is almost identical to the original fingerprint that @DrZWave tried according to this thread. I rearranged the order of the arguments, but that is strictly personal preference and has no bearing on it working. The change of substance is that I removed 0xEF from the inClusters.

0xEF is not a command class. Instead, it is the MARK. In the raw description (in Z-Wave parlance, that’s the Node Information Frame, or NIF), the MARK separates the list of command class IDs you will put in inClusters from the list of command class IDs you will put in outClusters. If there are no outClusters, there will be no MARK. In any case, if the NIF contains a MARK, do not include the literal MARK in either cluster list.

I’ll write up a FAQ with a little more explanation as the docs currently indicate that a single digit will separate cluster lists in the raw description. Perhaps SmartThings used to translate the MARK into this , but it appears like that might not be happening any more, or it’s a difference between what’s in the device info page in the IDE vs what gets written to the log during the pairing ceremony.

Hi surfous,

In general using the command classes for the fingerprint of Z-Wave devices is NOT the correct way of fingerprinting Z-Wave devices. ST should be using the Manufacturer Command Class which defines the Manufacturer, the ProductID and ProductTypeID which are REQUIRED of any certified Z-Wave device. There are a relatively small number of old devices that are out there pre-certification but that number is dwindling fast. ST should use the MFG CC First and if a device doesn’t have MFG CC, then use the CC list for a fingerprint.

I do have my device working and am waiting for it to be publicly published by ST - https://github.com/drzwave/ExpressControls/blob/master/EZMultiPliDeviceType.gy

Oh, I’m not gonna disagree with you there - the current approach is certainly wrought with obvious problems - similar devices, especially simpler ones, are likely to have the same fingerprint. It was a fingerprinting mismatch that led me to learn about the (not really a) COMMAND_CLASS_MARK. Later, I see that @duncan mentioned 0xEF in the forums, but the docs mention only the single-digit separator. I’m still unsure if either method of separating supported and controlled CCs could be valid for Z-Wave devices with both supported and controlled CCs, or if it’s changed, or if the docs are wrong and the text is a holdover from adapting Zigbee fingerprinting to Z-Wave.

I understand why they did it - the NIF is guaranteed at pairing, and they try to match up device and hander from what they know they’ll have available. But they’re aware of the limitations of this approach as well.

As duncan has said in another thread,

ST appears to be in tune with this, though I’m not sure when we might see this, or if it’s already present and just undocumented as of yet.

Congrats on your device type release and pending publishing!