Zigbee2mqtt: Xiaomi QBKG03LM and QBKG04LM issues

[Koenkk]

As various (probably similar) issues with the Xiaomi QBKG03LM and QBKG04LM have been reported, I decided to create this single issue and close the other ones.

Reported issues:

• Unresponsive after some time; no route found (#254, #884, #334)
• Randomly turning off (#812)

[jarrah31]

Regarding #884 I too had issues with QBKG03LM loosing it's connection (whilst on Coordinator firmware version: '20181024'), but due to issues described here I ended up refreshing my coordinator with version '20181224' (found here), and it's been stable since.
However it's worth noting that I added an extra router between the wall switch and coordinator, so that may have helped as well...

It still occasionally turns off the lights by itself, but I haven't got to the bottom of that yet.

[pkedvessy]

Seems like random turn offs are caused by having mqttadminpanel in NodeRed. I have disabled the dashboard and all looks good. Maybe it is related to the frequent networkmap lookups... Anyone, who has random turn off issues, could you please confirm that you are having mqttadminpanel in NodeRed? If so, could you please have a try with turning off the admin panel?

[aimartin]

Seems like random turn offs are caused by having mqttadminpanel in NodeRed. I have disabled the dashboard and all looks good. Maybe it is related to the frequent networkmap lookups... Anyone, who has random turn off issues, could you please confirm that you are having mqttadminpanel in NodeRed? If so, could you please have a try with turning off the admin panel?

I've nodered, and I've some mqtt input and ouput nodes, but I don't think I've mqttadminpanel installed :S

[hanross2323]

Same as Aitor. I use nodered but no admin as far as I know.

I’m testing device connected through Xiaomi gateway and that to hastío through component and it seem to work just fine and stable.

Alex Catena
RTM Iberia

On 30 Jan 2019, at 10:15, Aitor Martin [e-mail] wrote:

Seems like random turn offs are caused by having mqttadminpanel in NodeRed. I have disabled the dashboard and all looks good. Maybe it is related to the frequent networkmap lookups... Anyone, who has random turn off issues, could you please confirm that you are having mqttadminpanel in NodeRed? If so, could you please have a try with turning off the admin panel?

I've nodered, and I've some mqtt input and ouput nodes, but I don't think I've mqttadminpanel installed :S

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Koenkk]

@aimartin @hanross2323 based on @pkedvessy this issue seems to happen when the network map is requested, do you request this map on a regular base?

[aimartin]

I've never requested a network map (at least, not manually, nor in NodeRed).

I still see that the device is showing up in other instances of zigbee2mqtt (I've 3 floors, and one Pi acting as independent server, posting to different MQTT topics), so it seems that even if I join to one server, eventually it will "jump" to other and that seems to cause issues... I'm planning to upgrade to the 1.1.0 version and try the "ban" feature, to see if that helps...

@Koenkk that makes sense to you?

Regards

[Koenkk]

@aimartin are these zigbee2mqtt instances operating on the same zigbee channel?

[aimartin]

@aimartin are these zigbee2mqtt instances operating on the same zigbee channel?

I've checked my configuration.yaml and I don't see anything regarding channel... how can I check that? (I've Linux and systems knowledge, but not much in Zigbee)

[Koenkk]

That means they are all on the same channel (I guess you also didn't set a different encryption key, meaning that the key is also the same).

You should use a separate channel for each zigbee2mqtt instance. This will also avoid any interference. (see channel https://koenkk.github.io/zigbee2mqtt/configuration/configuration.html). Note that after changing this you have to re-pair your devices.

[aimartin]

That means they are all on the same channel (I guess you also didn't set a different encryption key, meaning that the key is also the same).

You should use a separate channel for each zigbee2mqtt instance. This will also avoid any interference. (see channel https://koenkk.github.io/zigbee2mqtt/configuration/configuration.html). Note that after changing this you have to re-pair your devices.

Ouch!! I wasn´t aware of this, I'll update and change it during this weekend, seems that I'll have a lot of work xD

Will report back once done and tested, thanks!

[hanross2323]

No, I don’t request map and I don’t think I have changed any encryption key since I just learn you can do it :)

Alex Martinez

On 30 Jan 2019, at 10:48, Koen Kanters [e-mail] wrote:

@aimartin @hanross2323 based on @pkedvessy this issue seems to happen when the network map is requested, do you request this map on a regular base?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[aimartin]

Ok, I've started changing this, and I've found something weird:

if I put channel in a different channel (like 10), the USB device led goes to red and zigbee2mqtt doesn't start, but if I setup it to 11, it works fine. I've flashed the usb with the latest HEX (20190109).

I've also changed the network_key, will that be enough?

Regards

[pkedvessy]

Channel could be between 11 and 26.

[aimartin]

Channel could be between 11 and 26.

LOL, that explains a lot #Facepalm

[jarrah31]

It's worth saying that I don't use NodeRed but still experienced the random switch offs.

I have a friend who also has a QBKG03LM which keeps turning off as well. We're going to try upgrading to the latest coordinator to see if that makes a difference (he also doesn't use NodeRed).

[Nephiel]

According to the links below [1] [2], only the versions with neutral wire (QBKG11LM / QBKG12LM) can act as Zigbee routers. The QBKG03LM / QBKG04LM are the "no neutral wire" version. Do they really work as routers?

[1] http://en.miui.com/thread-2058422-1-1.html#post_23859766
[2] https://community.aqara.com/forum/faq-1/topic/which-aqara-products-can-act-as-zigbee-repeaters-564

[timdonovanuk]

FWIW - I'm not using zigbee2mqtt (although I'm about to make the jump) and my Aqara wall switches randomly turn off too. I'm using the Aqara gateway + Homeassistant + NodeRed and the "no neutral wire" double switch version.

They only seem to randomly switch off when I turn on bulbs all at once (smart bulbs...so the switch is on but the bulbs are set to 0%...if I set all bulbs to 100% at once). It's almost as if they are tripping something in the switch.

If I look in the Aqara app, it actually shows a log item "Double RoOff", which is interesting, as it only logs this when an API call turns them off (pushing the buttons results in a "press " in the logs). However, who knows, maybe if they trip the developers also just log a normal API off event in the logs.

The QBKG03LM / QBKG04LM are the "no neutral wire" version. Do they really work as routers?

No, they wont. Without a neutral they barely have enough power to receive, they definitely won't have enough power to drive zigbee mesh logic and repeat other signals.

[Koenkk]

@timdonovanuk that make this issue even more interesting, do you have any none Xiaomi devices in this zigbee network? (e.g. tradfri)

[timdonovanuk]

@Koenkk Indeed!

I have a Tradfri hub and the bulbs I'm testing with the Aqara switch are Tradfri bulbs, but because I'm not using zigbee2mqtt yet, I guess the tradfri and aqara devices won't be meshed as one zigbee network.

[Koenkk]

@timdonovanuk do you also have tradfri bulbs connected to the aqara hub? (that's possible since a few weeks).

[timdonovanuk]

Nope. I tried but couldn't get them to add, my bulbs are some of the first UK batch ever sold and the model numbers don't even match whats in the Aqara app.

[Nephiel]

The QBKG03LM / QBKG04LM are the "no neutral wire" version. Do they really work as routers?

No, they wont. Without a neutral they barely have enough power to receive, they definitely won't have enough power to drive zigbee mesh logic and repeat other signals.

That's what I thought. Thank you for the clarification.

FWIW - I'm not using zigbee2mqtt (although I'm about to make the jump) and my Aqara wall switches randomly turn off too. I'm using the Aqara gateway + Homeassistant + NodeRed and the "no neutral wire" double switch version.

They only seem to randomly switch off when I turn on bulbs all at once (smart bulbs...so the switch is on but the bulbs are set to 0%...if I set all bulbs to 100% at once). It's almost as if they are tripping something in the switch.

If I look in the Aqara app, it actually shows a log item "Double RoOff", which is interesting, as it only logs this when an API call turns them off (pushing the buttons results in a "press " in the logs). However, who knows, maybe if they trip the developers also just log a normal API off event in the logs.

That's interesting. I noticed that if I leave any of my QBKG04LMs switched on, and then cut off the mains, when I turn mains back on, the bulbs will light up for a second and then the switches will turn off their relays. I wonder if the "RoOff" event is sent in that case as well.

Here's what I think is happening: the relay on the switch is on, the loads are smart bulbs, but they are turned off, so the current routed through them is very small. When the bulbs turn on, the switch can't handle the sudden rise in current for the load. The voltage drops, enough to power off the electronics, but not necessarily the relay. A second later, when the load stabilizes, the switch powers back on, and turns off the relay. Same thing might happen with brownouts.

Anyone experience the random turn-offs with non-smart bulbs?

[Koenkk]

@Nephiel that would indicate that the QBKG04LM/QBKG03LM just have a bad electronic design?

[Nephiel]

Maybe, but not necessarily. I guess some compromises must be made in order to power the electronics without a neutral wire. After all, they are only rated to 800W (vs. 2500W of the neutral wired ones), and they need a minimum load to be able to draw any power at all.

Probably not a good idea to put variable loads on these no-neutral switches. I tried mine with dumb LED bulbs of questionable quality, and they flicker while they are on.

[ryanbeaton]

@Nephiel Re: flicker, how about something like this
https://aeotec.com/z-wave-low-voltage-dimmer

[Nephiel]

@ryanbeaton Thank you, didn't know about those, and it looks like they just might fix the flicker. I will try them.

[timdonovanuk]

I'm using the double switch - one side only has 1 smart bulb, the other 2. It shouldn't be anywhere near any max ratings for the switch!

Edit: I also cannot replicate the issue every time. For a brief time I had a nodered flow that would exhibit the issue about 50% of the time. But I've reworked the flow a bit, and the issue seems to have lessened, (happens more like 10% of the time now).

[Nephiel]

I'm using the double switch - one side only has 1 smart bulb, the other 2. It shouldn't be anywhere near any max ratings for the switch!

IMHO the issue is the min rating of the no-neutral versions, combined with bulbs with internal electronics. I will try the Aeotec bypass on some of my QBKG04LMs and report back.

[HAKostya]

Hi, I've been running zigbee2mqtt + homeassistant in docker for a couple of months now and everything was working great but a couple of day ago I rebooted my server and all of a sudden I lost 2 QBKG04LM switches (single button, no neutral) while the other 3 switches WITH neutral work just fine. Simple re-join fixed one of the switches but I'm no longer able to add another one - it just doesn't join the coordinator. I.e. it might connect once showing this in log:

```
3/18/2019, 7:30:45 PM - info: New device with address 0x00158d0002a9baad connected!
3/18/2019, 7:30:45 PM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_connected","message":"0x00158d0002a9baad"}'
3/18/2019, 7:30:45 PM - info: MQTT publish: topic 'homeassistant/switch/0x00158d0002a9baad/switch/config', payload '{"payload_off":"OFF","payload_on":"ON","value_template":"{{ value_json.state }}","comman
d_topic":"zigbee2mqtt/0x00158d0002a9baad/set","state_topic":"zigbee2mqtt/0x00158d0002a9baad","name":"0x00158d0002a9baad_switch","unique_id":"0x00158d0002a9baad_switch_zigbee2mqtt","device":{"identifiers":
"zigbee2mqtt_0x00158d0002a9baad","name":"0x00158d0002a9baad","sw_version":"Zigbee2mqtt 1.1.1","model":"Aqara single key wired wall switch (QBKG04LM)","manufacturer":"Xiaomi"},"availability_topic":"zigbee2
mqtt/bridge/state"}'

but it doesn't work and I see this in debug:
`3/18/2019, 7:34:50 PM - debug: Received zigbee message of type 'endDeviceAnnce' with data '"0x00158d0002a9baad"' of device 'lumi.ctrl_neutral1' (0x00158d0002a9baad)`

I've upgraded stick fw to the latest fw, tried to re-join it multiple times with no luck. It does connect to Xiaomi gateway with no issues and keeps working just fine but I can't get it to work with the z2m stick. 

## My configuration
<details><summary>Expand</summary>
<p>

```3/18/2019, 8:28:23 PM - info: Starting zigbee2mqtt version 1.1.1 (commit #577bb0d)
3/18/2019, 8:28:23 PM - info: Starting zigbee-shepherd
3/18/2019, 8:28:24 PM - info: Error while starting zigbee-shepherd, attemping to fix... (takes 60 seconds)
3/18/2019, 8:29:24 PM - info: Starting zigbee-shepherd
3/18/2019, 8:29:32 PM - info: zigbee-shepherd started
3/18/2019, 8:29:32 PM - info: Coordinator firmware version: '20190223'
3/18/2019, 8:29:32 PM - info: Currently 14 devices are joined:
3/18/2019, 8:29:32 PM - info: kitchen_wall_switch (0x00158d000275a920): QBKG11LM - Xiaomi Aqara single key wired wall switch (Router)
3/18/2019, 8:29:32 PM - info: livingroom_wall_switch (0x00158d0002a55154): QBKG12LM - Xiaomi Aqara double key wired wall switch (Router)
3/18/2019, 8:29:32 PM - info: livingroom_temphum (0x00158d000244789f): WSDCGQ01LM - Xiaomi MiJia temperature & humidity sensor  (EndDevice)
3/18/2019, 8:29:32 PM - info: bathroom_fan (0x00158d0002ab4a08): QBKG04LM - Xiaomi Aqara single key wired wall switch (Router)
3/18/2019, 8:29:32 PM - info: kitchen_temphum (0x00158d000239aea1): WSDCGQ01LM - Xiaomi MiJia temperature & humidity sensor  (EndDevice)
3/18/2019, 8:29:32 PM - info: bedroom_temphum (0x00158d000239a95e): WSDCGQ01LM - Xiaomi MiJia temperature & humidity sensor  (EndDevice)
3/18/2019, 8:29:32 PM - info: bathoroom_wall_switch (0x00158d0002a2188c): QBKG12LM - Xiaomi Aqara double key wired wall switch (Router)
3/18/2019, 8:29:32 PM - info: kitchen_button (0x00158d000214ec65): WXKG01LM - Xiaomi MiJia wireless switch (EndDevice)
3/18/2019, 8:29:32 PM - info: single_button_switch (0x00158d0002828a79): WXKG03LM - Xiaomi Aqara single key wireless wall switch (EndDevice)
3/18/2019, 8:29:32 PM - info: bathroom_temphum (0x00158d0002454a3f): WSDCGQ01LM - Xiaomi MiJia temperature & humidity sensor  (EndDevice)
3/18/2019, 8:29:32 PM - info: door_sensor (0x00158d000238709d): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice)
3/18/2019, 8:29:32 PM - info: balcony_temphumpress (0x00158d000233fb45): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
3/18/2019, 8:29:32 PM - info: smart_socket (0x00158d00024d886f): ZNCZ02LM - Xiaomi Mi power plug ZigBee (Router)
3/18/2019, 8:29:32 PM - info: 0x00158d0002a9baad (0x00158d0002a9baad): QBKG04LM - Xiaomi Aqara single key wired wall switch (Router)

EDIT: Updated to zb2mqtt 1.2.1 and latest FW + installed xiaomi smart socket (that acts as a router) within 1,5m radius from the switch. Now I can pair the switch and control it for 5-10 mins and then is stops working again. I can delete the device by sending mqtt message on zigbee2mqtt/bridge/config/remove topic and then add it re-pair it again - still the same:( if I restart z2m the switch doesn't come up... New messages in log

3/19/2019, 8:16:32 PM - info: Zigbee publish to device '0x00158d0002a9baad', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - 2
3/19/2019, 8:16:50 PM - error: Zigbee publish to device '0x00158d0002a9baad', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - 2 failed with error Error: AF data request fails, status code: 183. APS no ack.
3/19/2019, 8:16:50 PM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 183. APS no ack.","meta":{"entity":{"ID":"0x00158d0002a9baad","type":"device","friendlyName":"0x00158d0002a9baad"},"message":"ON"}}'

Any ideas on what else can I try to make it work are welcomed!

[urusha]

Getting the same errors with QBKG03LM, 20190223, 1.2.1

PM Failed to ping 0xXXX...

and when trying to control from UI:

Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.

Pressing buttons works fine.
Decoupled automations doesn't work.
Works fine when connected with gateway2.
Rejoin helps, but only for some time / until restart of hassio.

[mayrp2001]

Changed to zigbee2mqtt edge as suggested and still getting the same error.

zigbee2mqtt:error 3/30/2019, 7:24:22 AM Zigbee publish to device '0x00158d0002ec227d', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - 2 failed with error Error: AF data request fails, status code: 240. MAC transaction expired.

[itsmepetrov]

Hi, I've tried to make some research for this switches in the neighboring project and found some interesting details:

• Unreachable lumi.ctrl_neutral2
• lumi.ctrl_neutral2 switches still lost
• Xiaomi Aqara QBKG03LM switch not available after deconz reboot

The switch seems stuck in a loop, where it requests the attributes of the Time cluster from the coordinator, but doesn't receive any answer. After a couple of times, it gives up, leaves and rejoins the network, connecting to a different parent. deCONZ insists that the node is known by 0 neighbours.

According to this issues we need to add some changes to support this switches:

• Provide Time cluster

[tb-killa]

https://github.com/Koenkk/zigbee2mqtt/issues/1214#issuecomment-471914038

[daddvok]

Also there is such a problem with switches QBKG03LM and QBKG04LM
In my case, fortunately, from UI they turn on and off successfully, but with constantly different delays, it can be half a second, or maybe 5 seconds
after successfully turning on/off the switch from UI in the log i see:
PM Failed to ping 0x00158d0002e69da0 - once a minute

[antst]

I'm using the double switch - one side only has 1 smart bulb, the other 2. It shouldn't be anywhere near any max ratings for the switch!

IMHO the issue is the min rating of the no-neutral versions, combined with bulbs with internal electronics. I will try the Aeotec bypass on some of my QBKG04LMs and report back.

Did you try bypassing?

[Nephiel]

I'm using the double switch - one side only has 1 smart bulb, the other 2. It shouldn't be anywhere near any max ratings for the switch!

IMHO the issue is the min rating of the no-neutral versions, combined with bulbs with internal electronics. I will try the Aeotec bypass on some of my QBKG04LMs and report back.

Did you try bypassing?

I received the Aeotec bypasses recently, didn't have a chance to try them yet.

[antst]

Problem rather in
1) sudden change of load either detected as possible shortcut and automatically disconnected or switch just react too slow and got underpowered.
2) just not enough of load (not max, but rather min)

For second one I have very nice observation. When switch has minimal load on my case (TRADFRI gu10 bulb on minimal brightness) it goes ok for 12-16 hours, but then it suddenly start to blink time to time and more often with time and stops to react on button press. If I add second bulb (dumb led) then power recovers, supercap (?) inside of switch charges and it can go more hours again.

[neilvangeffen]

I just want to add to this,

Im using the no neutral 2 switch one, and have it hooked up on my desk with an extension cord for testing and going to a little 5W LED bulb and it will shut off after x amount of time sometime...
Interesting thing was though, that i logged this in zigbee2mqtt
4/24/2019, 9:57:43 AM - warn: Message without device!

Not sure if relevant, but thought i'd share

[antst]

I added simple bypass in form of capacitor (0.33 uF 400V) and it looks like it solves the issue

[antst]

In order to try to figure out why it looks like my network is busy, I removed all devices, moved coordinator to channel 15 and started to add one by one while sniffing.
Turned out that QBKG03LM spam network. My capture is full of those 12-byte packets from QBKG03LM (source 0xedc5), I tried to add second one and number of packets from both if them. (added source 0x5412 on second snapshot).

What is it and where should I look further?

[antst]

Can say that after 2 days with simple capacitor as bypass it functions perfectly. And cost nearly nothing.

[itsmepetrov]

@antst did you manage to solve delay/latency for on/off commands using bypass?

[antst]

Nope. Only problem of coexistence of aqara switch and smart bulbs, when change bulb brightness drives switch crazy.

Latency seems to be related to spamming Zigbee network by aqara switches with data requests which are never answered by coordinator.
Maybe it is time-cluster related. This I can’t say for sure. But by the time switches spam everything, it just simple packets with data request command (1-byte command) without anything else meaningful in the packet.
Taking into account that it functions perfectly on conbee/deconz and that the only difference, most likely, implementation of time cluster in deconz, i’d suspect we are out of luck until time-cluster is implemented in z2m.
This is discussed in the issue #1214

[itsmepetrov]

Yes, it tries to read time cluster every ~ 2 seconds and doesn't get response, but if we add time cluster it won't resolve the issue of delay, it will decrease it but will not remove completely. I still have the small delay ~ 1 second on Aqara Hub, and it looks like it's hardware specific issue

[antst]

1 second delay is much better than whole network barely responding when you have 4+ switches )

Plus, I’ve seen video with deconz, it’s nearly instant. So it could be better than 1 second.

[itsmepetrov]

@antst it depends, sometimes it's blazing fast sometimes not, looks like there is internal timer for event handling in this switches, and I've also seen how it works with deconz and I can say it's nearly similar to aqara hub.

[Koenkk]

• I implemented the time responses (#1214) and verified it works correctly using sniffing.
• After implementing this I found 2 strange things:
  
  
  
  • The QBKG03LM still spams the dataRequests (which are not zigbee packets but 802.15.4 packets).
  
  
  • The QBKG03LM still queries the time from the coordinator every +- 2 mins.
  
  
• Figured out it was time to grab my Xiaomi gateway to see what's going on here.
• To my surprise both the dataRequests spam and 2 min interval time requests also happened with the original Xiaomi gateway.

On the above findings, I assume that the behaviour regarding the QBKG03LM and QBKG04LM is OK now. This can be tested in the latest dev branch. Can somebody verify that the issues have been solved now?

[urusha]

@Koenkk I'm running your patch since it was published, have 5 units of QBKG03LM/QBKG04LM. I haven't lost any of them (no need to re-pair) from that time, thanks! Before the patch I have to re-pair at least one of them almost every day. But lags still persist, sometimes it takes 2-4 seconds to switch. Also, one day one unit stopped to respond, and I saw errors, like this:

Zigbee publish to device '0x0015...', genTime - readRsp - [{"attrId":0,"status":0,"attrData":609974935,"dataType":226}] - {"direction":1,"seqNum":107,"disDefaultRsp":1} - 1 failed with error Error: AF data request fails, status code: 233. MAC no ack.

, but after some amount of time it started to work again without any manipulations.
One error that I've just catch (device from the log was OK, it may be connectivity issue):

Zigbee publish to device '0x0015...', genTime - readRsp - [{"attrId":0,"status":0,"attrData":609972348,"dataType":226}] - {"direction":1,"seqNum":208,"disDefaultRsp":1} - 1 failed with error Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.

So, there are still problems with these switches, but at least they are working most of the time for me now! If I face the described conditions again, I will leave more info here. Thanks!

[funcasta]

@Koenkk I'm running your patch since it was published, have 5 units of QBKG03LM/QBKG04LM. I haven't lost any of them (no need to re-pair) from that time, thanks! Before the patch I have to re-pair at least one of them almost every day. But lags still persist, sometimes it takes 2-4 seconds to switch. Also, one day one unit stopped to respond, and I saw errors, like this:

Zigbee publish to device '0x0015...', genTime - readRsp - [{"attrId":0,"status":0,"attrData":609974935,"dataType":226}] - {"direction":1,"seqNum":107,"disDefaultRsp":1} - 1 failed with error Error: AF data request fails, status code: 233. MAC no ack.

, but after some amount of time it started to work again without any manipulations.
One error that I've just catch (device from the log was OK, it may be connectivity issue):

Zigbee publish to device '0x0015...', genTime - readRsp - [{"attrId":0,"status":0,"attrData":609972348,"dataType":226}] - {"direction":1,"seqNum":208,"disDefaultRsp":1} - 1 failed with error Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.

So, there are still problems with these switches, but at least they are working most of the time for me now! If I face the described conditions again, I will leave more info here. Thanks!

I'm having the exact same issue. I'm running the latest firmware and it's working much better (I don't need to pair the switches all the time), but sometimes it takes several seconds to get the commands, and some other times I'm getting the "AF data request fails, status code: 205." error. BTW, I'm getting "Failed to ping 0x00..." in the log all the time.

[Nephiel]

Can say that after 2 days with simple capacitor as bypass it functions perfectly. And cost nearly nothing.

I finally tried the AEOTEC bypass, it seems to help with the flicker issue.

[Nephiel]

Question: Since these switches cannot act as routers, is there any reason they're recognized by Z2M as being of type Router instead of EndDevice?
What would happen if I were to replace "type":"Router" with "type":"EndDevice" by hand in my devices.db for these switches?

[antst]

After I installed 0.33uF 400V capacitors, I didn’t have single issue. Much cheaper than AEOTEC bypass.

[voynovia]

After I installed 0.33uF 400V capacitors, I didn’t have single issue. Much cheaper than AEOTEC bypass.

can I learn more how to connect a capacitor?

[NewFolk]

Hello,
I am on "version":"1.4.0","commit":"6b75465","coordinator":20190425.
And my QBKG04LM does not work too.
Some times i see Failed to ping
some times genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - 2 failed with error Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.

[funcasta]

It's weird, but I added a Xiaomi socket (which acts as a router) to my network, and now all the switches are working fine (although I can see the ping error in the log file from time to time)

[NewFolk]

@antst How do you connect capacitor?

[Nephiel]

@voynovia @NewFolk in parallel with the bulb. Make sure the capacitor has no polarity (polypropylene) and has the correct ratings, it can be dangerous! I'd ask an electrician, to be safe.

@NewFolk The error 205 is probably related to issue #1536.

Any ideas about https://github.com/Koenkk/zigbee2mqtt/issues/943#issuecomment-491527487 ?

[antst]

About speed. I find strange thing. I finally got stable setup, and I see that some of my switches are stably fast and some stably slow. And there is no correlation on signal level, hops etc/
But for the fast ones line in database.db is shorter

[antst]

No, that's not true.
But what is true is that "fast" ones were at some point attached to aqara hub (and possibly got firmware update), while slow ones were never part of aqara. And this is 100%.

EDIT: I tried to add one of slow switches to aqara hub and then turn off aqara hub (without removing switch from it) and repair to Z2M....and it became fast!

[antst]

But there is something else, we miss with those switches.
When they are connected to aqara hub, they ignore long-press on buttons, which normally force them to re-pair, while hub is online. And I'd love to have the same for Z2M. Very good with the kids.

[antst]

We need to sniff what aqara hub tells to those switches on first pair (supposedly hub alter something, and this removes delay, and this is now firmware update) to implement the same in Z2M.
But while I was experimenting, I am out of "slow" switches now.

[urusha]

I could sniff, but as I understand I need the network key and the channel of my aqara gateway, how can I get this info?

[antst]

If you use Wireshark, there are plenty of descriptions. But it must be switch which was never connected to aqara hub

[urusha]

Ok, I've got the key. But my prod network seems to be on the same channel as the test one, so if there is no way to filter out the prod network, I have to sniff in another place to get a clean dump, I'll try to do this tomorrow,

[antst]

Do it just on different channel!

On 26 May 2019, at 13:10, urusha [e-mail] wrote:

Ok, I've got the key. But my prod network seems to be on the same channel as the test one, so if there is no way to filter out the prod network, I have to sniff in another place to get a clean dump, I'll try to do this tomorrow,

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[urusha]

I don't think there is a way to change xiaomi gateway channel... And repairing all prod devices is not an option for me.

[antst]

By the way, once I had coordinator running rock-stable, I see that i still experience random switches off. But now, with capacitor, it is not that lethal, it doesn't hang and doesn't loose connection to the gateway and does not require reset/repair. And I think this time it is not related to the power.
But still, after few hours "ON", typically about 3-4 hours, it turns off. Not always though. And you can immediately turn it on from zigbee.
And I don't think that this "off" even is reported immediately.

[urusha]

Here is the dump. Lags persist with Xiaomi Gateway v2 (1.4.1_167). Switch spams the network with IEEE 802.15.4 Data Requests (2-3 per second), and this could be the reason of the lags. @antst do you see these packets with your switches (may be there are several versions of these switches and some of them don't spam)?
pair.pcapng.zip

[antst]

Keep observation over my switches.
Now, with stable coordinator, I see that they turn off always somewhere between 3 and 4AM ) like timer )

[antst]

Here is the dump. Lags persist with Xiaomi Gateway v2 (1.4.1_167). Switch spams the network with IEEE 802.15.4 Data Requests (2-3 per second), and this could be the reason of the lags. @antst do you see these packets with your switches (may be there are several versions of these switches and some of them don't spam)?
pair.pcapng.zip

Yes, I see those also. And it is the same with xiaomi coordinator. Looks like bug in firmware of those switches.

[antst]

Argh. Looks like there are 5 packets per second from switch (and 5 ACKs from coordinator). 5 switches results in steady flow of 50 unnecessary packets per second! Damn aqara.

[Nephiel]

@antst Does the spamming happen with switches that have been connected to the Aqara gateway (and updated their firmware by doing it)? Also, does it happen with both 03LM and 04LM models?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[directman66]

Hey. QBKG03LM switches could previously be controlled through the topics
zigbee2mqtt/0x00158d00022bc3ab/left/set by sending the payload {"state_left": "OFF"} and zigbee2mqtt/0x00158d00022bc3ab/right/set by sending the payload {"state_left": "OFF"}.

Everything worked well. But after updating to version 1.7.0 the management topics changed. Now you can control it only by sending zigbee2mqtt/0x00158d00022bc3ab/right/set by sending the payload {"state": "OFF"}. I have already adapted the code and control methods when the result of the command corresponds to the command being sent. I do not like that sending the state parameter I see the result in the state_right topic. Can I add an old control option in addition to the existing one?

[pmuntyanu]

I had an issue w/ my aqara switch which was turning off(w/o any notice) after setting up the decoupled mode and turning off the bulb. After this, I could only remove the bulb and install it again to return the switch to life. Also, the switch was turned on sometimes(relay), even during the night. So to fix it, I (followed @Nephiel 's advice)bought and installed the Fibaro Dimmer bypass 2. Because the issue was appearing immediately, I should have seen it, but do not so far.

My setup:
Zigbee2mqtt 1.9.0
CC2530 CC2591
aqara switch
bypass

[ArkadiuszNiemiec]

@antst I have soldered the 0.33 uF capacitor to AC wires inside my LED lamp but after one day the relay switched off. My automation was able to turn it on back but only after 7 minutes. Is this fix still working for you? No disconnects?
Edit: I have calculated the reactance of this capacitor for 230/50 and it should behave as the equivalent of 5 W load. This should be enough for any switch.
Edit2: Oh, I have just read your newer replay. So it still disconnects for you...

[ArkadiuszNiemiec]

@pmuntyanu How is the situation with Fibaro Bypass? Does it still switch off from time to time?
Maybe there's something more than a capacitor.

[workinganimal]

I am not sure if this helps but i found out a thing about the QBKG03LM self turning off. I just changed my home and discovered that the QBKG03LM started to turn off randomly once in a week or so. I have 2 of these switches and i used the same switches in my last apartment but there i didn´t have any problems with them. The key difference here is that in my last apartment the switches had different brakers and also where on different phases. Now they have the same braker and are on the same phase and started to turn off randomly. This means that they are somehow interfering which each other. Does anybody have an idea how to resolve this?

[radudami]

I'm not sure if it's related, but ever since I've added the IKEA TRÅDFRI signal repeater to the network none of the switches have turned off by themselves. It still happens if the switch is on and I turn of the smart bulb at full power, but I guess this is a different issue.

[ArkadiuszNiemiec]

@radudami I have 4 switches connected though IKEA TRADFRI and all turns off randomly, even when the lamp is off and even with capacitor/by passes connected in parallel to the lamp :(

[ArkadiuszNiemiec]

They have just released a new version of their switches: https://www.gearbest.com/blog/tech-news/xiaomi-aqara-smart-wall-switch-d1-release-make-lighting-smart-12003

[alexbohariuc]

Are there any plans for adding the D1 wall switches or are they compatible (even if not listed)? I’m intending to buy around 10 wall switches and i kinda like the design of D1.

[Koenkk]

@alexbohariuc some are already supported in the latest dev branch

[mattydanby]

... Now they have the same braker and are on the same phase and started to turn off randomly. This means that they are somehow interfering which each other. Does anybody have an idea how to resolve this?

I started with a QBKG03LM and used both switches in a decoupled mode, this worked without issue including resets for months.

I then added a QBKG12LM (with a permanent live) on a separate RCBO circuit breaker but on the same phase. I am able to reset this and configure couple/decoupled modes for both switches. However now I experience the following issues on the 03LM even if the circuit breaker is off for the new 12LM.

1) The 03LM will not reset to try a re-join.

2) Once the mains supply is on the light powers on and I can see both switches have power. This will remain regardless of any other device state or activity for weeks. However as soon as I switch off the a light attached to the 03LM (decoupled) the 03LM powers down (blue status lights go out).

3) a- In this state the light is still powered but the switches do not respond via HA and as soon as I switch on the attached light via HA, the 03LM reboots (audible relay click is heard) the light switches off and approx. 1 minute later I can power on the 03LM via HA the light switches on!

3) b- In a coupled configuration the same occurs but occationally the light looses power so I can't switch it on. But i can turn the light on/off via HA but when off the blue status lights both go out and then on again with the light operation.

I hope that makes sense, does anyone have the same experience?

Any thoughts @Koenkk ?

I assume the D1's could have similar issues.

[winterscar]

Bump. I get random relay turn-offs with the two switch no neutral xiaomi wall switch.
Tried with the fibaro bypass and that didn't fix anything for me.