Xiaomi QBKG03LM and QBKG04LM issues #943
Comments
|
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. It still occasionally turns off the lights by itself, but I haven't got to the bottom of that yet. |
|
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 |
|
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 ***@***.***> 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.
|
|
@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? |
|
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 |
|
@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) |
|
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 |
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! |
|
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 ***@***.***> 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.
|
|
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 |
|
Channel could be between 11 and 26. |
LOL, that explains a lot #Facepalm |
|
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). |
|
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 |
|
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.
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. |
|
@timdonovanuk that make this issue even more interesting, do you have any none Xiaomi devices in this zigbee network? (e.g. tradfri) |
|
@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. |
|
@timdonovanuk do you also have tradfri bulbs connected to the aqara hub? (that's possible since a few weeks). |
|
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. |
That's what I thought. Thank you for the clarification.
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? |
|
@Nephiel that would indicate that the QBKG04LM/QBKG03LM just have a bad electronic design? |
|
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. |
|
@Nephiel Re: flicker, how about something like this |
|
@ryanbeaton Thank you, didn't know about those, and it looks like they just might fix the flicker. I will try them. |
|
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? |
|
If you use Wireshark, there are plenty of descriptions. But it must be switch which was never connected to aqara hub |
|
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, |
|
Do it just on different channel!
… On 26 May 2019, at 13:10, urusha ***@***.***> 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.
|
|
I don't think there is a way to change xiaomi gateway channel... And repairing all prod devices is not an option for me. |
|
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. |
|
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)? |
|
Keep observation over my switches. |
Yes, I see those also. And it is the same with xiaomi coordinator. Looks like bug in firmware of those switches. |
|
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. |
|
@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? |
|
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. |
|
Hey. QBKG03LM switches could previously be controlled through the topics 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? |
|
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: |
|
@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? |
|
@pmuntyanu How is the situation with Fibaro Bypass? Does it still switch off from time to time? |
|
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? |
|
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. |
|
@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 :( |
|
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 |
|
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. |
|
@alexbohariuc some are already supported in the latest dev branch |
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.
I hope that makes sense, does anyone have the same experience? Any thoughts @Koenkk ? I assume the D1's could have similar issues. |
|
Bump. I get random relay turn-offs with the two switch no neutral xiaomi wall switch. |
|
Almost 4 years passed since last issue update, but maybe anyone figured out the solution? My aqara d1 switches (no neural) randomly turns off and I cannot find proper solution to fix it. |
and others
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:
The text was updated successfully, but these errors were encountered: