Just saw this in my logs. Might it be an unsupported temp/humidity version? :
Unhandled Event PLEASE REPORT TO DEV - description:catchall: 0104 0402 01 01 0040 00 BE77 00 00 0000 01 01 | msgMap:[raw:catchall: 0104 0402 01 01 0040 00 BE77 00 00 0000 01 01 , profileId:0104, clusterId:0402, clusterInt:1026, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:BE77, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[]]
This is just a broadcast message that can be ignored, it has been added to the next release. Thank you for reporting, which model is this?
It's a Xiaomi temp/humidity, round with a push button (not recessed).
Ok, I've never seen them send this before. Next release this will be filtered.
I recently moved my 3 buttons from the Mi Home gateway, just to try things out, and all 3 dropped off the zigbee network within 12 hours. They are spread round the house so I'm pretty sure that mesh is not the problem.
Model number is WXKG01LM.
I haven't done any investigations yet but was just wondering if anyone else has seen issues with these devices.
Thanks.
EDIT.
Found this in the past logs for one of the devices.
If you’re still experiencing issues, @gavin_robinson, I would bet my cat (I don’t have one) that it’s the wired Aqara wall switches giving you trouble. On my network things would randomly drop and stop responding. I took @markus advice to try without the wall switches in the network and everything is now working perfectly, including all of my Xiaomi battery devices alongside AlertMe and Tradfri kit.
I’m going to wait for his driver and keep them off this network for now. To stop them trying to reattach, because I can’t turn them off, I had to change Zigbee channel.
The setup is so reliable now I’m tempted to replace some physical switches with Xiaomi Aqara wireless wall switches and wire the ceiling lights on permanently with Tradfri lamps.
What other devices do you have on your Hubitat mesh? I have the WXKG03LM and WXKG11LM, so I don't have a direct comparison, but my recent experience just above has been that other, seemingly compatible, devices have caused issues.
My motion sensors, contact sensors and humidity/temp sensors, Xiaomi and Aqara, are rock solid. It's just these darn buttons. All devices are spread throughout the house which leads me away from the mesh.
This is why I asked specifically about the buttons.
I'll crack it. 
EDIT. One of the buttons is now holding up ok. It's been 18hrs and all is good.
Getting closer. 
EDIT 2. I even have a temp sensor in a freezer in my detached garage that is working brilliantly. I didn't realise they worked at -16.8 C!
While I was running these drivers I did have some issues with the gyro enabled button, it was the only thing that dropped regularly (couple of times a week, sometimes) while the motion and contact sensors were solid. I've since switched to @markus's driver release, it seems to have solved my issues as the button has been fine for nearly a month. In short, these drivers were excellent for everything except the button but I couldn't tell you why.
Just an update on my button issue.
Paired one up yesterday afternoon. Been working fine since.
Paired second one up this morning. Been working fine since.
Paired third one up this lunchtime. Been working fine since.
Maybe it was something to do with pairing them all up together. Who knows. They work and that is all that matters. (Tempting fate I know)!!!!!!!!!!
Thanks for the great drivers @markus.
I will continue to add more devices but at a slower rate. I love the presence capability.
I just thought I would post an update on here about this humidity/temp sensor.
@markus has released a series of drivers that include a "present/not present" capability.
These drivers will also try to get the device back on line should it drop off of your zigbee network.
As I wanted to try and use this capability on this device, Markus advised me to try his "Zigbee - Sonoff Temperature & Humidity Sensor".
I had a few issues initially but that was probably due to me playing with different drivers trying to get the presence to work.
When I changed to this driver, then did a re-pair of the device it worked and has been working faultlessly for the last 24 hrs.
I just thought I would post this info in case anyone else wants to try Markus's driver and get the facilities that his drivers provide.
Thanks.
EDIT: I was using the "Konke temp" driver mentioned in this post and this too was working faultlessly with no issues. Me being just wanted that little bit more.
I also have 2 of the Blitzwolf devices and I am also running @markus drivers and they have been working well so far, have had them connected for about 2 weeks now.
Has anyone had any luck including the Aqara WS-USC02?
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:
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.
Download the Hubitat app
