Xiaomi QBKG03LM / QBKG04LM switches messed up payload with 'legacy: false' #11466
Labels
problem
Something isn't working
Comments
uncle-fed
changed the title
|
About the first 3 points, we should put the non legacy actions in the exposes, could you provide a list of all options?
Can you provide the debug log when the action contains
This looks like your device does not support this, from Koenkk/zigbee-herdsman-converters@3d1a721 by @ruifung:
|
I think one of us is confused here (currently me, with your reply :-)) I was trying to say that the documentation is fine (i.e. the documented behaviour = expected behaviour = how it should be), but the current implementation does not conform to that. The names of the "single click" events that z2m emits are not correct at present (as described in the first 2 points). And the 3rd point is about the fact that the currently present property should NOT be present in the payload, because it is not expected and it is not documented, i.e. it should be removed from the code, not put into the documentation :-) In other words, this is not about documentation, it is about the code changes that should make z2m work as currently documented.
In this case, shouldn't the web UI / Zigbee converter NOT allow this GET operation and reject it immediately? Both models of the switches discussed here do not support "get" of the |
Koenkk
added a commit
to Koenkk/zigbee-herdsman-converters
that referenced
this issue
Feb 18, 2022
|
The value of
Done (shouldn't show the get anymore). Changes will be available in the dev branch in tomorrow. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html) |
The docs are correct already. The |
this is for the QBKG04LM, what about the QBKG03LM, I expect (left|right)_(hold|release) We also need to tackle the |
|
As descibed in my inital post, points 1 and 2:
|
|
Double click right -- results in Double click left -- results in Also, for completeness, single clicks that result in Also note the property called |
Koenkk
added a commit
to Koenkk/zigbee-herdsman-converters
that referenced
this issue
Feb 19, 2022
|
|
@Koenkk Thanks a lot, I've verified the latest code changes. Double presses are now recognized (even though they are a bit awkward to actually generate consistently). So, everything you've said in the last comment is true and correct. Unfortunately. Unfortunately, because both To me this essentially means that the switch cannot be used to create scenarios where the same device could launch different actions on single press and on hold. If you configure action for the "release" event, it will be launched either on single press or at the end of hold - no distinction. Which then means, if you use single press action, then the hold cannot be used at all, as there is no way to distinguish between the end of hold or a single click. I have a proposal here that maybe is able to resolve this "inconvenience". Could there be an (internal, per device) flag that gets raised every time the
What do you think? |
|
What if the release actions will include the last action? So you will have a We have to think how to documents this and this cannot be the default behaviour since it is breaking. |
|
We could also do This of course would be already much better than the current implementation, but why not just actually implementing what has been documented from the start? I.e., the documentation pages for these switches stated |
|
See another user complaining about the documented behaviour not corresponding to reality here: |
|
i understand your point, but changing the behaviour is a breaking change, users depend on the current behaviour. So this new behaviour (with the flag stuff) should definitely be an option imo. |
It is going to be breaking for those who never read the docs and just relied on the implemented behavior. Can we call something that fixes the behavior to be compliant with the documentation to be breaking? I'll leave you to be the judge of that. :) I saw the problem because I read the docs and it didn't match the reality, so I immediately opened the issue here. Another person (quoted above) did the same. If others implemented something without following the API/docs and now it's going to break for them, whose problem is that? :) Also we're talking about new, non legacy behaviour where a fix like that can also be justified as the way forward. |
|
In my opinion the docs were wrong (since the I was wondering, is the |
|
|
|
I see, so another non-breaking possibility here would be to publish two actions for the single case. Although for the release case you don't know if it was from a hold or single. What do you think? So:
|
|
That sounds like a compromise solution which aims at being non-breaking. You're right, it leaves one use case incomplete / broken (depending on what you intend to do with the hold/release actions). Not ideal... But we could extend this idea and go all the way: we should also then add another (second) action for the end of the "hold/release" sequence and call it However, I still would like to point out that this discussion changes the accents about what's more important (in the long run) if we look in the context of If there were no I know that a lot of people on the forums and Telegram channels dedicated to the theme are always discussing the changelogs for every single z2m release and even minor update. Surely people would notice a text "POTENTIALLY BREAKING" ;-) |
|
Maybe, as yet another compromise, for now the set of secondary actions ( |
Do you mean that the switch actually provides different messages for the release after single-click and release after hold but the current converter does not make this distinction? Or I don't fully understand ?... |
This is fine by my
Legacy false is already the default behavior for many users (it will be set once a new network is started) @uncle-fed for the sake of completeness, can you provide me the debug log of the following sequences:
|
|
Single button switch, single press Single button switch, hold... wait... release 2-button switch, left button, single press 2-button switch, left button, hold... wait... release |
Koenkk
added a commit
to Koenkk/zigbee-herdsman-converters
that referenced
this issue
Feb 21, 2022
|
Thanks, added it now, can you test it? Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html) |
|
Hi, I've updated dev to get the 'converters 14.0.429' version but I don't get any new actions, i.e., no "single" actions seen, everything looks like before. |
|
I've completely reinstalled z2m and switched to the latest dev branch. I am still not seeing the "two actions". homeassistant: false
permit_join: false
frontend:
port: 8883
mqtt:
base_topic: z2m
server: mqtt://127.0.0.1
serial:
port: /dev/serial0
advanced:
cache_state: false
cache_state_persistent: false
cache_state_send_on_startup: false
channel: 15
last_seen: ISO_8601
legacy_availability_payload: false
legacy_api: false
rtscts: false
availability:
active:
timeout: 5
passive:
timeout: 60
device_options:
retain: false
legacy: false
debounce: 0.5
devices:
'0x00xxxxxxxxxxxxxxx':
friendly_name: switch/livingroom/ceiling
'0x00xxxxxxxxxxxxxxx':
friendly_name: switch/kitchen/wall |
|
@uncle-fed checked the code but I don't see what is wrong yet, is the |
|
Yes, the |
|
@uncle-fed can you provide the debug log starting from the point where you start z2m until a release action is send? See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable debug logging. |
|
|
First is a single press, then it is hold and release sequence. |
|
From the z2m dir, can you do |
|
|
Ah I think this is because the |
|
Indeed that was the reason! Thanks! |
|
done, can this be closed? |
Koenkk
added a commit
to Koenkk/zigbee2mqtt.io
that referenced
this issue
Feb 25, 2022
|
Yes, thanks a lot for your efforts and persistence! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
This issue picks up on the abandoned problem report #3002, with some additional information about incorrect behaviour.
There are several issues with the QBKG03LM / QBKG04LM single and 2-button switches when you press (or hold) their button(s).
What did you expect to happen?
The generated payload does not correspond to the documented (and the expected) one when z2m is running with disabled legacy mode.
How to reproduce it (minimal and precise)
z2m has the following config options set:
1-button switch emits
action: release, instead of theaction: singlewhen the button is clicked ordinarily. According to the documentation, thereleaseaction should only be seen when the switch button is held and then released.Similarly, the 2-button switch emits
action: release_leftoraction: release_rightorrelease_both, instead of thesingle_leftorsingle_rightorsingle_bothwhen the buttons are pressed shortly.In addition to
action, the 2-button switch has in its payloadbutton_left: ...orbutton_right: ...property, which is not mentioned anywhere in the documentation. Even in the legacy mode it only mentions the deprecatedclick_*poperty, but nothing aboutbutton_. Single button switch behaves correctly (does not transmit thebuttonproperty in this case).Even though it is not documented, it seems that the switch might be capable of distinguishing a double-click event. If you try it on a 2-button switch, for example, you get
action: undefined_left, which is different fromrelease_leftorhold_left. This may suggest that the switch could potentially offer more actions.Getting the
operation_modeproperty does not work. Every time I try, I get the timeoutPublish 'get' 'operation_mode' to '....' failed: 'Error: Read 0x00xxxxxxxxxxxxxxxx/2 genBasic([65314], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 36884 - 2 - 19 - 0 - 1 after 10000ms)'. However, setting theoperation_modewith/setdoes work properly and is instant.Zigbee2MQTT version
1.23.0-dev commit: aace02c
Adapter firmware version
20190523
Adapter
СС2538-RPi-Hat
Debug log
No response
The text was updated successfully, but these errors were encountered: