Command Class Wishlist

[AlCalzone]

All users of this library: here's your chance to influence which CCs I will implement next.

The rules are simple:

1. Pick one of the un-implemented CCs
2. Vote for it: a. Search this issue. If there's a comment for your CC, vote for it using the thumbs up button. b. If there's no comment yet, please add one.

Unrelated comments and comments that don't follow the rules will be ignored and deleted.

---

These CCs are next:

1. this could be your CC!

---

Already requested:

• Application Status - Won't be supported. Supervision is better in every regard and we can't match the Application Status commands to the requests they belong to.
• Association Command Configuration
• Meter Table Monitor
• Schedule
• Screen Meta Data

[RoboPhred]

Color (0x33)

I would like to try implementing it, but so far I have been unable to find the spec docs.

[AlCalzone]

That's the Color Switch CC, to be found in https://github.com/AlCalzone/node-zwave-js/blob/master/specs/SDS13781-Z-Wave-Application-Command-Class-Specification.pdf on page 148ff. If you would like to make a PR, go ahead.

[77656233]

"Alarm Sensor CC" for Fibargroup FGSS001

16:08:05.075 CNTRLR « [Node 013] TODO: no handler for application command 16:09:17.290 DRIVER Dropping message because it could not be deserialized: The command class Alarm Sensor is not implemented

Thank you!

[larstobi]

Association Command Configuration

[larstobi]

Scene Actuator Configuration

[larstobi]

Scene Controller Configuration

[robertsLando]

Thermostat Fan Mode

[robertsLando]

Thermostat fan state

[varet80]

I am interested in Schedule one, to be used with new devices supporting scheduling Schedule Comman Class. I am also happy help implementing it

[kpine]

Barrier Operator

[MYeager1967]

I'd love to finally be able to move my scene controller, an Enerwave ZWN-SC7, off of the Vera controller that it resides on. This device does not support the Central Scene Command class (91 or 0x5B). Instead, it uses Z-Wave Group Associations along with the Scene Controller Configuration Command Class (45 or 0x2D). This is described in the user manual. You use this command class to a map an association group, which is mapped to a physical button, to a scene ID. For example, for this device it looks like Group 1 is mapped to “Button 1”. The scene ID can be any number 1-255. I'm certain to be moving to zwavejs as I use Zwave2mqtt and it's moving to zwavejs.

[AlCalzone]

@MYeager1967 please upvote https://github.com/zwave-js/node-zwave-js/issues/729#issuecomment-730310951 to vote for Scene Controller Configuration

[jtscott]

Entry Control, literally no DIY keypad solution on the market at the moment!

[LordMike]

Application Status

I'm seeing some reports of it being dropped due to not being supported. Has something to do with "device being busy". Sounds simple :)

[maivorbim]

Irrigation, given that summer is coming :)

[AlCalzone]

summer is coming

I'll use that as the release name

[bepsoccer]

Sound Switch, please. I have a couple of the Zooz MultiSirens that I use with the legacy HA Zwave implementation that use parameter 3 via a service call, Sound Switch would make life easier! Nevermind, its implemented, just need to figure out how to use it in HA/Node Red.

[Ikcelaks]

I'm currently working on Scene Controller Configuration and will do Scene Actuator Configuration afterwards.

[AlCalzone]

Reminder:

Unrelated comments and comments that don't follow the rules will be ignored and deleted.

[maivorbim]

Powerlevel CC would be very useful to debug networks and would integrate nicely with the new node graph.

[WizKid]

Started implementing Entry Control in https://github.com/WizKid/node-zwave-js/commit/7648f2de5669df450976023870a529d71e6cd8ac . Still more to do which I'm planning to do. But thought I post in case someone else is working on it.

Especially handling the notifications and doing something useful with them. But I'm testing it with Ring Keypad and overall it seems to work. Pushing in a code and clicking Arm or any of the other buttons works. In the sense that the messages are parsed and I can see in the log that we get the right data.

[Ikcelaks]

Powerlevel CC would be very useful to debug networks and would integrate nicely with the new node graph.

I'm implementing PowerlevelCC now.

[WizKid]

Put up a pull request for Entry Control at #1838 .

[arcticgreen]

I’m voting for MultiCommandCCCommandEncapsulation since I have three Philio PST02-1A that are ignored when they send motion and door-open data... (temperature and illuminance are OK):

14:38:55.358 DRIVER « [Node 024] [REQ] [ApplicationCommand]
                       └─[MultiCommandCCCommandEncapsulation]
14:38:55.365 DRIVER   Received a command that contains multiple CommandClasses. 
                      This is not supported yet! Discarding the message...
14:38:55.367 CNTRLR « [Node 024] TODO: no handler for application command

https://github.com/zwave-js/node-zwave-js/blob/09d5ab6f2289bbf6e8a13d2f5ce8347353c82494/packages/zwave-js/src/lib/driver/Driver.ts#L2270

[gbuktenica]

Energy Production

[Hedda]

Window Covering

[jprates]

Hi,

Thanks for asking the masses what we need.

I'm voting for Transport Service as I've loads of messages on my log stating "Dropping message because it could not be deserialized: The command class Transport Service is not implemented".

I think they are being generated while trying to communicate with my Aeotec Water Sensor 7 Pro, so maybe this will also help pushing for that device to be supported soon. ;)

[danielbrunt57]

Door Lock Logging

[EiNSTeiN-]

Humidity Control Mode/Operating State/Setpoint

[pmeulen]

Meter Table Monitor

I've an "Eneco - Meteradapter" by "Prodrive B.V." PN: 6599-1500-0201 that sends this command. It is connected to the P1 port of my electricity meter.

https://products.z-wavealliance.org/products/1281

Z-Wave JS logs show two of these every 10 seconds:

SERIAL « 0x0122000400081c600d06003d0d000111000007e601090d1d0060006fbc9d67000 (36 bytes)
         0013b0c
DRIVER   Dropping message because it could not be deserialized: The command class Meter
          Table Monitor is not implemented (ZW0303)
SERIAL » [ACK]

I expect that this contains the kWh counter(s) of the meter. The node currently shows as <unknown> Manufacturer and Model in HA. However it identifies itself as:

"manufacturerId": 304,
"productId": 0,
"productType": 2,

[jmgiaever]

Schedule Entry Lock V3

E.g to be able to set temporary/time limited user codes on locks.

I'm aware it's deprecated, but guessing many locks that exist today use this CC.

[mikemcguire513]

I would like to see support for the Screen Meta Data Command class. This would allow for setup of Button Labels on the Nexia NX1000 scene controller.

[danielbrunt57]

Command Class: Door_Lock_Logging

[AlCalzone]

@danielbrunt57 you keep requesting that, but it is supported already.

[danielbrunt57]

@danielbrunt57 you keep requesting that, but it is supported already.

I have had this Kwikset 910 since about 2008 and it supports these command classes:

• Antitheft V2
• Association Grp Info
• Association V2
• Battery
• Configuration
• Device Reset Locally
• Door Lock Logging
• Door Lock V2
• Firmware Update Md V3
• Manufacturer Specific V2
• Notification V4
• Powerlevel
• Schedule Entry Lock V2
• Security
• Time Parameters
• User Code
• Version V2
• Zwaveplus Info V2

From 2000 to 2021 I used HomeSeer and had logging in 2008 when I acquired the lock (that's 15 years ago btw!) yet I see nothing in Z-WaveJS resembling logging...

am I missing or not understanding something???

[AlCalzone]

Not all CCs are exposed via the value API. Some are just too complex for that, some don't make tons of sense. In this case, each logging record would be a combination of 5 separate values. https://zwave-js.github.io/node-zwave-js/#/api/CCs/DoorLockLogging

AFAIK this CC also doesn't operate in push-style but would have to be polled sporadically/on demand.

You can open an issue in https://github.com/zwave-js/zwave-js-ui and request support for a dedicated UI for Door Lock Logging.

[tamorgen]

I've been in contact with iBlinds tech support, and they are telling me that many of the issues I have with iBlinds are due to the command class that ZWave JS is using (Multi-level switch). They told me that there is a newer command class for Window Coverings, that isn't being implemented by many hubs, that is more appropriate for Horizontal blinds. Is this command class implementation on the roadmap any time soon?

If it is, what would need to be done to change the device integration?

[WizKid]

@tamorgen : Maybe I'm misunderstanding the specification. But according to page 159 of the specification https://raw.githubusercontent.com/zwave-js/specs/d6c115ec1c46dd1db9f3dca3fc2106df577fac9c/Z-Wave%20Device%20Class%20Specification.pdf it says:

It is not RECOMMENDED to use this generic device class for new devices. Instead, it is RECOMMENDED to base devices of this category on the Multi-level switch generic device class with the Multi-position Motor specific device class

To me that sounds like ZwaveJS is doing the right thing.

[tamorgen]

@tamorgen : Maybe I'm misunderstanding the specification. But according to page 159 of the specification https://raw.githubusercontent.com/zwave-js/specs/d6c115ec1c46dd1db9f3dca3fc2106df577fac9c/Z-Wave%20Device%20Class%20Specification.pdf it says:

It is not RECOMMENDED to use this generic device class for new devices. Instead, it is RECOMMENDED to base devices of this category on the Multi-level switch generic device class with the Multi-position Motor specific device class

To me that sounds like ZwaveJS is doing the right thing.

No, it should not. The problem here is that while the generic multi-level command class works fine for roller shades or curtains, where Open is at one end of the spectrum, and close is at the other, Horizontal blinds have an open at 50% (in the middle).

To quote their CFO, with whom i've been interacting:

Horizonal blinds are relatively new to the smart home environment. Z-Wave just recently implemented a specific command class for Window Coverings which includes horizontal blinds. However, to date, there are no hubs that have implemented the new command class. Instead, all hubs are still using the Z-Wave Multilevel Switch command class to support window coverings. While this works well for roller shades and curtains, it is not ideal for horizontal blinds where 50% is fully open and as you are aware can cause problems for our implementation.

[tamorgen]

@tamorgen : Maybe I'm misunderstanding the specification. But according to page 159 of the specification https://raw.githubusercontent.com/zwave-js/specs/d6c115ec1c46dd1db9f3dca3fc2106df577fac9c/Z-Wave%20Device%20Class%20Specification.pdf it says:

It is not RECOMMENDED to use this generic device class for new devices. Instead, it is RECOMMENDED to base devices of this category on the Multi-level switch generic device class with the Multi-position Motor specific device class

To me that sounds like ZwaveJS is doing the right thing.

Also, the link you provided does not have a date on it. I googled the same document, and the one's I found have specific dates listed on the first page of the PDF.

https://sdomembers.z-wavealliance.org/document/dl/638

The class starts on page 667 of that document.

[kpine]

@tamorgen : Maybe I'm misunderstanding the specification. But according to page 159 of the specification zwave-js/specs@d6c115e/Z-Wave%20Device%20Class%20Specification.pdf (raw) it says:

You are mixing up Device Types vs. Command Classes. The Window Covering Generic Device Class is discouraged, not the command class. The Window Covering Command Class is alive and well, a requirement for Window Covering Device Type for the Device Type V2 Specification.

Anyways, this is a wish list issue. The WC class is already specifically called out as requested. There's been no statement it would not be implemented. Hit the thumbs up in the comment and wait, or even better, implement it!

[tamorgen]

@tamorgen : Maybe I'm misunderstanding the specification. But according to page 159 of the specification zwave-js/specs@d6c115e/Z-Wave%20Device%20Class%20Specification.pdf (raw) it says:

You are mixing up Device Types vs. Command Classes. The Window Covering Generic Device Class is discouraged, not the command class. The Window Covering Command Class is alive and well, a requirement for Window Covering Device Type for the Device Type V2 Specification.

Anyways, this is a wish list issue. The WC class is already specifically called out as requested. There's been no statement it would not be implemented. Hit the thumbs up in the comment and wait, or even better, implement it!

Thank you for your feedback. I've voted for it.

[AlCalzone]

Receiving MultiCommandCCCommandEncapsulation is supported since v10.10.0

[AlCalzone]

Energy Production CC support is added in #5677

[AlCalzone]

Window Covering CC support is added in #5679

[EkielZan]

Hi, I've a Quby / Engie Meter Adapter See here : https://devices.zwave-js.io/?jumpTo=0x0130:0x0002:0x0001:0.0 or https://github.com/openhab/org.openhab.binding.zwave/blob/main/doc/quby/en00_0_0.md

And I receive this error when trying to get data from it:

The command class Meter Table Monitor is not implemented (ZW0303)