Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Innr RB185 C turns off at brightness: 1 #4035

Closed
ghost opened this issue Aug 4, 2020 · 16 comments
Closed

Innr RB185 C turns off at brightness: 1 #4035

ghost opened this issue Aug 4, 2020 · 16 comments

Comments

@ghost
Copy link

ghost commented Aug 4, 2020

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?

{
  "state": "ON",
  "linkquality": 89,
  "brightness": 1,
  "color_temp": 164,
  "color": {
    "x": 0.323,
    "y": 0.329
  }
}

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"

Koenkk added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue Aug 5, 2020
Koenkk added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue Aug 5, 2020
@Koenkk
Copy link
Owner

Koenkk commented Aug 5, 2020

Should be fixed now, when brightness 1 is set for this bulb, it will automatically be converter to 0 (since that is off).

@ghost
Copy link
Author

ghost commented Aug 5, 2020

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

@sjorge
Copy link
Sponsor Contributor

sjorge commented Aug 5, 2020

@Koenkk i think the E14 Innr variants are also effected by this. I can test tomorrow if you want.

@ghost
Copy link
Author

ghost commented Aug 6, 2020

@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}}'

@ghost
Copy link
Author

ghost commented Aug 6, 2020

Also, my new RB265 just arrived, and they need the same patch as well. Looks to be common innr behaviour?

@sjorge
Copy link
Sponsor Contributor

sjorge commented Aug 6, 2020

I just tested with:

  • RB 250 C
  • RB 285 C

And they both require the same fix, so it does indeed look to be common for all Innr bulbs

Koenkk added a commit to Koenkk/zigbee-herdsman that referenced this issue Aug 8, 2020
@Koenkk
Copy link
Owner

Koenkk commented Aug 8, 2020

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 Koenkk/zigbee-herdsman-converters#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.

@ghost
Copy link
Author

ghost commented Aug 8, 2020

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)

Koenkk added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue Aug 9, 2020
@Koenkk
Copy link
Owner

Koenkk commented Aug 9, 2020

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)

@ghost
Copy link
Author

ghost commented Aug 9, 2020

@Koenkk as me and @sjorge noticed there's more innr bulbs that behave this way. Does this cover all of them?

@Koenkk
Copy link
Owner

Koenkk commented Aug 9, 2020

@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 added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue Aug 10, 2020
@ghost
Copy link
Author

ghost commented Aug 11, 2020

@Koenkk just tested it, works as intended, you can include the rest of innr bulbs as well

@Koenkk
Copy link
Owner

Koenkk commented Aug 12, 2020

Added it for all (and also applyRedFix). Assuming this can be closed now.

@Koenkk Koenkk closed this as completed Aug 12, 2020
@ghost
Copy link
Author

ghost commented Aug 14, 2020

@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

@dzungpv
Copy link
Contributor

dzungpv commented Aug 14, 2020

@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

@Koenkk
Copy link
Owner

Koenkk commented Aug 14, 2020

I've tested the following with an Innr, IKEA and Hue bulb:

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants