ZWP WD100 Dimmer - Device Handler?


(Corey O.) #1

I purchased 2 Dragontech ZWP-WD-100 zwave+ dimmer switches from amazon:

I currently have a ceiling fan with an Aeotec Nano Dimmer and a GE Fan Control Switch shoved up into the box in the ceiling. I wanted to use these switches as “satellite” switches around the room to control the main ceiling fan and light without having any physically wired connection. The dimmer switch and levels would control the light (nano dimmer) while double-tap up/down would increment/decrement the fan speed.

Unfortunately, I cannot find a fully functional device handler that works for the ZWP-WD-100. The general consensus on the forums has been that it is the exact same hardware as the Homeseer HS-WD100+ model (this may be true) with a different firmware. Most people are saying that the HS-WD100+ device handler works well with this device, but I have not found this to be the case at all. While it does give me double and triple tap functionality, it does not properly report dimming via the normal tap-and-hold method. Here is a sample of of the device logs if I start from a “switch on, level - 99” state and tap and hold the down paddle to dim the lights by about 50%" (should be one single event):

NOTE: this is in reverse order (see the timestamps)

2018-05-04 2:37:54.884 PM PDT
moments ago 	DEVICE 		level 	51 		Office Ceiling Fan Light Satellite 3 level is 51%
2018-05-04 2:37:54.884 PM PDT
moments ago 	DEVICE 		switch 	on 		Office Ceiling Fan Light Satellite 3 switch is on
2018-05-04 2:37:54.777 PM PDT
moments ago 	DEVICE physical 		switch 	off 		Office Ceiling Fan Light Satellite 3 switch is off
2018-05-04 2:37:54.585 PM PDT
moments ago 	DEVICE physical 		switch 	off 		Office Ceiling Fan Light Satellite 3 switch is off
2018-05-04 2:37:54.585 PM PDT
moments ago 	DEVICE physical 		button 	pushed 		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 2:37:54.384 PM PDT
moments ago 	DEVICE physical 		switch 	off 		Office Ceiling Fan Light Satellite 3 switch is off
2018-05-04 2:37:54.384 PM PDT
moments ago 	DEVICE physical 		button 	pushed 		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 2:37:54.176 PM PDT
moments ago 	DEVICE physical 		switch 	off 		Office Ceiling Fan Light Satellite 3 switch is off
2018-05-04 2:37:54.176 PM PDT
moments ago 	DEVICE physical 		button 	pushed 		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 2:37:53.992 PM PDT
moments ago 	DEVICE physical 		switch 	off 		Office Ceiling Fan Light Satellite 3 switch is off
2018-05-04 2:37:53.992 PM PDT
moments ago 	DEVICE physical 		button 	pushed 		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 2:37:53.889 PM PDT
moments ago 	DEVICE physical 		switch 	off 		Office Ceiling Fan Light Satellite 3 switch is off
2018-05-04 2:37:53.889 PM PDT
moments ago 	DEVICE physical 		button 	pushed 		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 2:37:53.907 PM PDT
moments ago 	DEVICE 		status 	Hold ▼ 		Office Ceiling Fan Light Satellite 3 status is Hold ▼ 

Needless to say, this wreaks havoc with my dimmer sync script (https://community.webcore.co/t/sync-a-group-of-dimmer-switches/6307)

The switch and dimmer features seem to work just fine when I use the generic ‘Dimmer Switch’ device handler present in pre-populated smartthings list. The problem is that it doesn’t enable double/triple tap support. Here is the comparable output using this generic device handler for the same physical action described above:

2018-05-04 3:17:35.968 PM PDT
moments ago 	DEVICE 		level 	51 		Office Ceiling Fan Light Satellite 3 level is 51 

For now, I just want a device handler that will properly report switch on/off, dim levels, and double/triple taps. The ability to arbitrarily set LED light values would be nice too, but I’m not entirely sure that’s supported by the firmware at this time.


#2

There was an issue in the DH code that incorrectly sets the switch to off when held down. This also would affect the HS-WD-100+ but probably would not be noticed unless monitoring the state like you are doing with your sync script since the state normally ends up on.

I’ve updated the Device Handler to correct this. Please let me know if the issue is resolved or if it causes any further problems.


(Corey O.) #3

@Darwin Thank you very much for creating these device handlers and for responding so quickly. Unfortunately, I am still experiencing problems.

First of all, I updated to the device handler in the following revision: https://github.com/DarwinsDen/SmartThingsPublic/commit/a2fccdc99cbf03877ccb4ab9c2e29b33436610a3#diff-b1748f3c0ecc176eab564a83c65dda1b

In my smartthings API interface I double-checked that I see the following line in the published device handler code:
* 1.04 (05/04/2018) - Remove call to set switch to off when held down

I am still seeing a similar behavior. Here is another copy/paste of my list events from the API interface when I tried to dim the ZWP-WD-100 from 99 to 48%:

2018-05-04 9:25:20.017 PM PDT
moments ago	DEVICE		level	48		Office Ceiling Fan Light Satellite 3 level is 48%
2018-05-04 9:25:20.017 PM PDT
moments ago	DEVICE		switch	on		Office Ceiling Fan Light Satellite 3 switch is on
2018-05-04 9:25:19.918 PM PDT
moments ago	DEVICE physical		switch	off		Office Ceiling Fan Light Satellite 3 switch is off
2018-05-04 9:25:19.834 PM PDT
moments ago	DEVICE physical		button	pushed		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 9:25:19.627 PM PDT
moments ago	DEVICE physical		button	pushed		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 9:25:19.436 PM PDT
moments ago	DEVICE physical		button	pushed		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 9:25:19.235 PM PDT
moments ago	DEVICE physical		button	pushed		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 9:25:19.025 PM PDT
moments ago	DEVICE physical		button	pushed		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 9:25:18.826 PM PDT
moments ago	DEVICE physical		button	pushed		Office Ceiling Fan Light Satellite 3 Hold-Down (button 6) pressed
2018-05-04 9:25:19.178 PM PDT
moments ago	DEVICE		status	Hold ▼		Office Ceiling Fan Light Satellite 3 status is Hold ▼
2018-05-04 9:25:03.549 PM PDT
moments ago	COMMAND			poll		poll command was sent to Office Ceiling 

By contrast, I have an actual Homeseer WD200+ and the same action (with your WD200+ device handler) gives me the following events:

2018-05-04 9:34:02.176 PM PDT
moments ago	DEVICE		level	34		Office Ceiling Fan Light Satellite 1 level is 34%
2018-05-04 9:34:02.176 PM PDT
moments ago	DEVICE		switch	on		Office Ceiling Fan Light Satellite 1 switch is on
2018-05-04 9:34:02.031 PM PDT
moments ago	DEVICE physical		switch	off		Office Ceiling Fan Light Satellite 1 switch is off
2018-05-04 9:34:00.863 PM PDT
moments ago	DEVICE physical		switch	off		Office Ceiling Fan Light Satellite 1 switch is off
2018-05-04 9:34:00.863 PM PDT
moments ago	DEVICE physical		button	pushed		Office Ceiling Fan Light Satellite 1 Hold-Down (b ...

Oddly enough, it’s not interacting with my webCORE piston the same way: https://community.webcore.co/t/sync-a-group-of-dimmer-switches/6307

If I tie only the TWP-WD-100 switch to my aeotec dimmer with the above piston example, I get the following behavior:

  1. press and hold to dim TWP-WD-100 switch
  2. aeotec dimmer turns off
  3. TWP-WD-100 switch turns off
  4. aeotec dimmer turns back on at full brightness
  5. TWP-WD-100 turns back on at same partial dim level as when it turned off

If I tie only the Homeseer WD200+ to the aeotec dimmer, everything works as expected:

  1. press and hold to dim the WD200+
  2. aeotec dimmer dims to the same level as the WD200+
  3. (neither the WD200+ switch nor the aeotec dimmer ever shut off)

Let me know if there’s any more information that I can provide.

As an aside, I saw a posting somewhere stating that the ZWP-WD-100 devices had been updated to a 1.59 version of the dragontech firmware and that it acted differently than the WD100+ as a result. I don’t know if this is true or relevant, but I thought I’d mention it. Using a smartthings hub, I’m not sure how to update or even see the firmware version of each device.


(Corey O.) #4

@RobinWinbourne For the life of me I could not figure out how to PM you through this forum interface. Perhaps I haven’t been verified properly on this forum either? This is just a bump so that you know I’m the same on the webCore forum.


(Corey O.) #5

@Darwin
I’m playing a bit with the WD100+ groovy file. What does case 1 represent in the up/down paddle switch events (lines 326 and 362)?

Just a note: I’m not sure if it actually hurts anything, but it seems that the default cases in the switches are missing the break statements.


#6

I found that keyAttribute of 1 (case 1) was inconsistently applied by the switch when I originally wrote the handler, and it appeared at least at the time to be a less common result of a single tap. My guess now is that it was an intended implementation for hold release, but not yet reliable in the firmware. The resultant case 1 action in there now may be applied more consistently on your firmware version and could certainly be messing up your sync script, but probably not normal operation. Regardless I don’t think it will hurt to comment case 1 out. The break isn’t required for the last switch case, although arguably it is bad/inconsistent form on my part.


(Corey O.) #7

@Darwin
Thanks again for your replies and your device handler. You’ve been pretty helpful already, even if indirectly. WRT keyAttribute case 1, I had come to a similar conclusion. I already attempted to comment those lines out and it did not give me the intended results. In fact, after further investigation, I found that the latest device handler code was not reliably triggering the setLevel action when I did a tap and hold (sometimes it did, most of the time it didn’t).

Rather than spending a lot of time debugging your device handler on the dragontech device, I ended up tracking down the original “Dimmer Switch” device handler in the official smartthings repo and adding some of your code to it in order to get the double/triple tap functionality. It seems to be working exactly as intended so far. I have a few more thoughts, but I don’t have to time to record them here. I’ll try and respond again late tonight.

Thanks again for the attention you’ve given this.


(Corey O.) #8

Hi @Darwin
The firmware on my device is reporting as v5.19. How in the world do you check for OTA firmware updates, and how do you apply them in the smartthings world?

I had some time to play some more with the switch. Unfortunately, my modified device handler doesn’t seem to be working as well as I thought. As an experiment, I pulled the ‘Dimmer Switch’ device handler code from the smartthings repo here: https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/dimmer-switch.src/dimmer-switch.groovy

I pasted the code in as a new device handler: “Dimmer Switch 2.0” and the only thing that I removed was 'runLocal: true, ’ from the metadata definition. If I switch from the stock ‘Dimmer Switch’ to my new ‘Dimmer Switch 2.0’ device handler, the physical setLevel trigger stops reporting reliably. (The 7 LED lights still ramp up and down as expected). It sometimes reports its status change when I change the dimmer level with a tap-and-hold, but mostly it does not. If I use the smartthings classic app to issue a setLevel command, it always reports properly. I’m sure that I wouldn’t notice if the device were physically wired to the light bulb, but not reporting a status change to the hub is proving fatal to my satellite setup.

What exactly does the ‘runLocally: true’ parameter do, and is it possible that this is the difference in the behavior? Is there a way for me to verify that the code that I pulled from the repo is the same code that’s being selected in the smartthings api interface?

As for your HomeSeer WD100+ device handler, I noticed a few things:

  • The private dimmerEvents() method seems create the switch on/off event already. Doing this in the switch cases might be redundant?

  • I’m curious to know if the HomeSeer WD100+ is working properly with my type of setup. Do you have one in your possession to test? You might try powering it up without wiring it to a bulb directly then tethering it programmatically to another dimmer. Alternatively, you might just keep setting the dimmer level physically to see if every even properly reports the setLevel event to the hub. (As I mentioned, when I set the dimmer level programmatically it always reports)

  • I program in python all day and becoming anal retentive about whitespace and indentation is an occupational hazard. I’m assuming that you began with an existing device handler (like the ‘Dimmer Switch’) that used tabs all over the place. Like any good, modern, sane programmer you began using 4 spaces without giving it any thought. In text editors that format them similarly, it’s difficult to notice. However, in VIM the indentations are all over the place. I have half a mind to run a filter to convert the tabs on my device handler. I don’t have any experience with groovy, but it looks like 75% of the groovy projects on github are using 4 spaces, so I’m assuming that’s the standard?: https://ukupat.github.io/tabs-or-spaces/

Thanks again for your help, and let me know if I can do anything to return the favor.


#9

After reading your note, I did notice that the dim level value is returning inconsistently for the HS-WD100+. I made a small change to the handler to request the dim level after a hold up or down is executed and I haven’t seen the issue occur in my limited testing. I see the same problem with the default Z-Wave handler on the WD100+ now, which is odd since I don’t recall any of that happening when I first tested the switch a couple of years ago. I don’t see the same behavior with the WD200+

HomeSeer offers a Z-Wave firmware upgrade flash kit that can be used to upgrade these if you don’t have a HomeSeer controller. I don’t believe SmartThings supports OTA Z-Wave firmware updates yet. Regardless, I believe 5.19 is the current firmware version for the WD100+.

The intent of setting the switch on/off in the central scene switch case is to provide an instant status on/off response to the hub to make it quicker for smart apps to perform actions based on the switch on/off response vs having to wait for a round trip status query from the switch. Granted this isn’t necessary if you want to go through the trouble of using the DH button functions of the switch, but I thought it might make things easier for some.

Sorry - a bit rushed today. I also PM’d you if there is additional logging or debug information you’d like to share.


(Corey O.) #10

@Darwin

I made a small change to the handler to request the dim level after a hold up or down is executed and I haven’t seen the issue occur in my limited testing.

Cheers! I put your updated version of the device handler to the test and it seems to be working as you described. At this point, I’m not sure if there’s any reason to believe that there is a functional difference between the Dragontech ZWP-WD-100 device and the homeseer WD100+ device. Since the Dragontech model is $15 cheaper, that’s good to know. There is a very frustrating 4 second delay before the level event is reported, but I understand that’s probably the best that can be done. Does the original problem point to an issue with the firmware? If so, is there a place to report it?

I don’t see the same behavior with the WD200+

I’m using a WD200+ in my setup as well. The device + your device handler have been working as expected right out of the box. I’d suggest that this is currently the best dimmer switch on the market (at it’s $60 price tag, it has no excuse not to be).

HomeSeer offers a Z-Wave firmware upgrade flash kit that can be used to upgrade these

Would this be any different than getting the standard https://www.amazon.com/Aeotec-Z-Stick-Z-Wave-create-gateway/dp/B00X0AWA6E/ or https://www.amazon.com/GoControl-CECOMINOD016164-Linear-HUSBZB-1/dp/B01GJ826F8 ? I prefer the former because it allows you to pair devices without being plugged in.

The intent of setting the switch on/off in the central scene switch case is to provide an instant status on/off response to the hub to make it quicker for smart apps to perform actions based on the switch on/off response vs having to wait for a round trip status query from the switch.

I will have to defer to your knowledge and experience on this one. I have no knowledge of how this works. Can you expound a bit on the difference? I assume this is what’s causing the ~4 second delay on reporting level changes mentioned above?

Lastly, does zwave+ still have the capability to assign a group of dimmer switches to a group and allow them to communicate directly to circumvent the ~4 second hub delay altogether? Do these devices support that?

Thanks again for the quick changesets.