Closed ghost closed 3 years ago
Should be fixed now, when brightness 1 is set for this bulb, it will automatically be converter to 0 (since that is off).
Is this the correct way to do this? I noticed that you cap off brightness at 254 as well instead of 255 like in hue, and I'm wondering just how does the protocol handle these things
@Koenkk i think the E14 Innr variants are also effected by this. I can test tomorrow if you want.
@Koenkk just tried it out. It works for a single bulb, but not for a group that consists of these bulbs
Zigbee2MQTT:debug 2020-08-06 09:23:28: Received MQTT message on 'zigbee2mqtt/Bedroom/set' with data '{"brightness": 50}'
Zigbee2MQTT:debug 2020-08-06 09:23:28: Publishing 'set' 'brightness' to 'Bedroom'
Zigbee2MQTT:info 2020-08-06 09:23:28: MQTT publish: topic 'zigbee2mqtt/Bedroom 1', payload '{"state":"ON","linkquality":84,"brightness":50,"color_temp":370,"color":{"x":0.459857791746717,"y":0.410598847355503}}'
Zigbee2MQTT:info 2020-08-06 09:23:28: MQTT publish: topic 'zigbee2mqtt/Bedroom', payload '{"state":"ON","brightness":50,"color_temp":370,"color":{"x":0.459857791746717,"y":0.410598847355503}}'
Zigbee2MQTT:info 2020-08-06 09:23:28: MQTT publish: topic 'zigbee2mqtt/Bedroom 3', payload '{"state":"ON","brightness":50,"color_temp":370,"color":{"x":0.459857791746717,"y":0.410598847355503}}'
Zigbee2MQTT:info 2020-08-06 09:23:28: MQTT publish: topic 'zigbee2mqtt/Bedroom 2', payload '{"state":"ON","brightness":50,"color_temp":370,"color":{"x":0.459857791746717,"y":0.410598847355503}}'
Zigbee2MQTT:debug 2020-08-06 09:23:36: Received MQTT message on 'zigbee2mqtt/Bedroom/set' with data '{"brightness": 1}'
Zigbee2MQTT:debug 2020-08-06 09:23:36: Publishing 'set' 'brightness' to 'Bedroom'
Zigbee2MQTT:info 2020-08-06 09:23:36: MQTT publish: topic 'zigbee2mqtt/Bedroom 1', payload '{"state":"ON","linkquality":84,"brightness":1,"color_temp":370,"color":{"x":0.459857791746717,"y":0.410598847355503}}'
Zigbee2MQTT:info 2020-08-06 09:23:36: MQTT publish: topic 'zigbee2mqtt/Bedroom', payload '{"state":"ON","brightness":1,"color_temp":370,"color":{"x":0.459857791746717,"y":0.410598847355503}}'
Zigbee2MQTT:info 2020-08-06 09:23:36: MQTT publish: topic 'zigbee2mqtt/Bedroom 3', payload '{"state":"ON","brightness":1,"color_temp":370,"color":{"x":0.459857791746717,"y":0.410598847355503}}'
Zigbee2MQTT:info 2020-08-06 09:23:36: MQTT publish: topic 'zigbee2mqtt/Bedroom 2', payload '{"state":"ON","brightness":1,"color_temp":370,"color":{"x":0.459857791746717,"y":0.410598847355503}}'
Also, my new RB265 just arrived, and they need the same patch as well. Looks to be common innr behaviour?
I just tested with:
And they both require the same fix, so it does indeed look to be common for all Innr bulbs
Is this the correct way to do this? I noticed that you cap off brightness at 254 as well instead of 255 like in hue, and I'm wondering just how does the protocol handle these things
According to the ZCL (https://github.com/Koenkk/zigbee-herdsman/blob/master/docs/Zigbee%20Cluster%20Library%20Specification%20v7.pdf 3.10.2.2) 0xFF (255) is a reserved value which means the default value. Therefore 254 is the max possible brightness. Addressed in https://github.com/Koenkk/zigbee-herdsman-converters/pull/1200 , however reading this again now makes me wonder if this is correct as the max/minLevel can differ per bulb @dzungpv. It seems that be default the min level is 0x00 (0) and max level is 0xFF (255) so the change seems to be not correct.
We can try reading the maxLevel
/minLevel
for both the IKEA and Innr bulb and see if there is a difference.
First update to the latest dev branch and try changing the definition in devices.js
to:
{
zigbeeModel: ['RB 185 C'],
model: 'RB 185 C',
vendor: 'Innr',
description: 'E27 bulb RGBW',
extend: generic.light_onoff_brightness_colortemp_colorxy,
meta: {applyRedFix: true, turnsOffAtBrightness1: true},
onEvent: async (type, data, device) => {
if (type === 'start') {
const endpoint = device.endpoints[0];
const result = await endpoint.read('genLevelCtrl', ['minLevel', 'maxLevel']);
console.log('\n\n\n\n' + 'minlevel/maxlevel' + result + '\n\n\n\n');
}
},
},
You should see the logging on z2m startup.
I think there's something wrong here. I added this to a tradfri bulb as well, and the result is the same (kitchen is ikea, bedroom is innr)
Zigbee2MQTT:debug 2020-08-08 22:27:50: Received Zigbee message from 'Kitchen light', type 'readResponse', cluster 'genLevelCtrl', data '{}' from endpoint 1 with groupID 0
Zigbee2MQTT:error 2020-08-08 22:27:50: Not connected to MQTT server!
Zigbee2MQTT:error 2020-08-08 22:27:50: Cannot send message: topic: 'zigbee2mqtt/Kitchen light/availability', payload: 'online
(node:16) UnhandledPromiseRejectionWarning: Error: Read 0x000b57fffedbd90c/1 genLevelCtrl(["minLevel","maxLevel"], {"timeout":10000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
at Endpoint.checkStatus (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:140:23)
at Endpoint.<anonymous> (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:195:26)
at Generator.next (<anonymous>)
at fulfilled (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:24:58)
(node:16) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:16) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Zigbee2MQTT:debug 2020-08-08 22:27:50: Received Zigbee message from 'Bedroom 1', type 'readResponse', cluster 'genLevelCtrl', data '{}' from endpoint 1 with groupID 0
Zigbee2MQTT:error 2020-08-08 22:27:50: Not connected to MQTT server!
Zigbee2MQTT:error 2020-08-08 22:27:50: Cannot send message: topic: 'zigbee2mqtt/Bedroom 1/availability', payload: 'online
(node:16) UnhandledPromiseRejectionWarning: Error: Read 0x00158d0001972279/1 genLevelCtrl(["minLevel","maxLevel"], {"timeout":10000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
at Endpoint.checkStatus (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:140:23)
at Endpoint.<anonymous> (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:195:26)
at Generator.next (<anonymous>)
at fulfilled (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:24:58)
(node:16) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
It seems that the devices don't support this attribute (which is fine according to the ZCL as it's optional). It also means that we have no way of knowing the min brightness except trying.
I've fixed the issue where it was not applied for groups, this will now be done when at least one of the devices in it is a RB185 C.
Changes will be available in the latest dev branch in a few hours (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html)
@Koenkk as me and @sjorge noticed there's more innr bulbs that behave this way. Does this cover all of them?
@elfhack not yet, lets first see if it works for this, changes are available in dev branch in 30 mins from now so please test
@Koenkk just tested it, works as intended, you can include the rest of innr bulbs as well
Added it for all (and also applyRedFix
). Assuming this can be closed now.
@Koenkk Well this is awkward. My Bedroom group which is comprised of RB185C work as expected, but my living room group comprised of RB265s still exhibit the bug. Yet I see you've patched all of them. Any ideas? I'm running on 1.14.3-dev now
Edit: scratch that, I had the test version of devices.js mounted in kubernetes from earlier tests. Works perfectly
@Koenkk right, in z-stack it define in Common\zcl\zcl_general.h:
#define ATTR_LEVEL_MAX_LEVEL 0xFE // MAX level
#define ATTR_LEVEL_MIN_LEVEL 0x01 // MIN level
So it is 1 to 254, not 255
I've tested the following with an Innr, IKEA and Hue bulb:
brightness = Math.min(255, brightness);
All bulbs returned 254 as the currentLevel
:
Zigbee2MQTT:debug 2020-08-14 11:08:55: Received MQTT message on 'zigbee2mqtt/0x0017880104c9cd33/set' with data '{"brightness": 255}'
Zigbee2MQTT:debug 2020-08-14 11:08:55: Publishing 'set' 'brightness' to '0x0017880104c9cd33'
Zigbee2MQTT:info 2020-08-14 11:08:55: MQTT publish: topic 'zigbee2mqtt/0x0017880104c9cd33', payload '{"brightness":255,"state":"ON"}'
Zigbee2MQTT:debug 2020-08-14 11:08:55: Mocking 'update_available' value for Home Assistant
Zigbee2MQTT:info 2020-08-14 11:08:55: MQTT publish: topic 'zigbee2mqtt/0x0017880104c9cd33', payload '{"brightness":255,"state":"ON","update_available":false}'
Zigbee2MQTT:debug 2020-08-14 11:08:59: Received MQTT message on 'zigbee2mqtt/0x0017880104c9cd33/get' with data '{"brightness": 255}'
Zigbee2MQTT:debug 2020-08-14 11:08:59: Publishing get 'get' 'brightness' to '0x0017880104c9cd33'
Zigbee2MQTT:debug 2020-08-14 11:08:59: Received Zigbee message from '0x0017880104c9cd33', type 'readResponse', cluster 'genLevelCtrl', data '{"currentLevel":254}' from endpoint 11 with groupID 0
So you are right indeed @dzungpv , thanks!
Bug Report
What happened
setting brightness: 1 for this bulb turns it off, but it still has state: On. This does not happen with my tradfri bulbs, so I'm guessing there's a problem here?
What did you expect to happen
How to reproduce it (minimal and precise)
Debug Info
Zigbee2mqtt version: latest-dev commit 35be951 Adapter hardware: CC2531 Adapter firmware version: "commit": "35be951"