Leviton VRCS4

So I just added a SmartThings V2 hub and VRCZ4-M0Z to my Philips Hue and Alexa setup.

I’ve installed your DTH and SmartApp, changed the DT on the VRCZ4, configured the associations in the SmartApp – and while the VRCZ4 LEDs now faithfully track the state of their respective lights, the VRCZ4 buttons don’t turn them on or off.

The Alexa, Hue, and SmartThings apps can all turn these lights on and off (as can Alexa voice commands), and they all properly track actual on/off status – as do the VRCZ4 LEDs. But when I press a VRCZ4 button, the LED just blinks twice, then returns to its previous state.

Have I missed a configuration step somewhere?

…OK, I just re-read your 4 January reply to @lee and I think I see my problem:

Your design assumes we’re associating to lights that are load-controlled by Z-Wave switches, and that the VRCZ4 will operate these switches directly, yes?

In my case, the target devices are Philips Hue lights (which, I understand, speak ZigBee under the covers) – so it appears I’ll need additional code to actually make the VRCZ4 buttons control the Hue bulbs after all.

Is this something I can apply separately (like a second SmartApp on the VRCZ4, per @lee’s comment) or should I look at adapting your same DTH/SmartApp for Hue compatibility?

Yah as you noticed the dth expects to send zwave commands directly to zwave switches (works with some outlets too) on button press. The commands are also send to the hub, so it’s aware of the button pushes, so it should be technically feasible to trigger non-zwave devices with it, but it definitely doesn’t do this today.

Might be easier to adapt the status light handling to a full featured button controller smart app then adding all sorts of button options to mine.

Here’s a first-cut DTH and SmartApp for the Leviton VRCZ4-M04, adapted from your VRCS4 modules:

They seem to be working perfectly for on/off with my various Philips Hue bulbs and strips – still have to look at adding dimmer functionality.

I’m bypassing most of the Z-Wave association stuff, but I’ve left it in for now (since I figure it might be useful in a mixed-device environment). Definitely curious if anyone has suggestions for improvement; meanwhile, I’ll post again if/when I get dimmer functionality added.

1 Like

So…I have the VRCZ4-M0Z working with non-zwave devices (links here), but (so far) only for on/off – and as of now, I can’t seem to detect any message activity at all for the dim/bright (fifth) button at bottom.

How is that even possible? Isn’t the device necessarily generating zwave commands for dim/bright?

I do notice that the instruction sheet for the VRCZ4 says:

      NOTE: Controller will only Dim/Bright devices
      located within direct Radio Frequency range.

Not sure what that’s supposed to mean (viz., how that’s different from the other buttons), but is it really possible that the SmartThings hub can’t (ever) receive information from the dim/bright button? Or maybe there’s just some other/additional association that needs to happen?

In any case, I wondered if any of you (@digitalboi, @bdahlem, @zala, @ygelfand, @jdroberts) might have more information or insight along the lines of Jason’s quote above – i.e., “I am using @bdahlem’s VRCS Button Controller SmartApp to control all 4 buttons on the VRCZ4 (the dim buttons on the bottom do not work, boo).” [emphasis added]

Grateful for any pointers to info that might exist here in the community, or elsewhere. I’ll try to contact Leviton as well.

TThere are two kinds of Z wave commands.

One kind goes to the hub.

The other kind goes directly between two end devices. Both of these devices have to be using Z wave to communicate, and they have to be within range of each other, typically in the same room. (Hue bulbs are zigbee devices, so they cannot be used in this way.)

If you have a Z wave only system, and you aren’t using a mobile app for status, then you might set up something like this so that a motion sensor would directly trigger a light. Or, for a zone controller such as this one, so that A zone controller could send a message to other devices in the same room. Because they aren’t going to the hub, they are limited to “one hop.” ( and again, all the devices have to be zwave.)

Most people don’t use those kind of devices with a multiprotocol platform like smartthings, or, to be honest, with any system where you going to want to use a mobile app, because since the hub doesn’t know about the activity, the mobile app won’t either and everything gets out of sync.

The Leviton zone controllers, as has been discussed several places in the forum, are old style devices intended for the kind of communication that doesn’t go through the hub. So that’s why the hub is not getting any information from that 5th Button.

There are a number of other devices which will work with a multiprotocol platform and will let you press a button on the wall on a Z wave device, have that talk to the hub, and then have the hub send a message to a zigbee or WiFi device. But they aren’t this particular model.

Thanks for this, JD.

I’d picked up on the difference between hub communications and z-wave direct association – I think that’s (at least part of) why @ygelfand’s DTH and smartApp weren’t working for me with my Philips Hue bulbs initially.

But I have been able to replace z-wave direct association with ST/Hue functionality for the first four buttons. So what’s different about the fifth?

You’re saying that the SmartThings hub can only receive/understand some subset of z-wave commands (which includes the on/off for the first four buttons, but not the dim/bright on the fifth)?

P.S. I’ve found your post here and followed it to these pages:


Should these be indicating whether/why the two devices can share on/off info, but not dim/bright? (Also, are V1/V2/V3 backwards-compatible?)

The fifth button works differently than the other four. The first four just send a “basic” (that has a specific meaning in a zwave context) Command to the devices in a specific Association group. The fifth one sends a multi set level to the association group that was last used, so it’s proprietary firmware. You need to get more details from Leviton as to how exactly it works. And then you would need to write new custom code to try to capture it, but I don’t know how you’re going to know what the previous group was.

And all zwave generations are backwards compatible, that’s part of the specification.

the 5th is definitely different, you might need to do some trickery, but it should still be doable. It expects to talk zwave directly to zwave devices (which is why it works just fine w/ my dth). Do you have your buttons associated (zwave wise, not via ‘virtual’ controls on the hub) to any actual zwave device? That’s probably the part you are missing.

The DTH will work fine If the Device is being used as the manufacturer intended, to control other Zwave devices within one hop of it.

@mpk wants to control Hue bulbs (zigbee, not zwave). That means they have to go through the hub, there’s no way to have a zwave device talk directly to a zigbee device, you need the hub as a translator.

Yes, that’s exactly what I’m saying. 5th button wants to talk only zwave. It can’t talk zigbee. However if there’s no associated devices, the 5th button send nothing to no one. If you have an associated device, with the button it is operating, it should send zwave commands that the hub can see, and then his dth can react to it via whatever action he wants. Basically what i’m saying is, he may need to make sure its associated to some (Even if non-existent zwave device) just so he can “see” the button press on the hub’s end. As I said, my dth works, but I can also see the button presses on the hub, and add other actions if I was so inclined (since I purely control zwave devices with all my vrc[sz]4’s, I don’t, and don’t care).

1 Like

OK, I see what you’re saying. But You can’t use association with a virtual device, it has to be an actual physical Z wave device.

That said, how does the fifth button work on your device? Is it not acting as a dimmer for any of the other four button groups, just dimming the last one used?

So you press button three, then you press the dimmer button, and the dim command is sent directly to whatever devices you had associated to button three.

If you press button two, then you press the dimmer button, then the dim command is sent directly to whatever devices you had associated to button two.

That’s how Leviton says it works. First you press one of the four buttons to select the group, and then you press the fifth dimmer button. And the device uses its own internal firmware to figure out which group to send that dim command to.

that will work fine if it’s all zwave devices in the same room.

If you want the hub to try to catch the request and then do something with a zigbee device, the question is going to be whether the hub is going to know which group the dim request is intended for.

Also, I’m not sure exactly how @mpk is trying to use it. If they are trying to just press the fifth button without ever having pressed one of the four buttons first, that’s definitely not going to work because of the internal firmware in this controller. The fifth Button by itself doesn’t do anything. First you select from the four groups represented by the other four buttons, and then you use the fifth button to issue a dim command to the group you just selected.

You don’t get five groups just because there are five buttons. you get four groups and a dimmer button which can be used with any of the four, but you have to select one of the four first.

This is great stuff, folks – thanks for all the feedback.

To @JDRoberts: Knowing what the previous group was is not a problem, because the DTH already tracks whichever of the four on/off buttons was last pressed. That becomes part of the device’s state, and can be interrogated/retrieved when (if?) I’m able to trap and respond to presses of the fifth button.

To @ygelfand: I totally get the bit about the fifth button needing the other four to be associated to real z-wave devices…and was wondering – isn’t the SmartThings Hub a “z-wave device”? Do you suppose I might be able to associate all four buttons to the hub itself? (It doesn’t actually matter what they’re associated to, so long as they’re “associated enough” so that I can see the activity hitting the hub.)

Failing that, I suppose I could add an extra z-wave device that I don’t really need, other than to be the z-wave association target for the buttons…?

(Also, it occurs to me that if the fifth button is actually "tracking" the four association groups, and selectively sending its dim/bright commands *only* to that group, then the z-wave message itself must be encoding the association group within it -- and if so, then I probably won't even need to interrogate the device for the "current button"?)

Quick update: Incredibly, it seems that associating the groups to the ST hub itself is doing the trick!

I need to confirm, but the problem I was having originally with @ygelfand’s associateHub() routine is that the Philips Hue device network IDs have slashes in them (e.g., “001788280F07/2”), so they were “choking” the integerhex() calls embedded in the zwave.associationV2.associationSet() calls – meaning that I’d never successfully associated the groups at all!

Once I changed them to simply use the zwaveHubNodeId instead (“01”), I’m now seeing this traffic in the logs:

12:11:00 PM: debug Entrance 4-Button South button 0 was released
12:11:00 PM: debug Entering buttonEvent() for button 0...
12:11:00 PM: debug SceneActuatorConfGet: SceneActuatorConfGet(sceneId: 0)
12:10:28 PM: debug Entrance 4-Button South button 0 was released
12:10:28 PM: debug Entering buttonEvent() for button 0...
12:10:28 PM: debug SceneActuatorConfGet: SceneActuatorConfGet(sceneId: 0)
12:10:27 PM: debug Default zwaveEvent handler: SwitchMultilevelStopLevelChange()
12:10:26 PM: debug Default zwaveEvent handler: SwitchMultilevelStartLevelChange(dimmingDuration: null, ignoreStartLevel: false, incDec: 0, reserved00: 0, startLevel: 0, stepSize: null, upDown: 0)
12:10:26 PM: debug Default zwaveEvent handler: SwitchMultilevelStopLevelChange()
12:10:25 PM: debug Default zwaveEvent handler: SwitchMultilevelStartLevelChange(dimmingDuration: null, ignoreStartLevel: false, incDec: 0, reserved00: 0, startLevel: 0, stepSize: null, upDown: 1)
12:10:25 PM: debug Default zwaveEvent handler: SwitchMultilevelStartLevelChange(dimmingDuration: null, ignoreStartLevel: false, incDec: 0, reserved00: 0, startLevel: 0, stepSize: null, upDown: 1)
12:10:24 PM: debug Default zwaveEvent handler: SwitchMultilevelStopLevelChange()
12:10:24 PM: debug Default zwaveEvent handler: SwitchMultilevelStopLevelChange()
12:10:24 PM: debug Default zwaveEvent handler: SwitchMultilevelStartLevelChange(dimmingDuration: null, ignoreStartLevel: false, incDec: 0, reserved00: 0, startLevel: 0, stepSize: null, upDown: 0)
12:10:23 PM: debug Default zwaveEvent handler: SwitchMultilevelStopLevelChange()
12:10:23 PM: debug Default zwaveEvent handler: SwitchMultilevelStopLevelChange()
12:10:23 PM: debug Default zwaveEvent handler: SwitchMultilevelStartLevelChange(dimmingDuration: null, ignoreStartLevel: false, incDec: 0, reserved00: 0, startLevel: 0, stepSize: null, upDown: 1)
12:10:23 PM: debug Default zwaveEvent handler: SwitchMultilevelStartLevelChange(dimmingDuration: null, ignoreStartLevel: false, incDec: 0, reserved00: 0, startLevel: 0, stepSize: null, upDown: 1)

The hub is one plastic box with two different network control devices in it, one for Z wave and one for zigbee. So you essentially have two different networks running. They don’t use the same format for their device IDs. You should never have a zigbee device ID as the target of a zwave command.

You can only use zwave direct association between 2 zwave devices. And, yes, the target Z wave device
could be the hub itself.

Yah that’s basically along the lines of what I was suggesting, associate to something/anything, and the hub should see the req’s. That said, i don’t think you’ll get a desired target, as the zwave command won’t include who it was sent to, as it sends the command to that target. You’ll need to track who you want to talk to. Also as you may have noticed, you don’t get multiple commands while holding the button, you just get a ‘started holding button’, ‘stopped holding button’ command sent to you. So if you want gradual dimming by holding, you have to do some trickery on the dth’s side. Otherwise it should be functional. If you have trouble and think I can help, let me know.

1 Like

Thanks, Yuri – I’ve got it all working now (though it’ll probably benefit from some further tuning).

Indeed, I already had last-button tracking within the DTH state, and I did see that I’m only getting start/stop messages. I’m using an atomicState flag in the smartApp to toggle between “start” and “stop” modes – once you press the dimmer (“start”), it flips the flag and then repeats until the flag gets flipped back to “stop”, or the level hits 0 or 100. (I’ve tried both looping and recursion – I don’t love the recursion, but the loop seemed less responsive to changes in atomicState.) And without sleep() available, I had to use an old-school empty loop just to eat up time between iterations. (Too fast, and the smartApp doesn’t catch the revised level from the target – meaning it just keeps resetting it to the same level.)

Now that it’s working (here are the latest DTH and smartApp), I’ll probably experiment a bit further with looping vs recursion, and with iteration delays. (As of now, it still feels a bit sloppy in terms of ramp-time and start/stop responsiveness.) I might also try reverting to reading the target level only once at “start”, and then just incrementing the level locally on subsequent iterations.

OK – I’ve just committed a redesign of the dimming logic which vastly improves its performance.

I’ve reverted from recursion back to looping, but also broke the logic apart so that an entry method takes the current levels of all devices on the last button switched, and then passes the particulars (that button device, its starting levels, and the directional increment) into a separate looping method, which (now) just increments iteratively upon its own starting value (rather than trying to re-read the actual device level on each loop).

This eliminates the timing issues (and erratic lags) in trying to read (and then rewrite) the level on every loop, and has the added benefit of “locking” the ramp for the duration of the button-press (even if some other controller is simultaneously trying to alter its level).

It still needs an empty (inner) loop just to slow the iterations – otherwise, the device either doesn’t track the ramp (maybe because it can’t respond to so many level changes so quickly?) or it buffers up too many level changes before it can respond to a change in the atomicState flag (and thus “overruns” the ramp when you let go of the dimmer button).

As it stands now, it seems very reliable/consistent, and fairly accurate on starting/stopping dimming – certainly usably responsive, at least (if a little slower on the ramp than I might otherwise like). I still have it incrementing (or decrementing) by only 1 (out of 0 to 100) on each loop; I might experiment with larger increments while also further slowing the inner loop, which should make it more responsive (but possibly less “smooth” looking?)

P.S.: Now further improved, as described here

1 Like

Hi Iskender, First let me thank you for your enhancements to Brian’s great work. For a time, my logs were showing button one presses, but now alas they are not. At one point, using Brian’s Smartapp, I switched the button one association to control the internal relay to on, and saved, then hit configure in the tile. Presently, something is amiss: Button 1 turns the internal relay on, but wont turn it off. I’d prefer to create a scene with that button, but logs show no activity when i press button 1 and tile doesn’t show it either (as it does for buttons 2-4). I am able to configure scenes for all but button one. Also, my dimer buttons do not appear to be working, and the button lights do not remain on for current scene. I’d appreciate any ideas you or anyone else may have to resolve my problems, especially the button one problem. Thanks in advance.

A quick update! Repairing solved the button one problem, but still looking for solutions to handling dimming switch presses.

@ygelfand - know any way to fix this?

To be clear, in ST, you only see the first button push.

EDIT: When I switched to @mpk’s DTH/SA, it correctly sets the scenes on each button, solves the problem. Beautiful!

1 Like