Need help perfecting device handler for GoControl zwave smart light switch cover

[JDRoberts]

Continuing the discussion from [Linear WA00Z1 Smart Light Switch Cover (US)]

Linear WA00Z1 Smart Light Switch Cover (US)

Here is a “Milestone 1” release of it. It is far from perfect (Device Fingerprint needs testing, code is messy), but it works! Button 1 maps to the top button and button 2 maps to the bottom. It should work with any Button Controller SmartApp, tested with Smart Lighting. I could use some help perfecting this device type. Almost could consider terribly written.

Added a thread for you in the developers section. Folks here can probably give you the most help.

For those unfamiliar with it, this new device is basically a battery-operated two button wallmount Minimote. The idea is it fits over an existing light switch so you no longer have the problem of people turning off power to smart bulbs.

@ajpri has made a great start at a device handler, but would like some more help with it.

[ajpri (Austin Pritchett)]

Thanks for creating the topic!

Here’s the code I’ve been working on:

ajpri/STApps/blob/master/devicetypes/ajpri/gocontrol-wireless-remote-switch.src/gocontrol-wireless-remote-switch.groovy

So far it works as a button controller with both buttons being separate (button 1 mapped as top, button 2 mapped as bottom).

Here’s how I can use help…

I have found the raw description to be:

0 0 0x1801 0 0 0 f 0x5E 0x86 0x72 0x5B 0x85 0x59 0x73 0x70 0x80 0x84 0x5A 0x7A 0xEF 0x5B 0x20

I have a fingerprint:

fingerprint deviceId:“0x1801”, inClusters:“0x20, 0x5B, 0x70, 0x73, 0x80, 0x84”

However, I am not sure if this will pair devices to the device type. When a button is pressed on the switch, it sends a wakeup, central scene notification, and battery life info.

Also, I got inverting buttons working, preference defined in line 61, and sent to device in line 107. The command being sent every time the device is woken up. Is this good or is there a better way? Feels like it could drain the battery.

Final point is on making the device type better - optimizing the code to be efficient, and the best it can be.

[JDRoberts]

Tagging @AdamV and @tgauchat in case they have any suggestions.

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

Gotta remember to come back to this one and try to help (or see if other’s have helped…).

ZigBee (EDIT: oops… Z-Wave! ref: @JDRoberts below…) pairing (and configuring) is still too complex, though SmartThings has added a bunch of new, mostly undocumented commands (so far), but very satisfying when you get it working. Like magic it seems.

Need some time to read this through and cross reference my meager knowledge so far and/or look up the experts to tag. Ah … @JohnR has been extremely helpful to me and others… but not sure if he is only ZigBee expert or also Z-Wave.

[Motley (Michael)]

@ajpri

However, I am not sure if this will pair devices to the device type.

Why are you not sure if devices will pair to the device type? I was able to test my OSRAM switch that I am working on by removing it from ST, performing a reset, and re-connecting it to see if it would pair to the correct device type. I am looking to get at least one so when I do I can test but someone else will likely get to that before me.

[JDRoberts]

This is a zwave device.

[ajpri (Austin Pritchett)]

As far as fingerprinting is going, my fingerprint is not auto-identifying. Messed around with it a few times, still showing up as “Z-wave Device”. Stressing me out a bit. Once I master fingerprinting, I’ll write a tool that takes the raw description and makes a fingerprint.

[JDRoberts]

Technically only zigbee devices have fingerprints. But SmartThings uses the same term for zwave devices as well. (Zwave devices don’t have “clusters” either, but again SmartThings takes a Zigbee term and uses it for all protocols.)

Just wanted to mention it because it can lead to some confusion if you review outside resources.

This is the ST documentation on “fingerprinting” a Zwave device.

http://docs.smartthings.com/en/latest/device-type-developers-guide/definition-metadata.html#z-wave-fingerprinting

[Motley (Michael)]

I will say that I found when I added manufacturer and model on mine it would not pair with the device type, leaving the manufacturer and model commented out worked for my OSRAM Dimmer Switch device type. I suspect you have to have these strings exactly as the device would report and I haven’t figured out how to get the manufacturer and model string from the device, I have not seen any messages at join that would indicate it either, wondering if not specifying it for mine works because the device doesn’t actually report it.

[AdamV]

Personally I’ve never understood the fingerprinting. I’ve made some devices where it picks it up and matches it straight away, and others where it does not. No clue what seems to push it one way or the other!

[JohnR (John Rucker)]

@tgauchat

but not sure if he is only ZigBee expert or also Z-Wave.

Sorry no Z-Wave advice here. I have kept my focus on ZigBee with an eye on Thread.

[ajpri (Austin Pritchett)]

So I guess for now, that won’t work. Might mess around with it some more.

Well what about me sending the parameter 4 bit every time the device wakes up? Is that a good practice or is there a better way to handle it?

[Motley (Michael)]

@ajpri, I was looking at your fingerprint and wondering why you are not using all the published clusters? I know that @JDRoberts said that z-wave doesn’t use “clusters” but that is what ST calls them so that is what I will call them. When I look at the raw description the ‘f’ indicates that there should be 15 clusters and you are only using 6 of them. If I were to take the raw description the fingerprint I would come up with is below.

fingerprint deviceId:"0x1801", inClusters:"0x5E, 0x86, 0x72, 0x5B, 0x85, 0x59, 0x73, 0x70, 0x80, 0x84, 0x5A, 0x7A, 0xEF, 0x5B, 0x20"

If you try that does it pair properly? It may be that the fingerprint you are specifying is not matching the device since you are not specifying all of the “clusters” that the device is reporting.

[ajpri (Austin Pritchett)]

I got it!

@Motley, You were very close, but everything before the mark (0xEF) is considered inClusters (supported class), and after are outClusters (controlled classes).

Fingerprint (of device)

I don’t have the stomach to go into the full story of how the Raw Description is formatted and why. Just know that it was designed for ZigBee devices and Z-Wave was shoehorned in later. What you need to know is that the command classes that come before 0xEF COMMAND_CLASS_MARK are the supported classes – what the device accepts, more or less – and the ones after the mark are the controlled classes – what the device sends to others. For fingerprinting, we match the supported classes against the inClusters parameter and the controlled against outClusters.

This post helped answer it for me, but thanks for the guidance.
The Fingerprint is…

fingerprint deviceId:“0x1801”, inClusters:“0x5E, 0x86, 0x72, 0x5B, 0x85, 0x59, 0x73, 0x70, 0x80, 0x84, 0x5A, 0x7A”, outClusters:“0x5B, 0x20”

After Z-wave exclusion and re-inclusion, the device type paired without a hitch!

I’ll update the public GitHub file and call it Milestone 3.

[JDRoberts]

Awesome! If you think it’s ready, add a [RELEASE] thread to the device types sub forum so people can ask questions.

https://community.smartthings.com/c/projects-stories/community-created-device-types

[Motley (Michael)]

Glad you figured it out and got it working, my switch will be here in 3-4 days. Good to know that the 0xEF is the command class mark, the device type I wrote was a zigbee device type and for that it is slightly different, the first mark (after deviceID) says how many inClusters there are and then after those inClusters are defined the next mark says how many outClusters will be defined and then they are defined. Looks like for z-wave the first mark just defines the total number of clusters (command classes) and then the 0xEF mark defines the start of the outClusters.

I will be glad to help you test/refine the device type once I have mine if you still need help.

[jeffv2718 (Jeff V)]

Thanks, ajpri, for the code and work on this. I installed it over the weekend and it works perfectly with my GoControl switch.

[ajpri (Austin Pritchett)]

Thanks for the support & glad you liked it! Do note the Device Type is still under development and is evolving rapidly. This is my first Device Type and I’m learning as I go.

[marktheknife (Mark)]

Just got mine and it paired easily with the device handler installed. Button pushes seem to work just fine. But can the device handler deal with longer button holds? In the manual that came with the GoControl switch it seems like it should be capable of both presses and holds. Thanks for sharing this!

[ajpri (Austin Pritchett)]

Sweet! So it auto-identified correctly? Right now, the Handler only handles a press, but I believe it can handle a held event as well. I’ll take a look into it soon.

Soory about my slight absence from this project. As some of you may know, I’m just a High School Student, so I’ve been busy getting back from spring break. Also, I think I’m getting a bit under the weather. I’m good, just taking things easy. I hope to have a better code version uploaded soon (Milestone 4, estimating this weekend).