athombv / node-homey-zwavedriver Goto Github PK

Currently, the absence of a settings parser function auto-generates a parser if the settings type is number or boolean, however, some settings require the use of numeric strings (dropdown). Checking if the input is a numeric string, and treating it like a number therefore saves a lot of driver-side redundant code. It also removes the need for developers to split numbers over bytes like this: ((https://github.com/athombv/com.aeotec/blob/19f1074d2a723e3df9aa1bfcaffe6a30d7b92aea/drivers/ZW096/driver.js#L72))

** Software version**
Homey v1.1.9, Fibaro app 1.2.2 (GitHub, patched, Z-wave driver included 1.1.4)

** Issue description**
I noticed that with the current release the Fibaro motion sensors (FGMS-001-PLUS), not always provide the motion detection alarm. Checked the capability definition which seems correct.

I also noticed that, unlike the Neo motion sensors, the Fibaro's don't seem to respond to the Battery_get command initiated from the Z-wavedriver based on the online event (aka getOnWakeUp)...

** Released implementation, 'getOnWakeUp':true in driver.js, GET command by Z-wave driver**

Fibaro app 1.2.2, FGMS-001-PLUS/driver.js:

'measure_battery': {
			'getOnWakeUp': true,
			'command_class': 'COMMAND_CLASS_BATTERY',
			'command_get': 'BATTERY_GET',
			'command_report': 'BATTERY_REPORT',
			'command_report_parser': report => {
				if (report['Battery Level'] === "battery low warning") return 1;
				if (report.hasOwnProperty('Battery Level (Raw)'))
					return report['Battery Level (Raw)'][0];
				return null;
			}
		}

since adding these 2 motion sensors some days ago and while testing (updating multiple settings), I manually wake-up'd these sensors a dozen timed... and battery-levels were not updated..

some debug logging with 'getOnWakeUp': true,

[debug] node.on('online') arguments: { '0': true }
[debug]  COMMAND_CLASS_BATTERY->BATTERY_GET args: {} cb: true
[debug] node.on('applicationUpdate') arguments: { '0': <Buffer 04 07 01 5e 86 72 59 80 73 56 22 31 98 7a> }
[debug] settings() newSettingsObj { motion_sensor_sensitivity: 12,
  ........
  led_indicating_tamper_alarm: false } changedKeysArr [ 'tamper_sensitivity' ]
[debug] CONFIGURATION_SET index: 20 size: 1 newValue <Buffer 14>
[debug] node.on('online') arguments: { '0': false }
[debug] node.on('online') arguments: { '0': true }
[debug]  COMMAND_CLASS_BATTERY->BATTERY_GET args: {} cb: true
[debug] node.CommandClass['COMMAND_CLASS_NOTIFICATION'].on('report') arguments: { '0': { value: 5, name: 'NOTIFICATION_REPORT' },
  '1': 
   { 'V1 Alarm Type (Raw)': <Buffer 00>,
     'V1 Alarm Type': 0,
     'V1 Alarm Level (Raw)': <Buffer 00>,
     'V1 Alarm Level': 0,
     'Reserved (Raw)': <Buffer 00>,
     'Notification Status (Raw)': <Buffer ff>,
     'Notification Status': 'On',
     'Notification Type (Raw)': <Buffer 07>,
     'Notification Type': 'Home Security',
     'Event (Raw)': <Buffer 00>,
     Event: 0,
     'Properties1 (Raw)': <Buffer 01>,
     Properties1: { 'Event Parameters Length': 1, Sequence: false },
     'Event Parameter': <Buffer 03>,
     'Event (Parsed)': 'Event inactive' },
  '2': null }
[debug] node.on('online') arguments: { '0': false }

Here, the following response is provided based on every GET command:
[debug] COMMAND_CLASS_BATTERY->BATTERY_GET args: {} cb: true
So there is a callback, yet no report provided..

Is it possible that this is also blocking other reports from being parsed / received by Homey?

with listener at driver.js

With below listener (used for debugging battery powered devices) added to Fibaro app 1.2.2, FGMS-001-PLUS/driver.js

module.exports.on('initNode', token => {
    const node = module.exports.nodes[token];
		if (node) {
			node.instance.on('online', online => {
				if (online) {
					// Retrieve 'Battery Level' upon wake-up; temp replacement of getOnWakeUp function (triggering on online event instead of Wake-up)
					node.instance.CommandClass['COMMAND_CLASS_BATTERY'].BATTERY_GET({});
					// Option to retrieve the WAKE_UP_INTERVAL_CAPABILITIES upon wake-up; for debugging only
					// node.instance.CommandClass['COMMAND_CLASS_WAKE_UP'].WAKE_UP_INTERVAL_CAPABILITIES_GET({});
					// Option to retrieve the WAKE_UP_INTERVAL upon wake-up; for debugging only
					// node.instance.CommandClass['COMMAND_CLASS_WAKE_UP'].WAKE_UP_INTERVAL_GET({});
					// Option to retrieve configuration of a certain parameter upon wake-up; for debugging only
					// node.instance.CommandClass['COMMAND_CLASS_CONFIGURATION'].CONFIGURATION_GET(
					// 	{ 'Parameter Number': new Buffer([86])
					// 	}, null);
					// node.instance.CommandClass['COMMAND_CLASS_CONFIGURATION'].CONFIGURATION_GET(
					// 	{'Parameter Number': new Buffer([87])
					//	}, null );
					// node.instance.CommandClass['COMMAND_CLASS_CONFIGURATION'].CONFIGURATION_GET(
					//	{'Parameter Number': new Buffer([89])
					//	}, null );
					// node.instance.CommandClass['COMMAND_CLASS_CONFIGURATION'].CONFIGURATION_GET(
					//	{'Parameter Number': new Buffer([86])
					//	}, null );
					// node.instance.CommandClass['COMMAND_CLASS_ZWAVEPLUS_INFO'].ZWAVEPLUS_INFO_GET({});
				}
			}
		);
		}
}
);

With this listener I do get a battery report on every (manual or automatic) wakeup:

[debug] node.on('online') arguments: { '0': true }
[debug] node.on('applicationUpdate') arguments: { '0': <Buffer 04 07 01 5e 86 72 59 80 73 56 22 31 98 7a> }
[debug] node.CommandClass['COMMAND_CLASS_BATTERY'].on('report') arguments: { '0': { value: 3, name: 'BATTERY_REPORT' },
  '1': { 'Battery Level (Raw)': <Buffer 64>, 'Battery Level': {} },
  '2': null }
[debug] node.on('online') arguments: { '0': false }

If further information is required, let me know.

My 2 apps with the updated zwave driver of today all give:

I'm getting a error after updating to the latest zwave lib from github in the app

[5:08]
SyntaxError: Illegal continue statement
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object. (/node_modules/homey-zwavedriver/index.js:3:18)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)

When entering a value, e.g. 123123123 in one of the input fields and trying to commit this value. The Z-wave driver is crashing.

Expected result: No crash of Z-wave driver
Better expected result: Check values before submitting them (the min and max values of this number input had been set, so HTML5 form check before submit would do).

TypeError: value is out of bounds
at checkInt (buffer.js:824:11)
at Buffer.writeIntBE (buffer.js:956:5)
at /node_modules/homey-zwavedriver/lib/ZwaveDriver.js:161:16
at Array.forEach (native)
at ZwaveDriver.settings (/node_modules/homey-zwavedriver/lib/ZwaveDriver.js:134:18)
at /homey-app/manager/drivers.js:1:3459
at ZwaveDriver.drivers.(anonymous function).ready (/homey-app/manager/drivers.js:1:2049)
at eventListeners.clientDriver (/homey-app/manager/drivers.js:1:2416)
at /homey-app/helpers/client.js:1:868
at Array.forEach (native)

--- INFO: com.fibaro has been killed ---

Network Graph doesn't show nodes without device Zone which makes it impossible to distinguish nodes having the same name (eg. each room has a Ceiling Lamp).

When a battery device is offline, battery dead, or broken for some other reason, it would be nice that Homey marks this device as unavailable.

When:

• The app receives an unload signal
• Save the current values to the settings store with a timestamp

When:

• The driver is loaded

And:

• A node is a battery node
• There are persistent settings found
• These settings are less than 30 minutes old

Then:

• Set the capability values to these settings
• Clear the settings

'use strict';

const { ZwaveDevice } = require('homey-zwavedriver'); this was homey meshdriver

class MyZWaveDevice extends ZwaveDevice {

async onNodeInit() {
this.log('MyZWaveDevice has been inited');

}

}

module.exports = MyZWaveDevice;

When you follow the manual to the letter it says:

Installation
cd /path/to/com.your.homeyapp/ git submodule add https://github.com/athombv/node-homey-zwavedriver.git

Example
const ZwaveDriver = require('homey-zwavedriver');

But when you do that the Z-wave driver isn't downloaded to the node_modules sub dir.
So I went ahead and removed the module (git rm node-homey-zwavedriver) and changed to the node_modules directory and fired 'git submodule add https://github.com/athombv/node-homey-zwavedriver.git` once again.
Fired 'athom project --run' which results in:

So I went ahead and renamed the folder from 'node-homey-zwavedriver' to 'homey-zwavedriver' and now my driver works like a charm.

So, to sum up what has to be changed:

1. Change documentation: add a line to cd to node-modules directory
2. Change name of driver to node-homey-zwavedriver or rename repository on Git.

implement node.instance.CommandClass.COMMAND_CLASS_CONFIGURATION.CONFIGURATION_GET
to get config parameters from device in drivers to check the configuration parameters

The standard behavior of a Switch ON action card is to switch ON the device regardless of the state of the device, so it will send a command (and wait for confirmation) before sending the next command...
If you need to switch of 10 devices (of which a number are already off), it will still take some time before all devices are off

I would love an "switch on" / "switch off" action card which would provide the option to "send command anyway" or "switch on when device is off"... will increase responsiveness

This should be possible for Z-wave, since the state of the device Homey knows should match the state of the device... so Homey should not have to retreive first the actual state from the device but use it's own state (recollection) of the device.

Since this is intercepting the SET command, it should be implemented in the Z-wave driver (not in the device driver).

When device wakes up an event is triggered, add functionality that will execute certain set and get commands directly after a device wakes up.

Hi,

I'm currently working on a drive for z-wave based weather station. The "SENSOR_MULTILEVEL" returns 7 type of sensor values:

• Temperature
• Luminance
• Humidity
• Wind speed
• Barometric pressure
• Dew point

Using the "homey-zwavedriver" class I need to return the "Sensor Type" in the capability section for the different sensors returned to "command_get_parser". I was unable to find a complete list of supported "Sensor Type" strings.

Can you please provide me with such a list.

In general it would be very helpful to have a list of values returned to "command_get_parser" for the different command_classes.

Thanks,

Martin

Arguments in a () => will not work, replace by function () {}.bind(this);

    // attach event listeners
                nodeEvents.forEach((nodeEvent) => {
                    zwaveNode.on(nodeEvent, () => {
                        this._debug(`node.on('${nodeEvent}')`, 'arguments:', arguments);
                    });
                });

                Object.keys(zwaveNode.CommandClass).forEach(commandClassId => {
                    zwaveNode.CommandClass[commandClassId].on('report', () => {
                        this._debug(`node.CommandClass['${commandClassId}'].on('report')`, 'arguments:', arguments);
                    });
                });

                if (zwaveNode.MultiChannelNodes) {
                    Object.keys(zwaveNode.MultiChannelNodes).forEach(multiChannelNodeId => {
                        Object.keys(zwaveNode.MultiChannelNodes[multiChannelNodeId].CommandClass).forEach(commandClassId => {
                            zwaveNode.MultiChannelNodes[multiChannelNodeId].CommandClass[commandClassId].on('report', () => {
                                this._debug(`node.MultiChannelNodes['${multiChannelNodeId}'].
                                CommandClass['${commandClassId}'].on('report')`, 'arguments:', arguments);
                            });
                        });
                    });
}

I'm trying to add Homey as a secondary controller to my Homeseer setup.
Unfortunately it fails on a security negotiation.
Is this feature currently not active in Homey fimware 0.9.3?
I succesfully included a vera edge and a domoticz server to my Homeseer as a secondary controller and i can see my z-wave device in there interfaces.
But with Homey I can't see any devices created. And i can't manually add them.
Did someone manage to get this working?

this works which i found in the fibraro app node modules homey zwave driver read.me

why not mentioned in this read.me ?

cd /path/to/com.your.homeyapp/
npm install --save https://github.com/athombv/node-homey-zwavedriver

Result in driver for Fibaro Smoke alarm and Fibaro C)2 alar.
Result in driver for CO sensor and Smoke sensor give null assignment back to driver .
the other capabilities are OK.
On drive page I see (-) for temperature alarm. The other CO or Smoke alarm has the right "on/off" assignment.

Error: Cannot find module 'async'
at Function.Module._resolveFilename (module.js:325:15)
at Function.Module._load (module.js:276:25)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object. (/node_modules/homey-zwavedriver/lib/ZwaveDriver.js:5:15)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)

Time-out error trying to get data from channels. The code did work several weeks ago.

Code used:
measure_power: { multiChannelNodeId: 1, command_class: 'COMMAND_CLASS_METER', command_get: 'METER_SUPPORTED_GET', command_report: 'METER_SUPPORTED_REPORT', },

New debug log:
[debug] 1 COMMAND_CLASS_METER METER_SUPPORTED_GET args: {} err: { [Error: timeout] message: 'timeout' } result: null

Old debug log same code:
[debug] 1 COMMAND_CLASS_METER METER_SUPPORTED_GET args: { Properties1: { 'Rate Type': '3', Scale: 0 }, 'Scale 2': 0 } err: null result: { 'Properties1 (Raw)': <Buffer 61>, Properties1: { 'Meter Reset': false, 'Meter Type': 'Electric meter', 'Rate Type': 'Import and Export' }, 'Properties2 (Raw)': <Buffer 05>, Properties2: { 'Scale Supported 0': 5, 'M.S.T': false } }

It seems the driver only supports up to METER command class V4. I'm supposed to integrate some new Shelly Zwave device that use METER command class V6 which is returning errors when doing this.registerCapability('meter_power', 'METER'); and this.registerCapability('measure_power', 'METER');

The errors are:

2023-07-26T18:07:04.756Z [err] [ManagerDrivers] [Driver:shelly_wave_1pm] [Device:8e8f8f94-054d-46f1-9c30-7743e777e1fa] Error: capability get command failed {
  capabilityId: 'meter_power',
  commandClassId: 'METER',
  parsedPayload: { Properties1: { 'Rate Type': 'Import', Scale: 0 }, 'Scale 2': 0 }
} TypeError [ERR_INVALID_ARG_TYPE]: The "byteLength" argument must be of type number. Received undefined
    at new NodeError (node:internal/errors:399:5)
    at validateNumber (node:internal/validators:178:11)
    at boundsError (node:internal/buffer:81:5)
    at Buffer.readIntBE (node:internal/buffer:447:3)
    at module.exports (/app/node_modules/homey-zwavedriver/lib/system/commandclasses/METER/index.js:65:50)
    at METER (/app/node_modules/homey-zwavedriver/lib/ZwaveDevice.js:10:61)
    at ShellyZwaveDevice._parseCommandClassPayload (/app/node_modules/homey-zwavedriver/lib/ZwaveDevice.js:615:24)
    at ShellyZwaveDevice._onReport (/app/node_modules/homey-zwavedriver/lib/ZwaveDevice.js:588:44)
    at ShellyZwaveDevice._getCapabilityValue (/app/node_modules/homey-zwavedriver/lib/ZwaveDevice.js:446:27)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'ERR_INVALID_ARG_TYPE'
}

2023-07-29T18:25:01.373Z [err] [ManagerDrivers] [Driver:shelly_wave_1pm] [Device:8e8f8f94-054d-46f1-9c30-7743e777e1fa] Could not get capability value for capabilityId: meter_power TypeError [ERR_INVALID_ARG_TYPE]: The "byteLength" argument must be of type number. Received undefined
    at new NodeError (node:internal/errors:399:5)
    at validateNumber (node:internal/validators:178:11)
    at boundsError (node:internal/buffer:81:5)
    at Buffer.readIntBE (node:internal/buffer:447:3)
    at module.exports (/app/node_modules/homey-zwavedriver/lib/system/commandclasses/METER/index.js:65:50)
    at METER (/app/node_modules/homey-zwavedriver/lib/ZwaveDevice.js:10:61)
    at ShellyWave1PMDevice._parseCommandClassPayload (/app/node_modules/homey-zwavedriver/lib/ZwaveDevice.js:615:24)
    at ShellyWave1PMDevice._onReport (/app/node_modules/homey-zwavedriver/lib/ZwaveDevice.js:588:44)
    at ShellyWave1PMDevice._getCapabilityValue (/app/node_modules/homey-zwavedriver/lib/ZwaveDevice.js:446:27)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'ERR_INVALID_ARG_TYPE'
}

The device is documented here: https://kb.shelly.cloud/knowledge-base/wave-1pm

Now it is not possible to include the temperature sensors (DS18B20) to:

• Door/Window Sensor (FGK-101, FGK-10X);
• Universal Binary Sensor (FGBS-001);

These temperature sensor(s) will be added as endpoint(s), so need to be defined.
But this is impossible now because every endpoint noted in the JSON are being added.
And thus causes a fail in the inclusion when not attached to the Sensor's.

So there should be a check in the inclusion if the endpoint is there, if not, it will pass this endpoint and move on to the next step.

The current problem with Homey Z-Wave Driver is that there are devices that have for example 2 multi channels using the capability 'onoff', but one multichannel uses a different command class or method for reporting this.

Concrete example, me.zwave -> Double Switch (05461). You want to add this device as two separate devices as it has two separate switches that switch different outputs.

Two multi channels:

• MultiChannel Node 1 -> capability 'onoff': reports using COMMAND_CLASS_BINARY_SWITCH about the current state of the switch.
• MultiChannel Node 2 -> capability 'onoff': reports using COMMAND_CLASS_BASIC with a BASIC_SET command about the current state of the switch.

Currently this can not be implemented. A suggested solution is to add a multiChannelNodes object to the drivers of z-wave devices in which for each multi channel the capabilities can be defined (differently from each other if necessary). This would result in one devices added for each multi channel that can use different command classes for the same capability.

Example:

module.exports = new ZwaveDriver(path.basename(__dirname), {
    debug: true,
    multiChannelNodes: {
        '1': {
            capabilities: {
                onoff: {
                    command_class: 'COMMAND_CLASS_SWITCH_BINARY',
                    command_get: 'SWITCH_BINARY_GET',
                    command_set: 'SWITCH_BINARY_SET',
                    command_set_parser: value => {
                    },
                    command_report: 'SWITCH_BINARY_REPORT',
                    command_report_parser: report => {
                    }
                }
            }
        },
        '2': {
            capabilities: {
                onoff: {
                    command_class: 'COMMAND_CLASS_BASIC',
                    command_get: 'BASIC_GET',
                    command_set: 'BASIC_SET',
                    command_set_parser: value => {
                    },
                    command_report: 'BASIC_REPORT',
                    command_report_parser: report => {
                    }
                }
            }
        }
    },
    capabilities: {
        onoff: {
            command_class: 'COMMAND_CLASS_SWITCH_BINARY',
            command_get: 'SWITCH_BINARY_GET',
            command_set: 'SWITCH_BINARY_SET',
            command_set_parser: value => {
            },
            command_report: 'SWITCH_BINARY_REPORT',
            command_report_parser: report => {
            }
        }
    },
    settings: {

    }
})

NOTE: This might be necessary of the me.zwave -> Double Switch (05461), but just used as an example. For now there are ways to work around this, but it might be clearer if implemented as proposed above.

I couldn't find any support for the COMMAND_CLASS_ENTRY_CONTROL. This class is for instance used in the BeNext Tag Reader 500. I'm trying to implement this device with advanced control (they call it "Gateway Mode"). But therefore I need the COMMAND_CLASS_ENTRY_CONTROL to be supported. If this class is implemented the Tag Reader 500 can:

• Control the UserIds belonging to the tags (this makes it possible to control the userids by Homey and then use multiple tag readers with the same tags).
• Toggle scenes (flows) with the tag reader by pressing 1,2,3 enter or other 'scene numbers' on the tag reader.
• Make Homey control the alarm (when able to 'arm' the home and when not) and give this as feedback to the Tag Reader by letting the light blink green or red.

It would be cool to implement this class as many Homey users have this device, and probably also other devices use this class for advanced control of security systems.

Tag Reader manual: http://www.benext.eu/static/manual/tagreader500.pdf (page 3 'Gateway Mode')
COMMAND_CLASS_ENTRY_CONTROL: http://z-wave.sigmadesigns.com/wp-content/uploads/2016/08/SDS12657-12-Z-Wave-Command-Class-Specification-A-M.pdf (page 244).

For some unknown reason the nodes in the Network Graph keep switching positions which makes it look like a (very busy) bees hive.

Homey 1.1.4 / zwavedriver 1.1.4

While debugging the battery update (getOnWakeUp) function, I typically set the wakeup interval on a relative low (yet still acceptable) level. Around 300 or 600 seconds to see that the automatic interval is also working...

After upgrading the Homey 1.1.4 (and Z-wave driver 1.1.4), I am no longer able to change it to this value... no response.

From @caseda I understood that in this version, some changes / restrictions have been implemented for the wakeup interval (min, max and step size), although I cannot find it in the documentation nor in the settings card of the devices (additional hint connected to this interval), or active validation (and response) of this value (similar to other settings).

Device capabilities:

[debug] node.CommandClass['COMMAND_CLASS_WAKE_UP'].on('report') arguments: { '0': { value: 10, name: 'WAKE_UP_INTERVAL_CAPABILITIES_REPORT' },
  '1': 
   { 'Minimum Wake Up Interval Seconds (Raw)': <Buffer 00 01 2c>,
     'Minimum Wake Up Interval Seconds': 300,
     'Maximum Wake Up Interval Seconds (Raw)': <Buffer ff ff f0>,
     'Maximum Wake Up Interval Seconds': 16777200,
     'Default Wake Up Interval Seconds (Raw)': <Buffer 00 a8 c0>,
     'Default Wake Up Interval Seconds': 43200,
     'Wake Up Interval Step Seconds (Raw)': <Buffer 00 00 3c>,
     'Wake Up Interval Step Seconds': 60 },
  '2': null }

Setting it to 300 and 360 seconds should be possible.

After setting the wakeup interval to 300 seconds (and proper update procedure, ie. when the device is online), the device still reports the app default value of 21600 seconds (aka not updated):

[debug] node.CommandClass['COMMAND_CLASS_WAKE_UP'].on('report') arguments: { '0': { value: 6, name: 'WAKE_UP_INTERVAL_REPORT' },
  '1': 
   { 'Seconds (Raw)': <Buffer 00 54 60>,
     Seconds: 21600,
     'NodeID (Raw)': <Buffer 01>,
     NodeID: 1 },
  '2': null }

Tried several times, on 300 and 360, with same response.
Tried on 3600 seconds as interval (same procedure):

[debug] node.CommandClass['COMMAND_CLASS_WAKE_UP'].on('report') arguments: { '0': { value: 6, name: 'WAKE_UP_INTERVAL_REPORT' },
  '1': 
   { 'Seconds (Raw)': <Buffer 00 0e 10>,
     Seconds: 3600,
     'NodeID (Raw)': <Buffer 01>,
     NodeID: 1 },
  '2': null }

Tried on 7200 seconds as interval (same procedure):

[debug] node.CommandClass['COMMAND_CLASS_WAKE_UP'].on('report') arguments: { '0': { value: 6, name: 'WAKE_UP_INTERVAL_REPORT' },
  '1': 
   { 'Seconds (Raw)': <Buffer 00 1c 20>,
     Seconds: 7200,
     'NodeID (Raw)': <Buffer 01>,
     NodeID: 1 },
  '2': null }

So it appear that there is a different minimum level than specified by the devices capabilities.

Questions I have:

1. What is the mechanism behind the limitations of the wakeup interval; is this based on the device capabilities of are other non-device specific limits introduced?
2. Please update the documentation accordingly.
3. Is it possible to add these limitation to the device settings card, similar to other Z-wave parameters (validation) and the association groups (amount of devices to be added and possibility to add additional hint, app specific)

In the case of the MCO MH-S411, MH-S412, MH-S314 switches, the LED backlight cannot be adjusted, there is no such adjustment option. (The MH-C421 has such a menu item.) Can this be solved through the MCO application or in some other way? Can this setting be included in the MCO application, as in the case of the MH-C421? According to the attached description, it is parameter 4. Thanks in advance!
MH-S411.pdf