-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
QBKG03LM / QBKG04LM / QBKG11LM - Aqara Wall Switch state reporting #1252
Comments
Can you provide the debug logging of this? To enable debug logging set in advanced:
log_level: debug |
|
Looks like the state does come in correctly but results in a wrong message being published. |
Changing the entry in devices.js to below will probably fix it {
zigbeeModel: ['lumi.ctrl_neutral2'],
model: 'QBKG03LM',
vendor: 'Xiaomi',
// eslint-disable-next-line
description: 'Aqara double key wired wall switch without neutral wire. Doesn\'t work as a router and doesn\'t support power meter',
supports: 'release/hold, on/off, temperature',
fromZigbee: [
fz.QBKG03LM_QBKG12LM_LLKZMK11LM_state, fz.QBKG03LM_buttons,
fz.QBKG03LM_QBKG12LM_operation_mode, fz.ignore_basic_report,
fz.generic_device_temperature, fz.on_off,
],
toZigbee: [tz.on_off, tz.xiaomi_switch_operation_mode],
endpoint: (device) => {
return {'system': 1, 'left': 2, 'right': 3};
},
onEvent: xiaomi.prevent_reset,
}, |
I've tried adding Currently, when button is physically clicked, the state is published as The proposed fix might be OK for the 1 button Aqara wall switch without neutral wire, which as far as I can see would also suffer from the same missing |
Should be fixed with: {
zigbeeModel: ['lumi.ctrl_neutral2'],
model: 'QBKG03LM',
vendor: 'Xiaomi',
// eslint-disable-next-line
description: 'Aqara double key wired wall switch without neutral wire. Doesn\'t work as a router and doesn\'t support power meter',
supports: 'release/hold, on/off, temperature',
fromZigbee: [
fz.QBKG03LM_QBKG12LM_LLKZMK11LM_state, fz.QBKG03LM_buttons,
fz.QBKG03LM_QBKG12LM_operation_mode, fz.ignore_basic_report,
fz.generic_device_temperature, fz.on_off,
],
meta: {multiEndpoint: true},
toZigbee: [tz.on_off, tz.xiaomi_switch_operation_mode],
endpoint: (device) => {
return {'system': 1, 'left': 2, 'right': 3};
},
onEvent: xiaomi.prevent_reset,
}, |
Tested and, indeed, the last change fixes the issue with the 2-button switch. Thank you! I will try and test single-button switch without neutral and 2-button switch with neutral later and report back. Is there also a way to query the state of both left/right in one go? I didn't find one... |
@uncle-fed I think it's possible with |
Unfortunately, this only returns |
That was a bug 🐛 Fixed in latest dev branch. Can you make a PR once you get this working? |
Sure, I can make a PR. |
Yes, the switch will send 2 Zigbee messages back (one for left and one for right) = 2 MQTT messages. |
Okay, I think now we got the 2-button, no neutral switch (QBKG03LM) in order. I started testing 1-button switch with neutral wire (QBKG11LM). When I publish to Also, definitely incorrectly, when I publish to Last thing, if you attempt to send
|
Now tested also 1-button switch without neutral wire (QBKG04LM). |
This is expected indeed. The first message comes from zigbee2mqtt itself, it is automatically send after the command is successful (because most devices don't report back their state). The second one is the report from the device itself.
This is wrong indeed, can you share the debug logging of this? To enable debug logging set in advanced:
log_level: debug
This device does only have one endpoint (no right or left), so this error makes sense. I think the problem is the vague error message? |
I reported this because I thought it was inconsistent with the behaviour of 2-button switch QBKG03LM. I thought that sending
Not much to look at here... but here you go :-) This is for a QBKG04LM switch, before adding the
And the same after adding
You're right it is about the actual error message and about consistency. Now it looks like a dump of node.js catching an exception. If you try and request any other "non-supported" attribute, you get an error of a kind: |
Fixed the following in the latest dev branch (for QKBG03LM, QBKG04LM, QBKG11LM, QBKG12LM)
|
Can confirm that the fixes above did the right thing. Many thanks! Well, almost. Something got slightly botched for the 2-button switch now. When I physically click on either left or right button, the device state is published as
|
Also fixed that |
Works well now. Thanks for all your time and support! |
Sorry, one more important detail that seems to be inconsistent between 1 and 2 button switches. This is about when physical buttons are clicked, in this case 2 messages are published. One with the 'state' only and 2nd one with information about the click. A click on the single button switch looks like this (all messages within same second):
A click on the left button of a 2 button switch looks like this:
What causes certain inconvenience is that you don't get the Having |
You can combine those messages into one with the |
I am not sure that I explained well. It is not about the fact that there are 2 messages (that you can combine, I know). It is about the fact that in one case the 2nd message does not contain 'state' attribute which, according to the debug output, is coming from the device. Both 1button switch and 2button switch report state but only with 1button switch it is published together with the "click" event. |
The second messages comes from endpoint 4, I'm not sure if it contains enough information to determine the state for endpoint 2. I think endpoint 4 is only used for the click event. |
If this is the case, then the 1 button switch is "lying" (I mean zigbee2mqtt is lying on its behalf) about the state. Just have a look at the debug output above for 1button and 2button switch. They have identical incoming information from endpoint 4 but it results in a different message published. I am just trying to get things consistent.
If state cannot be determined from endpoint 4, then it should NOT be published for 1button switch, which is currently the case. |
Tried the latest fix now (had to manually overwrite my files, for some reason pulling latest z2m dev branch did not get the changes from the last commit here). Now the behaviour is consistent, i.e., single-button switch does NOT report One more consistency matter (please, please don't hate me for being so OCD :-)). Some attribute naming for single and double button switch does not match. Single button switch publishes this:
Double button switch publishes this:
Shouldn't the Also, the value |
I've just updated the latest dev branch so the changes are in now. Regarding that inconsistency, it's indeed something that should be fixed. But this would introduce a breaking change, so it's something that will be cleaned up in zigbee2mqtt 2.0. In zigbee2mqtt 2.0 such events will only be exposed on an |
... the saga continues... more testing was done and it looks like only the
|
Probably found the issue, please check this commit: fee101b |
Yes! :-) |
Hi, not sure if this is the right place, but I've been looking everyone about QVKG04LM not reporting temperature. Is there a fix for this? thanks |
I've realised now running zigbee2mqtt with
state_cache
disabled that my Aqara Wall switch does not report back its state when queried. It does reply but sends back only its signal level.This is the 2-button Aqara wall switch without neutral wire.
https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices.js#L632-L648
I publish
{"state": ""}
tozigbee2mqtt/device-name/left/get
and response comes immediately tozigbee2mqtt/device-name
, but it contains only{"linkquality":xx}
and nothing about state.Also tried alternative way, sending
{"state_left": ""}
tozigbee2mqtt/device-name/get
, the response is identical to above (onlylinkquality
).Is it supposed to work this way? Is this switch capable of reporting state on demand? Mine does not report temperature either, BTW.
The text was updated successfully, but these errors were encountered: