I've attempted porting Brian Dahlem's SmartThings driver for this Leviton scene controller to Hubitat. Although I've followed what guides I could find and what other advice I could glean from reading through this community's posts, I am unable to achieve complete functionality. I only get button presses from one button no matter what button I push on the controllers. I can verify that the controllers in question are fully functional as I can exclude them from HE, include them with another hub/system, and I get all functions to work. I am confident the issue is with my port.
The original driver is located on BDahlem's GitHub.
The original thread from the ST community is available for review too…
Given what I know, all I did to port BDahlem's driver to HE was replace all instances of physicalgraph to hubitat, remove the blocks about tiles and simulator, and change the capability from "button" to "pushableButton." But I have to be missing some step in the parse method or maybe in handling zwave API specific details? I also suspect from the log something odd might be happening during configuration as I see "NULL" in some of the payloads spelled out. That may be an oddity of how log.debug builds string conversions. I am not using the associated load feature in my installation.
The odd bits I see in my logs look like this — the first during configuration and the second when pressing a few buttons, 1 through 4 in order, then back again.
Looking as well for some help getting this device working. Without this device being supported currently on Hubitat I can't fully migrate from Smartthings.
So I have been looking at this device type handler for a few days now, made some changes but I too am no where closer than @r.p.ulivella. If anyone has some time to give us a hand with the device code, it truly would be helpful.
@mike.maxwell I personally own the VRCS4-1LX, I know others are using the VRCS4-M0Z. From my understanding it has to be the VRCS4 and not the VRCZ4 as the Z model is a Group controller and not a scene controller.
@chris.leight — confirmed and correct. I also can confirm I see the same thing in my logs as you do. When I re-join the device with another system (not Hubitat) I can see the alternative and complete payloads as you describe.
We're all on to this and now I'm excited to get this working!
Ok, I've been dinking with the VRSC4 on and off for the past week.
I've gotten a handle on what it can do, and I must say it's one of the more bizarre devices that I've ever worked on, anyway...
Right off the bat, I can see two different ways of implementing a driver for this, so given that I'm just looking for feedback as to which route to go.
Firstly the interesting bit.
Each of the 4 buttons (excluding the level paddle for the moment) operate at the hardware level as mutually exclusive on off switches, IE only one indicator can be active at a time.
They can be turned on and off via code, but only one of them can be illuminated at a time.
So option 1:
expose each of the 6 buttons in a button controller implementation
Buttons 1 through 4 can produce pushed, while 5 and 6 (the dimmer) can produce pushed and released.
option 2:
expose the 4 buttons as 4 separate child device dimmers.
each button would turn on/off it's respective child dimmer, and the level paddle would raise/lower the level of it's respective active child dimmer.
@mike.maxwell — my vote would be for option 1. The device feels like a stack of buttons to me and the use cases I see most align with this implementation. It also seems the more simple of the two overall.
It is very exciting to see progress on this. Woohooo!
@mike.maxwell I believe the way Leviton intended it to work was option 2. However, it was implemented as neither of those options in SmartThings. In SmartThings it was basically just buttons 1-4 and 5,6 did nothing.
If you implement option 2 I have a feeling somebody will take your work or what @chris.leight started and implement option 1 and then the community gets two options. If you implement option 1 the community will probably be lazy and not bother with option 2 since they (we... okay, I can share some blame... I've used it for years but I didn't want to bother with that mess after I saw bdahlem's original driver manually having to manipulate the device's LEDs...) never did anything but 4 buttons for SmartThings.
I'm getting values like '2D010404NULL'. I'm guessing this is converting whatever this command is into HEX or whatever but "NULL" isn't HEX. What's going on there? "buttonNum" is an integer but I also tried it with String in case it couldn't find the constructor. I have no idea how groovy and HE resolves those types of things.
This command isn't implemented, hence returning null.
We will implement it.
Also, I don't see any reason that option 1 and option two could both be implemented. Option 2 would be a preference setting to create the composite dimmer children.
A ha, @chris.leight ! That's why it's not working.
Sounds good, @mike.maxwell . Thanks! Is there a bug tracker or anything that you guys use that I can subscribe to so that I can see when it goes into a build?
Should the constructor perhaps assume 0 or the default instead of concatenating null? Or throw an exception if the third param is null? If you are me that's a hard one to troubleshoot me thinks without knowing what constructors are available.
I would almost prefer it to throw an exception so I can see a message in the logs or something. I guess once there a few circulating examples that's not an issue anymore.
None of the zwave commands have optional parameters or default values, it just so happens that ST implemented this particular one this way for whatever reason.
Yes, we're in need of documentation, in the mean time we just deal with these as the issues arise...
It is awesome to see some traction on getting this device to work in Hubitat. A big thank you goes out to @mike.maxwell for purchasing the device and reverse engineering a solution.
