So do I, unfortunately that’s not a strategy for everybody. I agree you don’t need to provide fixes for every broken device out there, but the cheapmost devices you really should get working because those are what users buy and want to use, it’s a real knockout criterion if those don’t work (without hassle), causing people to even walk away from OH to the competition.
How best to implement that … well, as a pro user I prefer to have options to tweak things over not having options, but I doubt you need the BFG caliber guns for this. We have a standard after all so there should not really be that much need for exceptions, let alone user modifications.
Either way I’d always leave any design decision on that to @chris.
As always, it’s about time and money. I personally don’t have the time to try and get all these non-standard devices working. I’ve purchased quite a few devices in the past to do this, but it becomes expensive.
I agree - it would be great to support all these devices, but it would take someone else to do this - we can’t just have something that is infinitely “tweakable” - life just doesn’t work that way.
I have added a Xiaomi Motion Sensor following the advice in this thread regarding keeping awake.
model number is RTCGQ01LM
Very cheap device which I probably will not use in production.
label: LUMI lumi.sensor_motion
thingTypeUID: zigbee:xiaomi_lumisensor-motion
While the device sends motion detected it does not send a reset to OFF. There is no OFF by design. Use expire or rule to reset state to OFF at time interval to suite.
This test was direct and there are reports of issues with routing and Aqara devices.
2021-04-26 21:36:07.828 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D0006358113: Channel zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113:occupancy updated to ON
2021-04-26 21:36:07.829 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006358113: Updating ZigBee channel state zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113:occupancy to ON
2021-04-26 21:36:07.832 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113
2021-04-26 21:36:07.833 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker cancelled task for thingUID=zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113
2021-04-26 21:36:07.835 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113 in 14430 seconds
2021-04-26 21:37:11.093 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006358113: Polling [zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113:occupancy] channels...
2021-04-26 21:37:11.095 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006358113: Polling zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113:occupancy
2021-04-26 21:37:31.493 [DEBUG] [l.converter.ZigBeeConverterOccupancy] - 00158D0006358113: ZigBee attribute reports ZclAttribute [cluster=Occupancy Sensing, id=0, name=Occupancy, dataType=BITMAP_8_BIT, lastValue=1, lastReportTime=Mon Apr 26 21:37:31 CEST 2021, implemented=false]
Glad you got it working. I tested a few of these devices (different ones - temp sensors, motion, lux…) a couple of years back and had no real issues with them. They are temperamental, and are definitely a pain to get connected, and there were reports they don’t play nicely in large networks where they have to route, but I personally found they worked ok.
The key is to keep it awake through the whole process - just keep pressing the button until everything is running - in OH, it needs to be kept awake both before the thing turns up in the inbox (which should be quick), then while it still says “Unknown” in the name, then once you add it as a thing for (say) 30 seconds. This covers all parts of the initialisation process and will (hopefully) ensure success 
.
That is correct - many of these motion sensors just send an ON - you’d need to use a rule or something to set back to off after some time.
1 Like
I am sure someone would be happy to donate and have them sent to you if your open to that? or to someone who does have the time and wont take offence to getting given a $10 sensor and expected to do 8+ hours of work in return
I am looking at Aqara temp and humidity sensors and alternatives at the moment, so I may be happy to do the work IF @chris your open to having some sort of patch layer added? Probably take me 3 months of spare time to learn the binding and have a play, so keen to hear if there is an interest in adding this to the binding if your not the one doing the work?
I know this seems like a small amount of money - and it is for these devices. However I’ve spent literally thousands of pounds over the past few years buying devices. However the big issue for me is time - I need to focus on supporting the compliant devices and this of course also helps the non-compliant ones.
Of course - it’s possible to add other handlers. I would probably prefer to keep this in a separate bundle as we’ve done for the different dongles. The binding was written with this in mind.
I would prefer to avoid a really hacky “layer” that tried to be everything for everyone - those sort of things are typically difficult, and end up being convoluted and often a bit buggy. The best approach is to simply add a new device handler to support the features of the device.
However you should note that it won’t probably be possible to resolve things like keeping the device awake which is the problem mentioned earlier with the joining.
I would suggest (as I think I already did earlier in this thread) that people identify the problem they are trying to solve, and not just ask for “better support” for a device (or something like that) as it will make it difficult to work out what to do 
So can I ask what the problem with these sensors is that needs additional support adding to the binding? I’ve personally purchased these devices to test with the binding a long time ago, and they work (or at least they used to a couple of years ago). As above - I think it’s worth identifying the problem before trying to solve it - it may not exist
Just installed WSDCGQ11LM and it included and is working but I note Chris’s comment about being issues with some Aqara and routing so this might not be definitive. All my testing is direct and the Hubitat thread earlier in the thread indicates that issues depend on the router/repeater.
1 Like
I have no idea or experience to draw on, only what I have seen in multiple home automation forums that mention they break conventions. Good news you found they work.
Thanks for the heads up on the method you prefer is already done for dongles, will check it out before I place an order for any Zigbee if that is the direction I wish to take. Wording a 10 second post could have been done better as my goal was to see if you were open to changes. Thank you for all the work you put into the project/s much apricated.
When correctly written you can detect what device is being talked to and dynamically load a different handler only for that 1 device. If you do not have the problematic device, zero lines of code run from that handler and it can not cause stability issues or performance problems. Chris proof reads all changes to the binding, so you really have nothing to worry about as it would not get merged if there was any chance of it causing an issue.
Yes but when the interface to the handlers has changed to support new features a few times and all of the older handlers still need to work it starts to get messy.
As I understand it that is actually an architecture design that is less complexed than what is used today.
Suggest that you read → https://github.com/zigpy/zha-device-handlers#what-the-heck-is-a-quirk
I think it would be a good idea for openHAB to have the device handlers library for Zigbee devices as a separate bundle that is maintained in its own Git repository + bonus if could also be updated separately.
All things being equal it is only the devices that do not 100% compliant with the standard Zigbee specification that such custom converters/handlers (quirk translators) and most of those devices might only need smaller tweaks of device attributes or commands usually is something that less skilled scripters can manage contributing to, however the codebade can be intimidating if converters/handlers is not handled in its own seperate bundle
Regardless recommend see example → https://github.com/zigpy/zha-device-handlers#building-a-quirk
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.
1 Like
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.
2 Likes
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.
1 Like
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.