-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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
|
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 |
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 First update to the latest dev branch and try changing the definition in {
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)
|
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) |
@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 |
@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:
So it is 1 to 254, not 255 |
I've tested the following with an Innr, IKEA and Hue bulb:
All bulbs returned 254 as the
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"
The text was updated successfully, but these errors were encountered: