It is indeed an architecture pattern but avoiding complexity in the first place is also a good option and the basis of good architecture.
Also remember if the issue is in the routing in the mesh it can not be fixed by openHAB or any application.
The good news is Aqara motion sensor RTCGQ11LM also works. Well when the connection is direct.
It has been stated many times on the forum that these devices work, and they are listed as supported in the docs. A lot of people use them, but also a lot of people find them problematic. As @robmac pointed out, that is not limited to OH - there are a lot of forums on the web that talk about this.
I’m always open to changes - but it’s best to discuss specifics.
This is true, but please note that there are limits on what can be done. If the device issues are not at the application layer (eg how it interprets attributes, then there may be little that you can do. This goes for things like routing and joining issues - you won’t be able to do a lot about this as it’s mostly managed at the network layer and therefore by the dongle - not the binding. These are the main issues people are having with these cheaper devices. Hence my earlier point that it’s best to understand the issues before getting too hung up on the solution.
This is what I propose, but please note again that there is really only a small amount of stuff that can be done. The binding already provides customisation options to add custom attributes and command handlers and about the only thing I can think of that requires more than this at the moment is the Xiaomi custom attribute that packs a load of information into a single attribute. This customisation layer was added for Deutsche Telekom / Qivicon Homebase to allow them to customise devices a long time ago already.
This sort of thing is extremely rare (I’ve only seen it in these devices) and even then most of the information is provided in separate attributes so there is not a lot that is missing, and I think no critical information (IIRC) - see below.
I certainly would not propose to rewrite the binding just for these outlying devices. I believe that most of the devices that people are complaining about here do work “fine” with the binding. Yes, joining is a pain, and there are reportedly issues with routing if the network is large, but rewriting the binding will not solve the routing issue - it may be able to improve the joining a little at the detriment to other devices.
I have personally tested a lot of these devices - admittedly a year or two back, but they worked fine. Others have also used them extensively, and they were added to the supported devices list in the docs - not by me. @robmac also seems to be having “no problems” with them at the moment, so I do believe that they will likely all still work today.
I think people are talking very generically here - “it” doesn’t work - we need to have custom device handlers - etc. But I’d really suggest to identify WHAT doesn’t work, and THEN discuss how to handle it. Writing a new system to cope with perceived issues, that is super simple for “anyone” to write handlers may not solve any perceived problems if we don’t understand the problem first 
I will try to get hold of some aqara zigbee 3 devices for testing.
Thanks - that’s much appreciated.
Can you also create a PR when you do to update the list of supported devices, and also comment on any issues you identify. There is already a section in the doc about these devices, but anything else you spot, or pointers to help those less successful than yourself, would be much appreciated.
Anyone to read, please give this post on github another thumbs up or comment
I have been testing Aqara sensors all day but results are so … unsatisfying.
The illumination sensor seems to be working but it shows to be on mains power power (it cannot be, it’s always battery powered).
The door sensor thing keeps dropping offline quickly (gets back online when I use the contact).
I’ve increased the maximum reporting period from 15mins to 4h and the poll period to 12h, need to wait to see if that helps.
The weather sensor works (but I had a lot of trouble with that on previous pairing attempts).
And just took on the last one, a brand new Aqara motion sensor.
That now I keep failing completely to pair :(.
I’ve been pressing the button all process long, some attempts more often others less but none worked.
I see packets arrive so it’s probably no RF issue.
Most of the attempts the thing does even not appear in UI as a box so I cannot promote it to thing status. Sometimes it does but it’s stuck in Unknown, no matter if I scan once or multiple times.
Then again after OH restart it’s always there in inbox, including its full name, but it does not work (thing stays in ‘unknown’ state). I understand this is related to the interrogation stage needed after promotion to thing. But I pushed the button a lot and for a long time before I’ve restarted OH (the effect being the name to appear).
Here’s one logged attempt, taken after a fresh OH restart to ensure there’s no leftovers: aqara_motion_pair_log.txt (1003.5 KB)
Please have a look.
Another attempt I made was to use Karaf openhab:zigbee ncpscan rather than GUI.
That reproduceably results in the following error the moment I reset the sensor:
2021-04-28 14:52:49.716 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=1, notRdy=false]
2021-04-28 14:52:49.889 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'Energiemanagement-7' failed: Could not cast NULL to org.openhab.core.library.types.QuantityType; line 1082, column 58, length 52 in Energiemanagement
2021-04-28 14:52:49.997 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - Sending EZSP transaction timed out after 10 seconds
2021-04-28 14:52:50.001 [ERROR] [b.core.io.console.ConsoleInterpreter] - An error occurred while executing the console command.
java.lang.ClassCastException: class com.zsmartsystems.zigbee.dongle.ember.ezsp.command.EzspNetworkFoundHandler cannot be cast to class com.zsmartsystems.zigbee.dongle.ember.ezsp.command.EzspScanCompleteHandler (com.zsmartsystems.zigbee.dongle.ember.ezsp.command.EzspNetworkFoundHandler and com.zsmartsystems.zigbee.dongle.ember.ezsp.command.EzspScanCompleteHandler are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @102372b)
at com.zsmartsystems.zigbee.dongle.ember.EmberNcp.doActiveScan(EmberNcp.java:939) ~[?:?]
at com.zsmartsystems.zigbee.console.ember.EmberConsoleNcpScanCommand.process(EmberConsoleNcpScanCommand.java:53) ~[?:?]
at org.openhab.binding.zigbee.console.internal.ZigBeeConsoleCommandExtension.handleZigbeeCommand(ZigBeeConsoleCommandExtension.java:149) ~[?:?]
at org.openhab.binding.zigbee.console.internal.ZigBeeConsoleCommandExtension.handleCommand(ZigBeeConsoleCommandExtension.java:117) ~[?:?]
at org.openhab.binding.zigbee.console.internal.ZigBeeConsoleCommandExtension.execute(ZigBeeConsoleCommandExtension.java:89) ~[?:?]
at org.openhab.core.io.console.ConsoleInterpreter.execute(ConsoleInterpreter.java:55) [bundleFile:?]
at org.openhab.core.io.console.karaf.internal.CommandWrapper.execute(CommandWrapper.java:78) [bundleFile:?]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) [bundleFile:4.3.1]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) [bundleFile:4.3.1]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) [bundleFile:4.3.1]
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) [bundleFile:4.3.1]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) [bundleFile:4.3.1]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) [bundleFile:4.3.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) [bundleFile:4.3.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) [bundleFile:4.3.1]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
2021-04-28 14:52:50.013 [DEBUG] [e.osgi.LoggingCommandSessionListener] - Command: 'openhab:zigbee ncpscan' returned 'null'
2021-04-28 14:52:50.711 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-04-28 14:52:50.713 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=6, ackNum=1, reTx=false, data=2E 00 01 18 00]
2021-04-28 14:52:50.719 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=1, ackNum=7, reTx=false, data=2E 80 01 18 00 02]
2021-04-28 14:52:50.720 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=6, ackNum=1, reTx=false, data=2E 00 01 18 00]
Finally and FWIW, when I click to remove the thing, OH keeps telling me in orange it is “removing”, waiting for the binding to confirm, but it never finishes doing so until I click to delete it a 2nd time.
z-wave all is forgiven.
You are doing the same as I did but with different results which makes me think it could be other devices on your network or slight environment factors or a different version of the device.
@NilsOF did warn us these devices were temperamental and they are certainly proving that they are.
Do you get versions showing in the properties?
I have
zigbee_stkversion 2
zigbee_datecode 20160524
zigbee_zclversion 1
hardwareVersion 2
zigbee_applicationVersion 11
It took a long time to initialise fully and move from unknown to online. I included late one evening and left it so can’t say exactly how long.
The latest T1 are very hard to get but these are new to you and I but very old design.
We are testing devices that are on an old SDK that hopefully will be replaced soon against a stick with a very recent SDK. I am not sure how backward compatible zigbee promises but these are very close to EOL so possibly not a wise investment even at the current low cost. Especially to run with a version 3 stick.
Not all but yes
Motion:
zigbee_datecode 20170627
zigbee_applicationVersion 5
Illumination:
zigbee_datecode 20191118
zigbee_applicationVersion 21
Magnet:
zigbee_datecode 20161128
zigbee_applicationVersion 3
Weather:
zigbee_datecode 20191205
zigbee_applicationVersion 5
you mean according to zigbee_datecode ? not consistent see above.
no these are version 2 zigbee. the stick is version 3 zigbee.
Aqara has already released new versions (T1) in China using version 3. Just not available to us in Europe yet but these version 2 are.
Sonoff version 3 are available.
That information you have may explain the differences in what we see. It is hard to say what is and what will not work. I bought my motion sensor last week 
Which field is the one that tells ?
Mine’s just some weeks old.
Got yours on Ali ? Not sure if you can get the China-only T1’s there.
Just ordered a Tuya switch similar to Aqara T1. Featured as ZigBee 3.0 but let’s see.
From my one version 3 device I think zigbee_zclversion.
I do not think these report but from reading they are old. I found even Amazon seller have has them reduced.
no I don’t think so yet
No then most of my devices would be version 1 Chris will know
FWIW, I got the motion sensor to work with my Conbee stick/deCONZ binding. Just takes 5-10 seconds to pair. So I guess it’s not related to the device not being awake.
I also read over at the deCONZ GitHub about issues with that sensor and there was a mentioning of some vendor proprietary attribute… don’t find it any more but if you think it’s valuable information to get this working let me know.
Also finally got this Tuya thermostat to reset and to work with deCONZ, too (just minutes after I ordered another one - gnah …).
With our zigbee binding, it complained about handlers missing (“no supported clusters found”). Will post a pairing log of that asap.
It also points to a possible compatibility issues with the firmware on the I-Tead or the lack of good tuning of the RF on the I-Tead or the power amplifier on the Conbee.
No that’s shooting at the dark. Whenever I clicked a sensor I have seen the package arriving in OH so I have no reason to believe trouble is related to RF weakness.
Well, it’s a little unfair to blame Zigbee here - these devices have known issues
I’m interested in how you draw this conclusion? I don’t personally know how the Dresden software works, but it migth not need the device to be awake as long as the OH binding does. I’ve said a couple of times that the way the binding works requires that the device be kept awake quite a long time.
which is similar to a lot of issues on z-wave and I assume would be the same on any mesh where devices fail to comply to the standard precisely
Absolutely. Due to the more closed nature of ZWave, there are less non-compliant ZWave devices and they mostly use the same firmware for the lower layers. Zigbee is built on open standards - 802.15.4 - and there are many different network layers built on this standard. Some companies use Zigbee on 802.15.4, others pick parts of Zigbee to use, but simplifying it to make it easier for their closed system. This does give “Zigbee” a bad name, and is exactly why ZWave remained closed for so long, but it’s not really a Zigbee issue - it’s just that many closes systems don’t follow all the standard, and their devices may therefore not fully work in a Zigbee system.