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

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.

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!

1 Like

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

1 Like

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?

@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.

1 Like

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).


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.

4 Likes

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

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

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.

3 Likes

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

1 Like

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.

1 Like

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!

1 Like

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).

1 Like

Sure did. I pulled the battery tab and hit one of the buttons as the instructions said, while the ST hub was in pairing mode. The device came right up.

If you’re able to add the button hold events that’d be great. Then I can still use this to dim; for wife approval the top button is set to lights on, and the bottom to lights off (four GE link bulbs). I could probably work out a way with rule machine to add a dimming level with only button pushes, but holding is just simpler. Great work so far though.

1 Like

Did some messing around with some of the basic output. Looks like button hold events can be detected. I’ll continue messing around with the code and see what I can do. I personally don’t use the held event for any of my automations. However, I’ll get to work on that!

I have the same thing going on with my lights. Right now I’m using Smart Lighting but I’m working on a “companion SmartApp”. Just a modified button controller to handle this use case easily.

Thanks again for the support! Tell your wife I’m working hard on this & it’ll soon be even better! You have been a great part in growing this Device Handler.

1 Like

@ajpri, wanted to let you know that I got my switch today and hooked it up. It immediately paired with your device type which I had pre-installed on my hub and I was able to use the button controller app to setup the buttons to control a set of smart bulbs in a light fixture. The only thing missing as far as I can tell is being able to use the “held” presses to control the dimming/brightening of the lights.

Now that I have one of these if you would like help looking into the dimming/brightening functions I am willing to help with that, I am new to z-wave device handlers but have been doing some reading and also have written the zigbee device type for the OSRAM dimming switch so I can likely figure out z-wave fairly quickly as well.

I also wrote a smart app to go along with the device type I wrote which allows you to at least set a specific percentage for light level when held commands are received so that you can at least use the held buttons as a dim/brighten to specific levels. I will let you know once I test and see if that app will work with this device type, if nothing else I may modify the smart app to work. I have not given up hope for the OSRAM dimming switch since I do feel it has a better look but am still waiting for an OSRAM engineer to work with me on that.

I am going to update the thread for my device type with a quick comparison of the 2 switches (with pics of the 2 installed) and point everyone to this switch as an alternative until I can get the OSRAM one working.

1 Like

@AdamV has a very successful device handler for the Popp battery-operated zwave switch that has double tap and dimming. Not sure if it has anything you can use directly, but it might give you some ideas.

[Release] Z-Wave.me, Popp, & Devolo Wireless wall Controller & Key Fob (EU), with button controller dimming apps and CoRE integration

Hey Guys! Big update on the device type!
I have been busy working on the Device Handler.

  • Hold Events are under development! I still have some work to do, but it is looking good.
  • Inverting the buttons is still a mess. For now I have commented out the code. This isn’t a big issue since the Device Type Handler treats the buttons as independent, but If I can add it, I will.
  • The device type is coming together nicely. I hope to have something that I can call a “Version 1” in about a week. A big thank you to to everyone that has purchased the device and used the DTH.
2 Likes

Ajpri,

Thanks for all the great work so far. I was looking into this and trying to see about the hold events. I know the raw messages that it sends when you have the hold and release events just trying to see how you are putting them into the device handler. As it looks like we are going to have to approximate the percent on the amount of time that the button is held down.

Up Button Tap

6:31:17 PM: debug Parse received zw device: 0D, command: 5B03, payload: 6C 00 01

Down Button Tap

6:32:09 PM: debug Parse received zw device: 0D, command: 5B03, payload: 6D 00 02

hold down, release up - Top Button

6:32:54 PM: debug Parse received zw device: 0D, command: 5B03, payload: 6F 01 01
6:32:50 PM: debug Parse received zw device: 0D, command: 5B03, payload: 6E 02 01

hold down, release up - Bottom Button

6:33:28 PM: debug Parse received zw device: 0D, command: 5B03, payload: 71 01 02
6:33:25 PM: debug Parse received zw device: 0D, command: 5B03, payload: 70 02 02

0x5B

class physicalgraph.zwave.commands.centralscenev1.CentralSceneNotification
{
Short key Attributes
Short sceneNumber
Short sequenceNumber
List payload

String format()
}

sequenceNumber = Button

1=top 2=bottom

sceneNumber = Tap, hold down, release up

00=Tap
02=hold down
01=release up

Thanks for the work! I’ve been working on this all I could and am close to getting hold events working. Most of it has been testing to ensure things are working. I’ll be releasing the first bit of code to support held events soon. The release events are next on my to do list.

Milestone 4 is here!
Held events are now working. The release events are also working, but not perfect.