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

QBKG03LM / QBKG04LM / QBKG11LM - Aqara Wall Switch state reporting #1252

Closed
uncle-fed opened this issue May 21, 2020 · 31 comments
Closed

QBKG03LM / QBKG04LM / QBKG11LM - Aqara Wall Switch state reporting #1252

uncle-fed opened this issue May 21, 2020 · 31 comments

Comments

@uncle-fed
Copy link
Contributor

uncle-fed commented May 21, 2020

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": ""} to zigbee2mqtt/device-name/left/get and response comes immediately to zigbee2mqtt/device-name, but it contains only {"linkquality":xx} and nothing about state.

Also tried alternative way, sending {"state_left": ""} to zigbee2mqtt/device-name/get, the response is identical to above (only linkquality).

Is it supposed to work this way? Is this switch capable of reporting state on demand? Mine does not report temperature either, BTW.

@Koenkk
Copy link
Owner

Koenkk commented May 21, 2020

Can you provide the debug logging of this?

To enable debug logging set in configuration.yaml:

advanced:
  log_level: debug

@uncle-fed
Copy link
Contributor Author

May 21 17:37:54 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:54: Logging to console and directory: '/opt/zigbee2mqtt/data/log/2020-05-21.17-37-54' filename: log.txt
May 21 17:37:54 openHABianPi npm[26441]: zigbee2mqtt:debug 2020-05-21 17:37:54: Removing old log directory '/opt/zigbee2mqtt/data/log/2020-05-04.22-13-20'
May 21 17:37:55 openHABianPi npm[26441]: zigbee2mqtt:debug 2020-05-21 17:37:55: Loaded state from file /opt/zigbee2mqtt/data/state.json
May 21 17:37:56 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:56: Starting zigbee2mqtt version 1.13.1 (commit #3046680)
May 21 17:37:56 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:56: Starting zigbee-herdsman...
May 21 17:37:56 openHABianPi npm[26441]: zigbee2mqtt:debug 2020-05-21 17:37:56: Using zigbee-herdsman with settings: '{"network":{"panID":6754,"extendedPanID":[221,221,221,221,221,221,221,221],"channelList":[11],"networkKey":"HIDDEN"},"databasePath":"/opt/zigbee2mqtt/data/database.db","databaseBackupPath":"/opt/zigbee2mqtt/data/database.db.backup","backupPath":"/opt/zigbee2mqtt/data/coordinator_backup.json","serialPort":{"baudRate":115200,"rtscts":true,"path":"/dev/ttyACM0"},"adapter":{"concurrent":null}}'
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: zigbee-herdsman started
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: Coordinator firmware version: '{"type":"zStack30x","meta":{"transportrev":2,"product":2,"majorrel":2,"minorrel":7,"maintrel":2,"revision":20190425}}'
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:debug 2020-05-21 17:37:59: Zigbee network parameters: {"panID":6755,"extendedPanID":"0x00124b0019367210","channel":11}
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: Currently 6 devices are joined:
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: thermostat (0x000d6f000c2cddc2): AV2010/32 - Bitron Wireless wall thermostat with relay (EndDevice)
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: test/wall-switch (0x00158d0002a718b7): QBKG03LM - Xiaomi Aqara double key wired wall switch without neutral wire. Doesn't work as a router and doesn't support power meter (Router)
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: sensor/bedroom (0x00158d00034cec62): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: sensor/outside (0x00158d0002720d78): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: sensor/kitchen (0x00158d000322a2f9): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: test/motion-sensor (0x00158d0002c7174b): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: Zigbee: disabling joining new devices.
May 21 17:37:59 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:37:59: Connecting to MQTT server at mqtt://localhost
May 21 17:38:00 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:38:00: Connected to MQTT server
May 21 17:38:00 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:38:00: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'
May 21 17:38:00 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:38:00: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"version":"1.13.1","commit":"3046680","coordinator":{"type":"zStack30x","meta":{"transportrev":2,"product":2,"majorrel":2,"minorrel":7,"maintrel":2,"revision":20190425}},"log_level":"debug","permit_join":false}'
May 21 17:38:47 openHABianPi npm[26441]: zigbee2mqtt:debug 2020-05-21 17:38:47: Received Zigbee message from 'test/wall-switch', type 'read', cluster 'genTime', data '["time"]' from endpoint 1 with groupID 0
May 21 17:39:03 openHABianPi npm[26441]: zigbee2mqtt:debug 2020-05-21 17:39:03: Received MQTT message on 'zigbee2mqtt/test/wall-switch/left/get' with data '{"state":""}'
May 21 17:39:03 openHABianPi npm[26441]: zigbee2mqtt:debug 2020-05-21 17:39:03: Publishing get 'get' 'state' to 'test/wall-switch'
May 21 17:39:04 openHABianPi npm[26441]: zigbee2mqtt:debug 2020-05-21 17:39:04: Received Zigbee message from 'test/wall-switch', type 'readResponse', cluster 'genOnOff', data '{"onOff":0}' from endpoint 2 with groupID 0
May 21 17:39:04 openHABianPi npm[26441]: zigbee2mqtt:info  2020-05-21 17:39:04: MQTT publish: topic 'zigbee2mqtt/test/wall-switch', payload '{"linkquality":63}'

@uncle-fed
Copy link
Contributor Author

Looks like the state does come in correctly but results in a wrong message being published.

@Koenkk
Copy link
Owner

Koenkk commented May 21, 2020

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,
},

@uncle-fed
Copy link
Contributor Author

I've tried adding fz.on_off to the list of fromZigbee elements. It makes things a bit better, indeed. The state is being reported as a message with payload {"state":"OFF","linkquality":63}. Unfortunately this is not really a satisfactory solution. There is no indication which button's state (left or right in case of this device) we are getting.

Currently, when button is physically clicked, the state is published as {"state_left": "..."} and {"state_right": "..."}, which, I suppose, comes from the fz.QBKG03LM_QBKG12LM_LLKZMK11LM_state . Querying for state via the get method should also report state in a similar way, otherwise this function is no use.

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 fz.on_off
https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices.js#L598-L612
I have one but will need to test it later.

@Koenkk
Copy link
Owner

Koenkk commented May 21, 2020

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,
},

@uncle-fed
Copy link
Contributor Author

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...

@Koenkk
Copy link
Owner

Koenkk commented May 22, 2020

@uncle-fed I think it's possible with zigbee2mqtt/[FRIENDLY_NAME]/get {"state_right": "", "state_left":""}

@uncle-fed
Copy link
Contributor Author

Unfortunately, this only returns state_left when I try it. Actually it returns the state of the second state_ item. If I reverse them, I get back state_right reported.

@Koenkk
Copy link
Owner

Koenkk commented May 22, 2020

That was a bug 🐛

Fixed in latest dev branch. Can you make a PR once you get this working?

@uncle-fed
Copy link
Contributor Author

Sure, I can make a PR.
I tested the dev branch and now I can send a single 'get' request with state_left and state_right. The reply comes as 2 separate MQTT messages (one for state_left and one for state_right). Is this the intended behaviour?

@Koenkk
Copy link
Owner

Koenkk commented May 22, 2020

Yes, the switch will send 2 Zigbee messages back (one for left and one for right) = 2 MQTT messages.

@uncle-fed
Copy link
Contributor Author

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).
Things are quite messy there, even when I add fz.on_off to the relevant section in devices.js (otherwise it would not report its state at all via get). Here is the breakdown:

When I publish to zigbee2mqtt/friendly-name/set payload {"state":"on"}, the command is correctly processed by the switch but it results in 2 messages that are published to MQTT zigbee2mqtt/friendly-name as the "response": 1st message has payload '{"state":"ON"} and second message {"state":"ON","linkquality":99}. Shouldn't it be a single message?

Also, definitely incorrectly, when I publish to zigbee2mqtt/friendly-name/get payload {"state":""}, the response is published to zigbee2mqtt/friendly-name with the following payload {"click":"single","state":"ON","linkquality":94}. There is definitely no click involved anywhere and yet the response contains it. So looks like another bug, to be honest.

Last thing, if you attempt to send {"state_right":""} to zigbee2mqtt/friendly-name/get, you will get this in the log file:

May 22 21:40:19 openHABianPi npm[31611]: zigbee2mqtt:error 2020-05-22 21:40:19: Failed to call 'EntityPublish' 'onMQTTMessage' (TypeError: Cannot read property 'constructor' of undefined
May 22 21:40:19 openHABianPi npm[31611]:     at EntityPublish.onMQTTMessage (/opt/zigbee2mqtt/lib/extension/publish.js:163:52)
May 22 21:40:19 openHABianPi npm[31611]:     at Controller.callExtensionMethod (/opt/zigbee2mqtt/lib/controller.js:350:44)
May 22 21:40:19 openHABianPi npm[31611]:     at Controller.onMQTTMessage (/opt/zigbee2mqtt/lib/controller.js:244:14)
May 22 21:40:19 openHABianPi npm[31611]:     at MQTT.emit (events.js:189:13)
May 22 21:40:19 openHABianPi npm[31611]:     at MQTT.onMessage (/opt/zigbee2mqtt/lib/mqtt.js:95:14)
May 22 21:40:19 openHABianPi npm[31611]:     at MqttClient.emit (events.js:189:13)
May 22 21:40:19 openHABianPi npm[31611]:     at MqttClient._handlePublish (/opt/zigbee2mqtt/node_modules/mqtt/lib/client.js:1269:12)
May 22 21:40:19 openHABianPi npm[31611]:     at MqttClient._handlePacket (/opt/zigbee2mqtt/node_modules/mqtt/lib/client.js:409:12)
May 22 21:40:19 openHABianPi npm[31611]:     at work (/opt/zigbee2mqtt/node_modules/mqtt/lib/client.js:320:12)
May 22 21:40:19 openHABianPi npm[31611]:     at Writable.writable._write (/opt/zigbee2mqtt/node_modules/mqtt/lib/client.js:334:5))

@uncle-fed
Copy link
Contributor Author

Now tested also 1-button switch without neutral wire (QBKG04LM).
The behaviour is absolutely identical to the one described in previous comment for QBKG11LM.
Needs fixing similar way.

@uncle-fed uncle-fed changed the title QBKG03LM Aqara Wall Switch state reporting QBKG03LM / QBKG04LM / QBKG11LM - Aqara Wall Switch state reporting May 23, 2020
@Koenkk
Copy link
Owner

Koenkk commented May 23, 2020

When I publish to zigbee2mqtt/friendly-name/set payload {"state":"on"}, the command is correctly processed by the switch but it results in 2 messages that are published to MQTT zigbee2mqtt/friendly-name as the "response": 1st message has payload '{"state":"ON"} and second message {"state":"ON","linkquality":99}. Shouldn't it be a single message?

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.

Also, definitely incorrectly, when I publish to zigbee2mqtt/friendly-name/get payload {"state":""}, the response is published to zigbee2mqtt/friendly-name with the following payload {"click":"single","state":"ON","linkquality":94}. There is definitely no click involved anywhere and yet the response contains it. So looks like another bug, to be honest.

This is wrong indeed, can you share the debug logging of this? To enable debug logging set in configuration.yaml:

advanced:
  log_level: debug

Last thing, if you attempt to send {"state_right":""} to zigbee2mqtt/friendly-name/get, you will get this in the log file:

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?

@uncle-fed
Copy link
Contributor Author

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.

I reported this because I thought it was inconsistent with the behaviour of 2-button switch QBKG03LM. I thought that sending set to the 2-button switch resulted in only one response message (the one with the linkquality included). After your explanation I would need to double check if I am imagining it.

This is wrong indeed, can you share the debug logging of this?

Not much to look at here... but here you go :-) This is for a QBKG04LM switch, before adding the fz.on_off fix.

May 23 20:32:01 openHABianPi npm[1014]: zigbee2mqtt:debug 2020-05-23 20:32:01: Received MQTT message on 'zigbee2mqtt/test/wall-switch-1btn/get' with data '{"state":""}'
May 23 20:32:01 openHABianPi npm[1014]: zigbee2mqtt:debug 2020-05-23 20:32:01: Publishing get 'get' 'state' to 'test/wall-switch-1btn'
May 23 20:32:02 openHABianPi npm[1014]: zigbee2mqtt:debug 2020-05-23 20:32:02: Received Zigbee message from 'test/wall-switch-1btn', type 'readResponse', cluster 'genOnOff', data '{"onOff":0}' from endpoint 2 with groupID 0
May 23 20:32:02 openHABianPi npm[1014]: zigbee2mqtt:info  2020-05-23 20:32:02: MQTT publish: topic 'zigbee2mqtt/test/wall-switch-1btn', payload '{"click":"single","linkquality":63}'

And the same after adding fz.on_off:

May 23 20:35:08 openHABianPi npm[1111]: zigbee2mqtt:debug 2020-05-23 20:35:08: Received MQTT message on 'zigbee2mqtt/test/wall-switch-1btn/get' with data '{"state":""}'
May 23 20:35:08 openHABianPi npm[1111]: zigbee2mqtt:debug 2020-05-23 20:35:08: Publishing get 'get' 'state' to 'test/wall-switch-1btn'
May 23 20:35:09 openHABianPi npm[1111]: zigbee2mqtt:debug 2020-05-23 20:35:09: Received Zigbee message from 'test/wall-switch-1btn', type 'readResponse', cluster 'genOnOff', data '{"onOff":0}' from endpoint 2 with groupID 0
May 23 20:35:09 openHABianPi npm[1111]: zigbee2mqtt:info  2020-05-23 20:35:09: MQTT publish: topic 'zigbee2mqtt/test/wall-switch-1btn', payload '{"click":"single","state":"OFF","linkquality":63}'

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?

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: No converter available for ... . So maybe a better error can be provided, stating that Device has single endpoint or something like that.

Koenkk added a commit that referenced this issue May 23, 2020
Koenkk added a commit that referenced this issue May 23, 2020
@Koenkk
Copy link
Owner

Koenkk commented May 23, 2020

Fixed the following in the latest dev branch (for QKBG03LM, QBKG04LM, QBKG11LM, QBKG12LM)

  • click event when getting state
  • added the fz.on_off
  • Good error message when endpoint does not exist.

@uncle-fed
Copy link
Contributor Author

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 state_undefined attribute (instead of state_left or state_right):

2020-05-23 23:03:57: Received Zigbee message from 'test/wall-switch-2btn', type 'attributeReport', cluster 'genOnOff', data '{"61440":50957836,"onOff":1}' from endpoint 2 with groupID 0
2020-05-23 23:03:57: MQTT publish: topic 'zigbee2mqtt/test/wall-switch-2btn', payload '{"state_left":"ON","linkquality":49}'
2020-05-23 23:03:57: Received Zigbee message from 'test/wall-switch-2btn', type 'attributeReport', cluster 'genOnOff', data '{"onOff":1}' from endpoint 4 with groupID 0
2020-05-23 23:03:57: MQTT publish: topic 'zigbee2mqtt/test/wall-switch-2btn', payload '{"state_undefined":"ON","click":"left","button_left":"release","linkquality":42}'

@Koenkk
Copy link
Owner

Koenkk commented May 24, 2020

Also fixed that

@uncle-fed
Copy link
Contributor Author

Works well now. Thanks for all your time and support!

@uncle-fed
Copy link
Contributor Author

uncle-fed commented May 27, 2020

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):

Received Zigbee message from 'livingroom/wall-switch', type 'attributeReport', cluster 'genOnOff', data '{"61440":57900826,"onOff":1}' from endpoint 2 with groupID 0
MQTT publish: topic 'zigbee2mqtt/livingroom/wall-switch', payload '{"state":"ON","linkquality":70}'
Received Zigbee message from 'livingroom/wall-switch', type 'attributeReport', cluster 'genOnOff', data '{"onOff":1}' from endpoint 4 with groupID 0
MQTT publish: topic 'zigbee2mqtt/livingroom/wall-switch', payload '{"state":"ON","click":"single","action":"release","linkquality":68}'

A click on the left button of a 2 button switch looks like this:

Received Zigbee message from 'kitchen/wall-switch', type 'attributeReport', cluster 'genOnOff', data '{"61440":66334236,"onOff":1}' from endpoint 2 with groupID 0
MQTT publish: topic 'zigbee2mqtt/kitchen/wall-switch', payload '{"state_left":"ON","linkquality":65}'
Received Zigbee message from 'kitchen/wall-switch', type 'attributeReport', cluster 'genOnOff', data '{"onOff":1}' from endpoint 4 with groupID 0
MQTT publish: topic 'zigbee2mqtt/kitchen/wall-switch', payload '{"click":"left","button_left":"release","linkquality":76}'

What causes certain inconvenience is that you don't get the state published together with the click in the 2nd case (2 button switches).

Having state published is very convenient for automation because the "click" event carries all of the information about the click, including what happened because of the clicking.

@uncle-fed uncle-fed reopened this May 27, 2020
@Koenkk
Copy link
Owner

Koenkk commented May 28, 2020

You can combine those messages into one with the debounce feature (https://www.zigbee2mqtt.io/information/configuration.html#all-devices).

@uncle-fed
Copy link
Contributor Author

uncle-fed commented May 28, 2020

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.

@Koenkk
Copy link
Owner

Koenkk commented May 28, 2020

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.

@uncle-fed
Copy link
Contributor Author

uncle-fed commented May 28, 2020

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.

'attributeReport', cluster 'genOnOff', data '{"onOff":1}' from endpoint 4 with groupID 0

If state cannot be determined from endpoint 4, then it should NOT be published for 1button switch, which is currently the case.

@uncle-fed
Copy link
Contributor Author

uncle-fed commented May 28, 2020

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 state together with the "click", same way like 2-button switch. Fixed. :-)

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.
After all we're talking about the same line of products with the same look and feel.
Consider this:

Single button switch publishes this:

{"click":"single", "action":"release", "linkquality":73}

Double button switch publishes this:

{"click":"left","button_left":"release", "linkquality":86}

Shouldn't the action be called button ?
Or the other way around, shouldn't the button_... be called action_... ?

Also, the value click: single is kinda weird... suggesting to a potential user that there might be double-click or some other type of click (which there isn't cause only one click type is possible). But here, perhaps, I am being super-obsessed. Feel free to ignore this 'single' last bit... :-)

@Koenkk
Copy link
Owner

Koenkk commented May 28, 2020

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 action property.

@uncle-fed
Copy link
Contributor Author

uncle-fed commented May 28, 2020

... the saga continues... more testing was done and it looks like only the left button of 2 button switch is behaving OK. The right one is still returning state in the 2nd message , and it is also state_undefined too.

2020-05-28 21:58:17: MQTT publish: topic 'z2m/switch', payload '{"state_left":"OFF","linkquality":70}'
2020-05-28 21:58:18: MQTT publish: topic 'z2m/switch', payload '{"click":"left","button_left":"release","linkquality":55}'
2020-05-28 21:58:18: MQTT publish: topic 'z2m/switch', payload '{"state_left":"ON","linkquality":70}'
2020-05-28 21:58:18: MQTT publish: topic 'z2m/switch', payload '{"click":"left","button_left":"release","linkquality":76}'

2020-05-28 21:58:01: MQTT publish: topic 'z2m/switch', payload '{"state_right":"OFF","linkquality":78}'
2020-05-28 21:58:01: MQTT publish: topic 'z2m/switch', payload '{"state_undefined":"ON","click":"right","button_right":"release","linkquality":68}'
2020-05-28 21:58:02: MQTT publish: topic 'z2m/switch', payload '{"state_right":"ON","linkquality":76}'
2020-05-28 21:58:02: MQTT publish: topic 'z2m/switch', payload '{"state_undefined":"ON","click":"right","button_right":"release","linkquality":89}'

@Koenkk
Copy link
Owner

Koenkk commented May 29, 2020

Probably found the issue, please check this commit: fee101b

@uncle-fed
Copy link
Contributor Author

Yes! :-)

@drumstick77
Copy link

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

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