Koenkk
NodOn SIN-4-RS-20 - Expected one of: 0, 2, got: '8'
What happened?
Since the update of the NodOn SIN-4-RS-20 module, the module returns {"windowCoveringMode":8}, which is apparently not supported by the current integration.
What did you expect to happen?
No response
How to reproduce it (minimal and precise)
No response
Zigbee2MQTT version
1.37.1
Adapter firmware version
6.10.3.0 build 297
Adapter
EFR32MG21
Setup
Home Assistant OS
Debug log
[2024-05-21 18:59:34] debug: z2m: Received Zigbee message from 'Large Shutter', type 'readResponse', cluster 'closuresWindowCovering', data '{"windowCoveringMode":8}' from endpoint 1 with groupID 0 [2024-05-21 18:59:34] error: z2m: Exception while calling fromZigbee converter: Expected one of: 0, 2, got: '8'} [2024-05-21 18:59:34] debug: z2m: Error: Expected one of: 0, 2, got: '8' at getFromLookupByValue (/app/node_modules/zigbee-herdsman-converters/src/lib/utils.ts:593:15) at Object.convert (/app/node_modules/zigbee-herdsman-converters/src/lib/modernExtend.ts:1524:64) at Receive.onDeviceMessage (/app/lib/extension/receive.ts:153:51) at EventEmitter.wrappedCallback (/app/lib/eventBus.ts:174:17)
rollerShutterCalibration: (args?: Partial<EnumLookupArgs>) => enumLookup({
name: 'calibration',
lookup: {'stop': 0, 'start': 2},
cluster: 'closuresWindowCovering',
attribute: 'windowCoveringMode',
access: 'ALL',
description: 'Automatic calibration of the roller shutter.',
}),
So actually, only 2 modes are configured for the windowCoveringMode attribute in the device definition.
Do you have any documentation on what additional values could look like, or what they mean ? actually, 0 == stop and 2 == start... Maybe you could find some hint in the documentation of the product ? If 8 is a possible value, we need to know what it means for.
Update: looking at the ZCL specs, it looks like the attribute is not properly implemented.
So in your case @AlbanDurrheimer , it means that the LED options are activated (the value 8 refers to the 4th bit). Makes sense ?
The only LED on this module is the status LED, and I doubt it can be controlled (I don't see the point).
This is just part of the Zigbee standard specification : so i guess the capability has been implemented to turn on/off the led. And this is the case since you got the value 8 when it got requested its value. So that seems legit : however the current zhc device definition didn't mapped it, and this is why you have an error. Maybe only the calibration bit appeared useful by the author, and the other cases were not done.
Could you create the issue here instead actually : https://github.com/Koenkk/zigbee-herdsman-converters/issues ? That is the proper lib to fix the situation.
