I just attempted to add one of these as well with no luck. I can use the device on the generic Zigbee driver and it'll turn on and off, but it doesn't work with any other driver that I can tell.
Have you tried it with my Aqara Wall Switch driver?
I haven't added support for Aqara WS-USC02 specifically, but it shouldn't be hard to do (it may already support it) since that driver already support every other Aqara Wall Switch. If it does work, please post your device fingerprint. It complete one can be retrieved by using the Get Info command in my Generic Zigbee Device Toolbox driver.
The drivers in this thread are unmaintained since @veeceeoh doesn't come here anymore (last visit back in February). For currently maintained drivers see this thread:
2 Likes
Thanks but I don't think that worked. The device doesn't have on/off buttons in the settings page and this is in the logs
dev:3542020-07-27 07:37:46.996 pm warnUnknown model (lumi.switch.b2laus01) - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: 10F302000032050042146C756D692E7377697463682E62326C6175733031, dni: 10F3, endpoint: 02, cluster: 0000, size: 32, attrId: 0005, encoding: 42, command: 01, value: 146C756D692E7377697463682E62326C6175733031 | parseMap:[raw:10F302000032050042146C756D692E7377697463682E62326C6175733031, dni:10F3, endpoint:02, cluster:0000, size:32, attrId:0005, encoding:42, command:01, value:lumi.switch.b2laus01, clusterInt:0, attrInt:5]
dev:3542020-07-27 07:37:46.990 pm warnUnknown model (lumi.switch.b2laus01) - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: 10F302000012040042044C554D49, dni: 10F3, endpoint: 02, cluster: 0000, size: 12, attrId: 0004, encoding: 42, command: 01, value: 044C554D49 | parseMap:[raw:10F302000012040042044C554D49, dni:10F3, endpoint:02, cluster:0000, size:12, attrId:0004, encoding:42, command:01, value:LUMI, clusterInt:0, attrInt:4]
dev:3542020-07-27 07:37:46.468 pm infoNo VALID lastCheckin event available! This should be resolved by itself within 1 or 2 hours and is perfectly NORMAL as long as the same device don't get this multiple times per day...
dev:3542020-07-27 07:37:46.447 pm infoRecovery feature ENABLED
dev:3542020-07-27 07:37:46.340 pm infogetDriverVersion() = v0.8.1.0720
Not sure if it's still helpful but here's the fingerprint
fingerprint model:"lumi.switch.b2laus01", manufacturer:"LUMI", profileId:"0104", endpointId:"02", inClusters:"0000,0003,0004,0005,0006", outClusters:"", application:"16"
@markus -
Just an FYI. After updating to 2.2.3.118, I'm getting the following error from devices with your drivers. I won't be home until tomorrow night, so I cannot confirm if the devices are working or not, but I will let you know as soon as I can. Let me see if I can send a friend over to test motion lighting.
That is very sad to see 
There seems to be a change in platform 2.2.3 which breaks the Recovery feature, set the Recovery Mode to disabled if you're on platform version 2.2.3 just to be safe. I will release a version of my drivers which disables it for the time being if on 2.2.3. Devices will not be as likely to reconnect once they drop with this turned off, but at the moment there is no choice.
1 Like
I'm on 2.2.3 on two hubs, and not seeing these errors. Everything seems to be working.
1 Like
I'm happy to hear that 
Not a fun morning waking up to seeing this type of issue 
It's probably because all your devices are fine, this only happens when the driver goes into recovery mode due to finding a device to not be online.
Didn't want to say it but I don't have any either. Maybe the error is specific to some particular device?
2 Likes
Yes, those that have dropped and my drivers start trying to get back online As long as all is stable and no recovery-events are needed all seems to be fine. I will push a new driver update for all my drivers disabling that feature on 2.2.3. The update will be pushed in a few minutes.
3 Likes
This really sucks. You do something to help us keep devices connected and the platform has to block it.
Do we know if HE did anything positive to enhance zigbee stability or stop the frantic PAN ID changes in this last 2 2.3 update?
1 Like
At this point it looks like an unfortunate bi-product of loads of changes in the platform, I've not had time to track it down from the driver side, I'm hoping that we will see more information in the community which will help pinpoint it. The errors that has been seen running this feature don't make sense since the limit complained about is for a type of call which doesn't happen inside that method except once. It is never repeated. The method itself is however repeated very frequently as part of the recovery process. I have some hope in sorting this out and making changes to make this possible again, even without truly knowing what in the platform screwed it up in the first place. Disabling it as I did was much about not wanting to add to all the current issues, there should be solutions down the road.
They did, they made a change that should help with that, it is not perfect, but they know that and will work on improving it when they have time.
5 Likes
@markus some more FYI. I installed 2.2.3.118 as soon as it became available. Also installed 2.2.3.119 pretty early as well. I have not experienced the errors encountered by @aaiyar. Because I have not had these errors I have held off on installing your updates. Maybe I'll see something that might help. Sure your recovery routines bash the event stack a bit but HE has never complained even with all the other normal events going on. Even if I try the insane mode on 2 devices at once. I don't believe the recovery mode is broke. More like there is something else generating a lot of events as well. The combination results in the error. If so, over time, the error should be intermittent. You should also see recovery's that don't result in errors. Ok I think I have rambled on enough. My hub is C5.
3 Likes
Thank you for chiming in on this 
I agree, this is a combined issue caused by system problems. I have a possible fix that will just let my drivers back off if the system is experiencing these types of issues and only then disable the feature until the system is back to normal. I've not had time to write the fix yet though, but it will be there.
2 Likes
veeceeoh thank you for the temp/humidity driver I am in the process of moving from ST to HE and have a bunch of these sensors. The one thing I miss from the ST driver is the display as integer it make my smart panel cleaner. Any chance this could be added or is there something in the code I can change?
1 Like
As far as I understand it @veeceeoh is not supporting these drivers anymore or has been MIA for a period of time. That said @markus is supporting many Xiaomi Aqara devices over on this thread.
2 Likes
Thanks
1 Like
Just a note for people reading this thread, his last log in was Feb 2020. I hope he is OK, but I think that these are possibly abandoned at this point. Hopefully he returns at some point, he made some valuable contributions here.
That is probably the way people should go at this point. As time goes on, Hubitat changes may, and probably will, cause issues with drivers that are not kept up to date. Markus has some excellent drivers, so I would encourage people to try those instead.
5 Likes
There's any intention from the Hubitat team to have these drivers built in? These aqara sensors are amazing, they are Compact, Nice Looking and Cheap.
1 Like
