search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.96k stars 1.67k forks source link

Xiaomi QBKG03LM and QBKG04LM issues #943

Closed Koenkk closed 4 years ago

Koenkk commented 5 years ago

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:

jarrah31 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

aimartin commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 commented 5 years ago

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 commented 5 years ago

Channel could be between 11 and 26.

aimartin commented 5 years ago

Channel could be between 11 and 26.

LOL, that explains a lot #Facepalm

jarrah31 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

timdonovanuk commented 5 years ago

@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 commented 5 years ago

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

timdonovanuk commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Nephiel commented 5 years ago

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 commented 5 years ago

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

Nephiel commented 5 years ago

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

timdonovanuk commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Expand

```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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

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:

tb-killa commented 5 years ago

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

daddvok commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

antst commented 5 years ago

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). Untitled 6 Untitled 7

What is it and where should I look further?

antst commented 5 years ago

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

itsmepetrov commented 5 years ago

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

antst commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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.