There are five threads discussing an inability to change LED color, but all of these pertain to specific controllers (e.g., Hubitat, SmartThings, etc.). I’m trying to change my LZW31-SN LED color via ZwaveJS2MQTT. Via the logging console, I see that the command is sent out:
2021-02-02 04:28:34.620 INFO APP: Zwave api call: writeValue [ { nodeId: 13, commandClass: 112, property: 13 }, 179, [length]: 2 ]
2021-02-02 04:28:34.620 INFO ZWAVE: Writing 179 to 13-112-0-13
2021-02-02 04:28:34.687 INFO ZWAVE: Success zwave api call writeValue
2021-02-02 04:28:34.840 INFO ZWAVE: Node 13: value updated: 112-0-13 170 => 170
But, the response indicates that the value did not take. When I check the LED, it is still blue. However, I also have a LZW30-SN. When I change the color of the LED on that switch, it changes fine as indicated by the logs:
2021-02-02 04:28:26.704 INFO APP: Zwave api call: writeValue [ { nodeId: 12, commandClass: 112, property: 5 }, 179, [length]: 2 ]
2021-02-02 04:28:26.704 INFO ZWAVE: Writing 179 to 12-112-0-5
2021-02-02 04:28:26.739 INFO ZWAVE: Success zwave api call writeValue
2021-02-02 04:28:26.781 INFO ZWAVE: Node 12: value updated: 112-0-5 170 => 179
Since the LZW30-SN responds just fine, it’s not a gateway or hub issue. I can’t figure out why the LZW31-SN is not responding. It’s running version 1.48 of the firmware.
Pretty sure I’m writing to the correct parameter. It’s listed as parameter 13 for the LZW31-SN (node 13 in my network). If you see the debug log from zwavejs2mqtt, you’ll see that it’s attempting to write a new value of 179 to node 13, parameter 13. The controller reports a success in writing the value. However, node 13 then reports that the value has been updated from 170 to 170! So, the value is simply not taking (I can confirm by looking at the LED that the new value is not taking). Here’s the relevant information from the debug log:
2021-02-02 04:28:34.620 INFO APP: Zwave api call: writeValue [ { nodeId: 13, commandClass: 112, property: 13 }, 179, [length]: 2 ]
2021-02-02 04:28:34.620 INFO ZWAVE: Writing 179 to 13-112-0-13
2021-02-02 04:28:34.687 INFO ZWAVE: Success zwave api call writeValue
2021-02-02 04:28:34.840 INFO ZWAVE: Node 13: value updated: 112-0-13 170 => 170
Just about any other parameter on the LZW31-SN that I change seems to take. It’s the LED parameters that appear to be getting rejected.
Good question. I tested using the ZwaveJS config GUI which doesn’t use a MQTT broker (it interfaces directly with the Zwave library). Still shows the same problem (LED won’t change color).
Right now all symptoms point to the switch being an issue. I have a support ticket out with Inovelli, but they haven’t responded yet. In general, the switch is functional. I just want to make sure that the LED component is working as that’s critical for my plans for the switch.
Problem solved. For some reason Inovelli support seems to think that this value should be a 1 byte string. However, if you look at the OpenZwave XML config file for this device, it clearly states it should be 2 bytes. After merging a bugfix into the node-zwave-js repository to send a 2-byte string, the LED color now changes (Should valueSize for parameter 13 of LZW31-SN be 2? · Issue #1581 · zwave-js/node-zwave-js · GitHub).
I am having this same issue with the LZW31-SN switches. How do I access the XML config file to determine if the value is to “2” or “1”? I updated the firmware on the switch and still no LED color change. I’ve had these for over a year now and I’m wondering if there is something I need to change somewhere. I have a hubitat hub and all the settings from the device menu don’t work. Thanks in advance.
I have the *Type set to “Inovelli Z-Wave Smart Scene Dimmer S2” I can change the “Indicator Level When Off %” And the when on % and see immediate results at switch in my office, when I save changes. The only thing that won’t change is the colors of the LED indicators. Do you know if this fix is required to make it work?:
I’m having the same problem. Everything was working fine until this morning when I noticed the LEDs weren’t changing based on a script I ran in Home Assistant. Manually setting the values via ZwaveJS2MQTT had the same behavior that @bburan shared at the beginning.
I restored a backup from Friday and I was able to successfully change the LEDs, so it seems that a change from then til now has caused an issue. Since then, I’ve made the following changes to my system:
Upgraded Home Assistant Core from 2022.2.6 to 2022.2.9
Added 2 inovelli red’s to my network (note that I cannot change the LEDs on any of the switches currently)
Here are logs from manually trying to change the color via Home Assistant Z-wave JS control panel for the switch:
2022-02-21 16:50:42.643 INFO ZWAVE: Calling api writeValue with args: [
{ nodeId: 3, commandClass: 112, endpoint: 0, property: 13 },
170,
{},
[length]: 3
]
2022-02-21 16:50:42.646 INFO ZWAVE: Writing 170 to 3-112-0-13
2022-02-21T21:50:42.663Z SERIAL » 0x010c0013030570040d01aa252c3d (14 bytes)
2022-02-21T21:50:42.667Z DRIVER » [Node 003] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 44
└─[ConfigurationCCSet]
parameter #: 13
reset to default: false
value size: 1
value format: UnsignedInteger
value: 170
2022-02-21T21:50:42.671Z SERIAL « [ACK] (0x06)
2022-02-21T21:50:42.676Z SERIAL « 0x0104011301e8 (6 bytes)
2022-02-21T21:50:42.678Z SERIAL » [ACK] (0x06)
2022-02-21T21:50:42.679Z DRIVER « [RES] [SendData]
was sent: true
2022-02-21T21:50:42.698Z SERIAL « 0x010700132c000003c4 (9 bytes)
2022-02-21T21:50:42.699Z SERIAL » [ACK] (0x06)
2022-02-21T21:50:42.700Z DRIVER « [REQ] [SendData]
callback id: 44
transmit status: OK
2022-02-21 16:50:42.707 INFO ZWAVE: Node 3: value updated: 112-0-13 21 => 170
2022-02-21 16:50:42.708 INFO ZWAVE: Success zwave api call writeValue true
2022-02-21T21:50:43.713Z SERIAL » 0x010a0013030370050d252d96 (12 bytes)
2022-02-21T21:50:43.714Z DRIVER » [Node 003] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 45
└─[ConfigurationCCGet]
parameter #: 13
2022-02-21T21:50:43.716Z SERIAL « [ACK] (0x06)
2022-02-21T21:50:43.722Z SERIAL « 0x0104011301e8 (6 bytes)
2022-02-21T21:50:43.724Z SERIAL » [ACK] (0x06)
2022-02-21T21:50:43.725Z DRIVER « [RES] [SendData]
was sent: true
2022-02-21T21:50:43.768Z SERIAL « 0x010700132d000005c3 (9 bytes)
2022-02-21T21:50:43.769Z SERIAL » [ACK] (0x06)
2022-02-21T21:50:43.770Z DRIVER « [REQ] [SendData]
callback id: 45
transmit status: OK
2022-02-21T21:50:43.789Z SERIAL « 0x010c000400030670060d0200159e (14 bytes)
2022-02-21T21:50:43.791Z CNTRLR [Node 003] [~] [Configuration] 13: 170 => 21
2022-02-21 16:50:43.792 INFO ZWAVE: Node 3: value updated: 112-0-13 170 => 21
2022-02-21T21:50:43.793Z SERIAL » [ACK] (0x06)
2022-02-21T21:50:43.795Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
└─[ConfigurationCCReport]
parameter #: 13
value size: 2
value: 21
2022-02-21T21:50:45.836Z SERIAL « 0x01100004000a0a320221320000003c0000f4 (18 bytes)
2022-02-21T21:50:45.837Z CNTRLR [Node 010] [~] [Meter] value[66049]: 0 => 0 [Endpoint 0]
2022-02-21 16:50:45.838 INFO ZWAVE: Node 10: value updated: 50-0-value-66049 0 => 0
2022-02-21T21:50:45.840Z SERIAL » [ACK] (0x06)
2022-02-21T21:50:45.843Z DRIVER « [Node 010] [REQ] [ApplicationCommand]
└─[MeterCCReport]
type: Electric
scale: W
rate type: Consumed
value: 0
time delta: 60 seconds
prev. value: 0
It looks like Home Assistant is sending the parameter with a size of 1, but the size should be 2. That is the problem, but I’m not sure why HA is doing that.
