Support Leviton scene/zone controllers #2397
Comments
|
Edit: Removing discussion of the scene configuration part because we support that CC already (with a bug). See below. I'm actually impressed you figured out the button light piece. Mine were just frequently wrong. |
|
Also, node does support sending raw messages already. https://zwave-js.github.io/node-zwave-js/#/usage/custom From that any UI could if it chose handle this. And, as of a few days ago, zwavejs2mqtt allows you to send a custom driver message under the Advanced tab from which you could setup the scene events.
I'll leave it to @AlCalzone to decide if we intend to offer custom command classes beyond that at the node-zwave-js level. |
|
Hmm, that's good. I noticed Home Assistant doesn't plumb that service
through yet but that's fixable.
Does node-zwave-js also support receiving raw messages?
For OpenZWave I used the ugly but effective expedient of parsing the logs
in real time! 🤣
…On Sun, Apr 18, 2021 at 7:20 PM blhoward2 ***@***.***> wrote:
Also, node does support sending raw messages already.
https://zwave-js.github.io/node-zwave-js/#/usage/custom
From that any UI could if it chose handle this. I'll leave it to
@AlCalzone <https://github.com/AlCalzone> to decide if we intend to offer
custom command classes beyond that at the node-zwave-js level.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAY7BAGBO5HEQLGSPVWBVLTJOHPLANCNFSM43EUKB5A>
.
|
|
@AlCalzone will need to comment on that. From the docs:
My guess is that it would be an easier sell to overcome that than creating and supporting completely custom command classes, especially in light of the need. Our analytics are still early stage but so far there is only one Leviton device on the list and it isn't one of these (DZ15S). And I expect the Zooz ZEN32 would cut even further into these devices. (I've replaced my VRC4's with them.) HA did recently add a SERVICE ZWAVE_JS.SET_VALUE but I believe it only calls values setup already. It may be possible to expand that to include raw commands or create a new service. The dev_zwave channel on the HA discord would be a good place to take the devs temperature as to whether they'd merge such a PR. |
|
Actually it looks like that "better way" is pretty much what I have done.
I'd just like to make the configuration more systematic in some way so that
other people don't have to jump through hoops to make this work. Back in
the day, Vera configured these Leviton devices out of the box for scene
support and even supported the quirky indicator LEDs.
It'd be neat if node-zwave-js provided an extensible way to configure and
access device-specific functionality. For example, suppose that the device
configuration files allowed developers to describe "services" for the
device that could be enumerated and shown in a UI, similar to how other
parameters are exposed.
Pseudo-code example:
```
services: [
{
name: "Configure scene button reports",
commands: [
{ class: "scene_controller_conf", params: ... },
{ class: "scene_controller_conf", params: ... },
... 6 more of these ...
]
}, {
name: "Set indicators",
parameters: ... define the leds and their colors ...
commands: [
{ bytes: ... synthesize the message ... }
]}
]
```
…On Sun, Apr 18, 2021 at 7:10 PM blhoward2 ***@***.***> wrote:
So, there is a better way. You can configure those to send normal scene
commands with a little work.
https://blog.gruby.com/2019/01/04/setting-up-a-leviton-vrcz4-m0z-for-use-with-home-assistant/
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAY7BDKFU3ELEZOEI6OA4DTJOGI3ANCNFSM43EUKB5A>
.
|
|
Edit: Removing the scene configuration discussion to make this easier to follow. As for the services idea, could you flesh out other circumstances where this may be helpful and have wider applicability? OZW became, in my view (and I think other's view), bloated and complex because of a lot of one-off quirks built into the code base. We try to live by a different mantra, including working with manufacturers to fix things when possible. What else are you envisioning? I get the configuring for scene events here but I'm unaware of any other device that needs a similar setup. It's an interesting idea but it would be a fair bit of work for the UIs I suspect and UI space is at a premium. |
|
@robertsLando Thoughts from your end? An enumerated list of device-specific scripts (if you will) defined in the config files? |
|
Another example of weird stuff is my Intermatic spa controller. Some
values need to be refreshed after setting them. The thermostats are also a
little non-standard.
That said, the Leviton scene configuration behavior is technically an
official command class in the spec so one could argue that it should be
handled by the stack during device setup and/or presented to the user (just
like associations).
But there's always a question of what trade-offs are appropriate for
supporting rarely used features, "advanced" functionality, or quirky
hardware.
Right now, when the stack doesn't know how to support some feature,
responsibility
falls on the user to set things up, perhaps after reading blog posts or
doing some reverse engineering (hopefully not?). It's pretty tedious.
This seems like a problem that the device database can help users with in
various ways either in machine readable form (such as by formally
describing config params) or as a resource for finding relevant device
specific documentation.
Personally, I'm biased towards encoding more information in a machine
readable way, such as the quirky commands for setting LEDs. I don't know
how common this is but it's probably not a singular occurrence. (I wonder
if there's a good way to search for examples of folks sending raw zwave
commands.)
Some of the setup I had to do for my system was pretty finicky. I was
really glad to have the Zwave PC apps and a Zniffer on hand.
So...
I think what I'm really looking for is a single source of truth for device
configuration and control.
Zwave devices have a lot of internal state. Getting these Leviton
controllers to work required quite a few steps none of which were
automated. After the fact, there wasn't any record of what changes were
made or how to reproduce them. Just some docs and ad-hoc scripts I wrote
for myself.
For robustness, I'd love a model where the user specified the intended goal
state for device configuration and the stack made the necessary queries and
settings to get there. Assuming all of those settings are machine readable.
😁
…On Sun, Apr 18, 2021 at 8:31 PM blhoward2 ***@***.***> wrote:
Yes, I meant rather than implementing a new command class. If you couldn't
figure out (or sell AlCalzone) on the idea for the LEDs, users could still
configure it for scene events. I realized after that you could probably
figure it out to do it through zwavejs2mqtt. That was literally added on
like Friday.
As for the services idea, could you flesh out other circumstances where
this may be helpful and have wider applicability? OZW became, in our view,
bloated and complex because of a lot of one-off quirks built into the code
base. We try to live by a different mantra, including working with
manufacturers to fix things when possible. What else are you envisioning? I
get the configuring for scene events here but I'm unaware of any other
device that needs a similar setup.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAY7BBHOCWJOT4A62EQZN3TJOPZZANCNFSM43EUKB5A>
.
|
|
It looks like we claim support for scene controller configuration.
I was able to set the first four scene IDs and I see them come through when I hit the button. I'm not sure what happened to the other four though. |
|
@AlCalzone I'm unclear why we only query four scene IDs when there are eight. Where does it get four from...the fact there are four association groups? It should query double that number as each group has two scene IDs for on/off. |
Would be ok for me! |
If you're willing to do the work, you can take a look at how we're handling the That technically is an official CC, but the official part is just the framework for manufacturer specific implementations. Since every manufacturer is free to do their own thing within the framework, I think it is hardly feasibly to do that all in configuration.
Straight from the Z-Wave specs:
So, yeah... The device supports 4 association groups, so zwave-js queries 4 scene groups. There's currently no way to detect that there are in fact 8 groups. We'd need a compat flag for this.
This is probably unnecessary if you implement the proprietary Leviton CC, but you could do this with https://zwave-js.github.io/node-zwave-js/#/api/driver?id=registerrequesthandler and provide a custom implementation that inspects the received message if it is the one you're looking for. As for the services idea: I can see where this is coming from, but IMO that belongs in a higher layer than the driver. |
|
Leviton Scene Controllers have been part of my system since the beginning. Maybe I can provide some information how I use LED's and the different colors: I use the scene button to control two different scenes, not like the traditional "on/off". At the moment I have configured the scene controller for 6 scenes and an on/off for a fan. For the scenes I use the LED colors to indicate which scene is running: For the last toggle: LED is green when operated manually, orange when running on schedule and red if fan operation is blocked (e.g. due to AC running) I basically use them as status indicator. Currently in Vera but I am starting to move all the devices to Home Assistant. One other thing I like about the Leviton Scene controllers is the ability to use the bottom paddle to change brightness level on scenes / associated devices. I think Vera converts a lot of the scenes in associations. |
|
@j9brown, are you working on the required modifications for implementing LED color control on the VRCS / VRCZ scene controllers? I recently moved all of my kit from Vera to ZwaveJS except for one VRCS4 device. I am using some custom LUA scripting on the Vera to fire off a Home Assistant web hook that will manage states of my home theater equipment and set the color of the associated scene button depending on the status of the equipment. Since there appears to be no way to control the button LED or even detect scene controller button presses in Home Assistant with the VRCS devices, I have left this scene controller as my lone device on the Vera for now. Would you mind sharing some of the details on how you have set things up to detect scene button presses and achieved control of the LED color via custom scripting? I am happy enough to use a python script or otherwise to replicate the desired functionality until it is properly exposed in the Zwave-JS driver. |
|
Hi Tim,
I've been busy with other projects so I haven't done any work on this yet.
I mostly wanted to confirm that there would be a plausible path for me to
move to Zwave-JS once I'm ready to invest the effort. ;)
This part of my home automation system is currently implemented using Home
Assistant and Node RED together with Zwave2MQTT. It relies on being able
to inject and receive raw Zwave messages because Zwave2MQTT doesn't support
the necessary command classes. Zwave2MQTT supports sending raw Zwave
messages by sending a properly formatted MQTT message to the correct
endpoint. Unfortunately, it doesn't support receiving raw Zwave messages
but it does dump all received Zwave messages to its log. So I wrote some
hacky code to parse the log in real-time and decode the messages.
Surprisingly, it's been quite reliable!
Anyhow, the situation with Zwave-JS seems a little different at this point.
1) I don't think it's possible to inject raw Zwave messages from Home
Assistant right now. At least, I wasn't able to find a suitable API wired
up to Zwave-JS through a Home Assistant service at the time I last
checked. So setting LEDs isn't possible yet. (Note that a better solution
would be to implement a custom command class for indicators in Zwave-JS
itself anyhow.)
2) I think Zwave-JS parses Scene Activation commands and Multi-Level Switch
changes unlike OpenZWave. So I don't think it'll be necessary to parse raw
Zwave messages. I think that these messages might show up as value changes
with command class 43 and 38 respectively.
So here's what you can do:
1. Use SCENE_CONTROLLER_CONF_SET to set up all of the 8 scene groups
described at the beginning of this thread. I did this manually with the
Zwave PC Controller program but perhaps there's a better way in Zwave-JS
now.
2. Try pressing buttons on your scene/zone controller. Look to see if
Zwave-JS emits value change events with command class 43 command 1 (2B
01). The value associated with this event will tell you which scene group
was activated and that will tell you which button was pressed. If this
works as I hope it does, then you should be able to write some automation
code to handle these value change events and do stuff as desired.
Good luck!
Jeff.
…On Fri, Jun 11, 2021 at 10:43 AM Tim ***@***.***> wrote:
@j9brown <https://github.com/j9brown>, are you working on the required
modifications for implementing LED color control on the VRCS / VRCZ scene
controllers?
I recently moved all of my kit from Vera to ZwaveJS except for one VRCS4
device. I am using some custom LUA scripting on the Vera to fire off a Home
Assistant web hook that will manage states of my home theater equipment and
set the color of the associated scene button depending on the status of the
equipment. Since there appears to be no way to control the button LED or
even detect scene controller button presses in Home Assistant with the VRCS
devices, I have left this scene controller as my lone device on the Vera
for now.
Would you mind sharing some of the details on how you have set things up
to detect scene button presses and achieved control of the LED color via
custom scripting? I am happy enough to use a python script or otherwise to
replicate the desired functionality until it is properly exposed in the
Zwave-JS driver.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAY7BAOYYGBHNEZ66ZP4TLTSJDLNANCNFSM43EUKB5A>
.
|
|
You may still be able to send a raw message by using zwavejs2mqtt and turning on mqtt to do so. You can turn the api on without using mqtt discovery. The driver supports raw messages and zjs2mqtt does in the UI but I've never checked via mqtt itself. |
|
I have started to revisit this and am thoroughly confused on how to implement the actual syntax of the raw command in Zwave-JS required for setting the button led color on my VRCS4. I already have a simple python based websockets client working which will connect and pass commands to zwavejs-server. I would like to now use the client in a script to set the colors on these buttons. The command class detail provided here for the ManufacturerProprietaryCC https://www.silabs.com/documents/login/miscellaneous/SDS13781-Z-Wave-Application-Command-Class-Specification.pdf provides details for the data payload framing for this class. Based on the detail provided by @j9brown at the beginning this issue, a data payload of: I have spent quite a bit of time and cannot figure out the syntax that I should use to pass a custom command to set this value on node 33 in my setup via the ZwaveJS websocket server. Can someone more versed in this possible provide a hint? If this is not possible via websockets, what would the corresponding command look like if sent via mqtt to the zwavejs2mqtt api? |
|
I don't know the specific command, but it's likely easier to test in zwavejs2mqtt. It has a place to run raw JavaScript commands to the stick so you're removing a lot of middleware until you figure it out. |
|
The Javascript "console" in zwavejs2mqtt is a great place to test out stuff like this, so I second the recommendation. For the websocket server you should be able to use the I would try something like: {
"messageId": "invoke-mfg-prop-cc-set",
"command": "endpoint.invoke_cc_api",
"nodeId": 33,
"endpoint": 0,
"commandClass": 145, // command class = 0x91
"methodName": "sendData",
"args": [
29, // manufacturerId = 0x001D
[13, 1, 255, 0] // data = 0D 01 FF 00
]
}What I'm not sure about is the MQTT has the equivalent |
|
Thank you @kpine! Your suggestion is exactly where I ended up last evening and you precisely identified the remaining issue. After trying many iterations and a fair bit of googling, I don't think there is a way to serialize a byte object to JSON via python json.dumps() which will successfully pass into ZwaveJS. ZwaveJS is receiving the command but complains as follows:
|
|
#3354 adds the |
|
I would really appreciate any support for a Leviton VRCZ4-M0Z 4-button scene controller in the Z-Wave JS implementation in Home Assistant. I can add the device but the HA device configuration page does not give any way to associate other entities with any of the 4 buttons like I could with the old HA Classic Z-Wave driver. |
|
HA doesn't yet let you manage associations for any devices. You need to use zwavejs2mqtt to do so. It's just waiting on UI support on their end. |
|
blhaoward2, |
|
You can't run both addons but they both run the same driver in the background. You stop the zwavejs addon, start the zwavejs2mqtt addon, and reconfigure the zwavejs integration to uncheck the box so it doesn't reinstall the original one. No need to rename or anything so long as you don't remove the integration itself. |
I would completely agree. There are quite a few of us trying to migrate away from Cloud-Based solutions like SmartThings, and have a non-small number of the Leviton Scene controllers installed. (6 here myself) - would appreciate them functioning, at least as "push button, be able to trigger action"... Color buttons would be a bonus later. :) |
|
@dlasher You'll have to request support in the https://github.com/home-assistant/core repository. The driver (node-zwave-js) has had association support for a long time, but it needs to be implemented by applications aswell. As for the proprietary CC support: This is non-trivial without having a device to test with. Most other CCs have specs to implement against, this one doesn't. Anyone with some programming skills and a Leviton device will have to step up for this. |
|
I've gotten two Leviton VRCZ4s to work in my instance of HA Container + zwavejs2mqtt after a ton of trial-and-error. I use the Z-wave JS integration in HA rather than MQTT for z-wave devices .. someone smarter than me can hopefully figure out how to apply this to an MQTT use-case. Here's a summary of the steps I took.
I'm not sure how to set the LEDs for different states, but at least the above will get your switches functioning inside of HA. I'm sure there is a way to actually tie these to switches in HA, too .. I'm just using them as physical triggers for scenes and routines, so that hasn't been as important to me. If all you want to do is associate other z-wave devices to the buttons, you can do that in the group tab in zwavejs2mqtt. I haven't figured out a way to do that inside HA, though I haven't really felt the need to. |
|
FWIW, #4701 makes it less messy to define new proprietary CC implementations |
|
In case someone is still looking for a solution. I have pretty much all of the feature I used to have with Vera working with Home Assistant (LED propagation, intensity buttons, etc) and way more reliably than with Vera. I posted all the code and instructions here: The only feature that is still missing is supporting direct association between VRCZ4s and loads, i.e. right now it has to go through HA, so if HA is down - controllers are effectively dead. With Vera only LED propagation would stop working if Vera was down, so I'm pretty sure they used direct association. I believe the same can be achieved with HA if we had ability to trigger off of this event: HA observes it when a controller button is pressed, even if controllers are configured for direct association to other loads. The event is always the same, so it doesn't tell you which button was pressed, but the scripts' logic can be changed to deal with that by refreshing loads. |
|
Thanks for investigating. I've opened a feature request for that. Makes sense to support this IMO. |
|
Fwiw, I use the indicators of my controllers differently. When my script receives a button press event, it activates the next scene in a programmed sequence and lights up the button with a color that indicates the currently active scene (green -> amber -> red). I don’t use direct associations to define these scenes because they involve non-Zwave devices so my script handles all of the activation logic by way of Home Assistant. It works well for me. Anyhow, it sounds like adding an optional feature to manage the LED states automatically could be useful for some folks. I’d still want to continue driving the LEDs with my own logic to avoid any interference. Incidentally, I believe the Leviton controllers are designed to automatically update the LED states to their controlled loads themselves when they receive scene change reports from those loads but the mechanism isn’t reliable or supported by all devices. You can see this mechanism in action with associations for load loads (particularly VRCS2 with its built-in relays). |
Is your feature request related to a problem? Please describe.
Now that OpenZWave is deprecated in Home Assistant, I've started looking at device support that I'll need to migrate over to node-zwave-js. This issue concerns Leviton devices (of which I have many) such as VRCS2, VRCS4, VRCZ2, VRCZ4, VRR15, VRS15, etc.
These devices use some custom and less common command classes for various features. OpenZWave never supported them but I was able to work around the limitations by sending raw Zwave commands and parsing responses (not ideal). I'd love to implement a better solution for node-zwave-js but need some guidance.
Features needed:
Describe the solution you'd like
I basically need some help to plan the changes needed to support these features. I'm happy to write the code or provide documentation or test cases to delegate to someone else more familiar with this project.
For LED setting, we'll need a custom command-class. How should vendor-specific classes be implemented?
For scene activations, we'll need some method to configure the device's scene groups and receive activations so that the button presses can be handled correctly. This setting uses a different set of messages from the usual configuration parameters or association groups so how should it work?
Describe alternatives you've considered
If there's a way to send/receive raw Zwave messages then I could keep using my own code which generates/parses them but it wouldn't be of much use to anyone else.
Additional context
Here are some technical details from a patch request I sent to OpenZwave but didn't commit (because it would have required deeper changes to the project to implement properly): https://github.com/j9brown/open-zwave/tree/master/config/leviton
I reverse engineered most of this using a Zniffer.
For example, this explains some quirks of VRCZ4.
The text was updated successfully, but these errors were encountered: