[ST EDGE] SmartThings Edge Driver for Leviton VRCS4-M0Z and VRCS4-MRZ (Beta)

Devices & Integrations Community Created Device Types
21

Here’s the weird part, so be patient.

  1. When you get the device initially and you wire it in, before you’ve added it to your Z wave network, pushing any of the four buttons will cause the load to go on or off.

  2. Now you add it to your Z wave network, and if everything goes right, you end up with two different devices: a scene controller with four buttons, and a separate “appliance module” which is the internal relay.

At this point, none of the four buttons will cause the internal relay to turn on or off. They have all been turned into local scene buttons instead.

  1. now you add the appliance module to a local scene controlled by whichever of those four buttons you want it controlled by. It could be button one, or button two, or button three, or button four. It’s totally up to you. You can also add additional devices to that scene.

Note, and this is really important, this is 2015 technology. It’s not a smartthings scene. It’s not a zwave “central scene.” It’s a Z wave “local scene.” That means information is NOT sent to the hub about these actions are unless you also use Z wave direct association and put the hub into the correct association group. So it’s doable but messy.

——-
Here’s a video showing this entire process and what happens with the light connected to the relay. So I hope that will make it clear.

———
Again, though, this was only the first generation of the firmware. The second generation had pretty much the same result, but relied on Leviton proprietary code. if I recall correctly (although I may be wrong on this one) with that version, the relay ended up connected to the first button, you no longer had a choice about which button to use for it. :thinking:

But as far as what commands are sent to the hub… No commands are sent to the hub. That’s what “local scene“ means. Unless you’ve put it in an association group, and in that case you aren’t going to get a hublike Command, you’re just going to get a basic command like you get from association. But for the primary function, the scene button endpoint is sending a Z wave local scene command to the internal relay. Two different devices in one plastic case, talking to each other.

22

Thank you, JD for the explanation.

I will work this weekend on cleaning up the current driver.

  1. Only accept the original device (Raw Description zw:L type:0100 mfr:001D prod:1302 model:0243 ver:0.02 zwv:2.67 lib:07 cc:85,2D,7C,77,82,73,86,72,91 ccOut:2B,2C) in the can_handle routine. I need to see if the CC commands have been pdated and use whether the device supports CommandCode 2D to distinguish the fingerprint from the MRZ device rather than the internal load.

  2. @M_A_U can then pair the device with my VRCS4 driver and the Internal Load will automatically be created as a Z-Wave generic switch.

  3. You can use Smarthings to associate the internal load to any button.

You mentioned different generations of the VRCS4-MRZ. Do you know how I can detect that?

@JDRoberts – thank you for the video, this makes my life much easier.

Henry

1 Like
23

Yes, I think it should be the easy way to make both work together.

I think that it should be done using Raw Description, but I am a “newbie” in developement. I have no ideia how to make.

But I have already posted it…

If you could make one raw description use your drive and the other one use default way, it can work. But it is just a guess.

And Harobison, I really apreciate you for spent time trying to help me. But I bet you will help a lot others too. Really thanks

1 Like
24

Yes, that would make sense. The internal relay is not a scene controller.

I don’t specifically know how to tell the two versions apart, you might ask Leviton support.

25

Ok, so I tried to see if I could accept

VRCS4-MRZ:

Raw Description zw:L type:0100 mfr:001D prod:1302 model:0243 ver:0.02 zwv:2.67 lib:07 cc:85,2D,7C,77,82,73,86,72,91 ccOut:2B,2C

and reject:

INTERNAL LOAD:

Raw Description zw:L type:1000 mfr:001D prod:1302 model:0243 ver:0.02 zwv:2.67 lib:07 cc:25,85,72,86,77,2B,2C,73,91 ccOut:82

by adding logic in the can_handle function. At first, I simply tried to “return false” to see if I could reject a new device with the fingerprint. No matter what I did, my VRCS4 driver was always accepted.

I am at a loss.

@nayelyz - do you have any solution about how I can code my driver to not bind even though the fingerprint (mfr, prod, model) is correct but the device is not compatible with the driver. If you follow this thread, the second (internal device) should just be configured as a switch.

Thanks

Henry

26

Hi, @harobinson

AFAIK, there’s no way to make a device not connect to the driver despite having its fingerprints, but you can change the driver that is controlling the device and configure it accordingly.

What isn’t clear in this case is how the internal load works, if you don’t want it to be connected to the driver, why did you add its fingerprint?
As I understand it is a “sub module” of the same physical device, right?

27

Welcome to the world of Leviton! If you see within the thread, this strange device pairs itself as two devices (a 4-switch controller and an additional single load switch). While you may say that the fingerprint is the same (in the Smartthings definition - mfr, prod, model), the device signatures have two additional qualifiers (type: 0100 vs 1000, and a different set of command classes they support).

I could create a sub-device driver but that would require me to create a full z-wave switch driver which is overkill. I would rather simply “return false from can_handle” and have a different driver selected.

I guess I have to ask what the return value from can_handle is really for. It seems logical that a false return from can_handle would imply that the driver cannot handle the device. Or am I mistaken?

1 Like
28

It is actually an independent device, just inside the same case. The two historically would join as two separate devices If you just did a scan with a certified Z wave hub. One would be a local scene controller, and the other would just be an on/off switch. Two different device IDs, not two endpoints on the same device.

29

No, the can_handle function allows us to set a special configuration for the device but that’s after the device connects to the driver.
A special configuration would be, in case this other device supports different CC, you can define their handlers there so the messages are handled properly.

Actually, every time a message from a device is received it goes through this function to know if it can be handled there, in this function, you can make different comparisons, for example, the cluster the message belongs to, you only need to send a boolean value to know if that message will go through this sub-driver or not.

ok, so, when you pair the device, it creates two device instances without your intervention, is that right?
I so, I’m picturing it like this:

if the “internal load” device gets paired as a separate device from the main one but doesn’t have the same CC as that one, then, it can be connected to the driver but its messages can be handled differently in a sub-driver instead of selecting another driver for it.

Or, you don’t want to create a subdriver with those different CCs?

Here I understand you don’t want to create an extra driver, so…

30

So based on this information, it seems that the best solution for the VRCS4-MRZ is as follows:

  1. When you pair the VRCS4-MRZ to SmartThings, two devices are created with roughly the same fingerprint and thus the VRCS4 driver is selected.

  2. The Scene Controller will be properly handled by the VRCS4 driver and life is good.

  3. While the Internal Load device (of the VRCS4-MRZ) will automatically select the VRCS4 driver, the user would have to manual switch the driver to a Z-WAVE switch.

@M_A_U and @JDRoberts, is that a good summary.

@Mariano_Colmenarejo – as the Z-WAVE guru, do you have any other recommendations?

Thanks all,

31

I know the independent third-party Z wave standard pretty well, I’m not familiar with the details of how edge drivers work, so I can’t really say much.

I agree Mariano would be a good person to ask about what you do when you have two different profiles off the same base fingerprint. :thinking:

32

Hi @harobinson

If I have understood your question correctly, it is that you want the VRCS4-MRZ to be paired with the driver and you do not want the other one to be paired.
Then I would try to make it match by the Command Class instead by manufacture, …

In the device, you would look for a C.C that differentiates devices, for example the C.C.: 2D Scene Controller Conf and would make this fingerprint to assign it the profile you need:
You can use two or three differents c.c too

- id: "Leviton VRCS4-MRZ"
    deviceLabel: Leviton XXXX
    commandClasses:
      supported:
        - 0x2D # Scene Controller Conf
    deviceProfileName: leviton-xxxxx

If you need both devices, you can also make a different id with a C.C that the other internal device has so that it pairs as a different device with the Switch profile

- id: "Leviton Switch"
    deviceLabel: Leviton Switch
    commandClasses:
      supported:
        - 0x25 # binary switch
    deviceProfileName: switch-binary
1 Like
33

Thanks for the advice. Would you also add the mfr, prod, model in the fingerprint to avoid having too many matches with other devices that may support the 2D command class?

34

Other question. Is there a way to match on the type field?

Raw Description zw:L type:1000 mfr:001D prod:1302 model:0243 ver:0.02 zwv:2.67 lib:07 cc:25,85,72,86,77,2B,2C,73,91 ccOut:82

You are giving me information that surely is not obvious in the documentation.

Thanks so much,

Henry

35

I have never tried to mix c.c. with manufacturer, … in the same id, I don’t know if it would work, you can try

36

It may not be in the documentation, but it is in many examples of drivers fingerprints.yml, which is as useful or more than the documentation

1 Like
37

Thanks for the hints.

Where can I find the values for genericType and SpecificType that the device reports?

Here’s the raw description of the device:
Raw Description zw:L type:1000 mfr:001D prod:1302 model:0243 ver:0.02 zwv:2.67 lib:07 cc:25,85,72,86,77,2B,2C,73,91 ccOut:82

Maybe: genericType = 10, and specificType = 00?

Thanks much,

Henry

38

Sorry, I can’t help you with this, maybe @nayelyz can

1 Like
39

Guys

I am posting to let you know that I will be absent next two weeks. Unfurtunally I am going out in a working travel. But when I return I will be able to make tests if necessary…

1 Like
40

Have a good trip. I think that I found a way to include your VRCS4 and not the internal load. I updated the driver. It should be pushed to you.

The driver information is 2023-03-05T15:54:18.414662764.

When you pair the device, you can hit the … at the top right, select Driver, and see the version information.

Hope this works.

Henry

1 Like