I believe that error is created by whatever Smart App you are using for the motion → lights on automation. All non-official custom device handlers will not execute locally. What Smart App are you using? Can you provide a screen shot of the error?
Please note, however, that using the illumination reports from an Aqara Motion Sensor for this purpose may not work as expected.
The reason for this is that the Aqara Motion Sensor only sends illumination report messages when motion is detected, and the message for illumination is sent just milliseconds before the motion detected message, meaning the SmartApp may still see the previous illumination value to make its decision to turn on the lights.
For example, you set the automation to turn on lights if motion is detected and the illumination value is below 15. Here’s what could happen:
14:00 The motion sensor detects motion and reads illuminance at 25 lux
17:40 The ambient light level goes below 15, but nothing happens because the motion sensor has not detected any motion since 14:00
18:30 The motion sensor detects motion and reads illuminance at 10 lux, but the Smart App does not turn on the lights because it still sees the previous illuminance value of 25
18:31 The motion sensor detects motion again and reads illuminance at 10 lux, and the Smart App finally turns on the lights
I did a search on the SmartThings forums here and see that the message ‘Beta feature currently not supported for local execution’ is from the Smart Lighting app. It is not related to Xiaomi / Aqara devices. It will appear for any illuminance capable device.
I think all the message is saying is that if you use illuminance as a “restriction” in the “More options” section then the app will not run locally, but rather in the cloud. It should still work, however.
If you have tried setting it up and it’s not working with the Aqara Motion Sensor, then that is because of the reason I mentioned before:
To repeat: The Aqara Motion Sensor only sends illumination reports when it detects motion. It does not send illumination reports every xx minutes. Because of the order of the illumination and motion detected messages, any automation using illumination levels along with motion detected to decide whether an action should be taken may not work reliably.
I just had to delete and re-pair each of my half-dozen Aqara Door/Window sensors, as none were communicating with the Smarthings Hub. All other devices (Z-Wave deadbolts, Zigbee lightbulbs, and Aquara Temp/Humidity sensors) were fine. I could not get the device to repair without first deleting and then re-adding. Upon re-adding, two of the sensors functioned, but reported bogus -519% battery charge, so a toggle of the “replaced battery” fixed the error, but only after exiting and re-entering the android app. Is there a better approach to this scenario?
Just ordered two WXKG12LM buttons. I will try to use them as front door and back door doorbells. Let’s see how they will work. Just have to wait 2-3 weeks to get them from China. They cost 10€ piece so very cheap I would say.
Let’s separate your issues first, however, because they are completely unrelated.
Aqara Door/Window Sensors not communicating with hub
When this happens, it’s because of one of two reasons, either
their ZigBee network connection was interrupted, or
you are using ZigBee repeater devices that Xiaomi/Aqara devices are incompatible with.
In both cases, Aqara / Xiaomi devices won’t rejoin the ZigBee network when requested by the hub because they are not 100% compliant with ZigBee protocol.
There are a whole host of things that can lead to reason 1, search for ZigBee interference / signal strength, so I’ll focus on #2. Any mains-powered ZigBee device, with the exception of some ZigBee smart bulbs (e.g., Sengled), is very likely a repeater. A ZigBee repeater helps to increase the range of a ZigBee mesh network by acting like a WiFi extender: ZigBee end devices can connect to a repeater that is closer with better signal strength instead of directly to the hub.
The origin of the problem in this case is that most ZigBee repeater devices have a check-in timeout period of time that is shorter than the 50-60 minute regular check-in time of Xiaomi / Aqara devices, and when those devices finally do try to check in and the repeater asks them to follow the normal ZigBee protocol of leaving and rejoining the network, Xiaomi / Aqara devices never rejoin.
There is no way to reprogram the Xiaomi / Aqara devices, and there is no way to easily affect whether end devices choose to connect to a particular repeater device except to remove that repeater device from the network completely.
A handful of repeater devices have been confirmed to work with Xiaomi / Aqara devices: XBee Zigbee modules (see here for more info), IKEA Tradfri Outlet / Bulbs, and user iharyadi’s custom ZigBee multi-sensor repeater solution . Also in theory Xiaomi / Aqara’s own mains-powered devices like the Xiaomi Smart Plug or the Aqara Wired Smart Wall Switches should work as compatible repeaters, but I don’t own any myself and haven’t read enough reports by users to know for sure.
Do you use any mains-powered ZigBee devices? If yes, I would highly suspect them as the reason that your Aqara Door/Window sensors dropped off the network.
Incorrect battery percentage reported
Most of the Xiaomi / Aqara device handlers include some code designed to retrieve battery voltage data that is sent when the device’s reset button is short-pressed. This was added as a way to help populate the battery percentage tile when pairing the device rather than waiting for the first time the device checks in (normally 50-60 after pairing, depending on the model.)
Changes in recent SmartThings firmware updates led to some messages that don’t contain any battery voltage data being formatted differently, and as a result this code pulls out an incorrect voltage value that gets reported as an out-of-bounds percentage.
This is absolutely nothing to be alarmed about, and as soon as the Aqara / Xiaomi device performs its regular 50-60 minute check-in that includes correct battery voltage data, the percentage value will appear as normal.
I am working on a method to filter out the messages that don’t contain battery voltage data, but as I work on the device handlers in my free time, and my free time is limited, and I am not paid to do any of this work, updates to all the device handlers with a fix won’t happen immediately.
I hope this information is useful, and I’m sorry for any inconvenience. Just please keep in mind that any dropped connections of Aqara / Xiaomi devices are completely unrelated to the device handlers.
NOT blaming device handlers, I’m grateful for them, as I cannot imagine how much time it might have taken me to write something like that. The Aqara temp/humidity sensors seem rock solid, it is only the door/window sensors that have been problematic. I have no "mains powered"zigbee devices, but I do have an outlet on order from Ikea to be the repeater that everyone says helps.
I have also moved my 2GHz WiFi to channel 1, and disabled WiFi channel 11, so the router will not even fail over to 11. The Zibgee channel used by the SmartThings hub is #25, so this should eliminate any RFI crosstalk that might result from overlapping WiFi and Zigbee frequency spectrum. (WiFi 11 and Zigbee 25 overlap). If the Aqara devices “never” rejoin, then the temp/humidity sensors are the exception, as they have needed no attention at all through several Hub power-cycles and other incidents that the door/window did not “live” through, requiring a delete/re-pair process for each.
Well, Aqara / Xiaomi devices never rejoin when requested to leave and rejoin by a hub or repeater device, and the only identified circumstance leading to that is when Aqara / Xiaomi devices try to check in after a check-in timeout has passed by, as explained here.
There are very likely other cases where a hub or repeater would request an end device to leave and rejoin, but a short interruption in the ZigBee mesh network due to a hub rebooting, etc., is not one of them, based on my experience and everything I’ve read of other user’s experiences.
If you don’t have any ZigBee repeater devices, and have attempted to avoid 2.4GHz WiFi interference, then I have a couple of guesses about the reason for the connectivity issues with your Aqara Door/Window Sensors:
The signal strength between your hub and the Aqara Door/Window Sensors may be relatively weak (weaker than that of the Aqara Temp/Humidity sensors) and some change in the environment has led to the signal being too weak to maintain a consistent connection. The best solution in this case would be to add a repeater device (like the IKEA outlet you’re getting) in a location between the sensors and the hub, and then either re-pair / manually re-join the door/window sensors so that they (hopefully) choose to connect through the repeater. Only a ZigBee sniffer or preferably an XBee module would allow confirmation of the routing of those sensor, though.
The ZigBee network 32-end-device limit of the hub may have been reached. The solution here is also to add one or more repeater devices, which don’t count against that 32-end-device limit, but do allow additional end-devices to be paired to the Zigbee network.
I should note that among my over 40 ZigBee devices (over 30 of which are Xiaomi/Aqara), I have 6 each of the Aqara and Xiaomi door/window sensors along with a couple of XBee modules (which serve as repeaters in addition to allow a view of the network’s routing map) and one IKEA outlet, and I have only seen two of the Aqara Door/Window sensors drop off the network a couple of times in the past year-and-a-half. But that was most likely due to all the testing I’ve done with a few repeater devices (which turned out not to be compatible with Aqara / Xiaomi devices).
I probably have 35 odd Aqara door and motion sensors. All of them were added without any issue at all. At some point I bought a Sylvania/Lightify smart plug, to extend network to lights and motion sensors outside my garage. Last week I tried to add a few more of these door sensors. Some of them connected, some failed to connect. Some would disconnect during next check-in. Of the ones that connected, some of them didn’t work properly, will show open even when they were closed / would not update and so on. The solution that seems to be working for me was I unplugged the smart plug and re-added the new motion sensors. All of them connected successfully, left them near the hub. After 5-6 hours I plugged back the smart plug. They stayed connected for 3-4 days. Yesterday I moved the sensors to their ultimate location and will leave them there for another 3-4 days before I install them. My hub is downstairs and these new sensors are all upstairs. There seems to be no issues at all. I am keeping my fingers crossed and hope they all stay connected.
Planning to pick up a Tradfri outlet this week and will test using it instead of Lightyfi and hope my outside motion sensors as well as all my Aqara sensors work as usual. At that point maybe ditch Lightify and use only Tradfri outlets going forward.
Is there any zigbee devices that could be used as repeaters and their end device timeout could be configred? If repeaters timeout could be set near 1h (close xiaomi sensors timeout setting) would it fix this issue?
There are two variants of this plug. The model 72922 has been reported to work with Xiaomi / Aqara devices - for the most part, but model 72922-A definitely doesn’t work with them. If that “-A” model is the one you have, then I’m not surprised by the behavior you describe. For most ZigBee repeater devices, if by some luck the repeater device does allow Xiaomi / Aqara devices to stay connected, then there can be issues with the repeater not passing on messages from Xiaomi / Aqara devices. I’ve witnessed it with a Securifi Peanut Plug I tried out, and I’ve read of the same behavior with the Sylvania 72922-A Smart Plug.
Although this may seem like a good way to avoid Xiaomi/Aqara sensors from routing through an incompatible repeater, unfortunately it isn’t, because by design, ZigBee devices may choose the best available route to connect through, and that route can change at any time as conditions or the topography of the network change. For the vast majority of ZigBee devices, users have no control of how, when, or where they choose to connect to any particular repeater (or directly to the hub).
Again, I have witnessed this first hand, using an XBee module to view the map of my ZigBee network, and watched as some Xiaomi / Aqara devices decided to move to a new repeater device I added. On the other hand, I have read that with some Xiaomi / Aqara devices, they seem to be stubborn in deciding to change over to a repeater with a stronger signal, after the user moved them to their install location. The end result of that can be a weak connection to the hub and the potential for those devices being dropped off the network.
For best results, ZigBee devices should be paired in their install location so they connect via a nearby repeater if the signal is strong enough (and if that repeater has available slots for more end devices.) The only way to confirm the route they have decided to take is with an XBee module (see this thread for more information.)
I would recommend that. I have one TRADFRI Outlet and it works great as a repeater for Xiaomi / Aqara devices on my Hubitat hub’s network (which works pretty much the same as a SmartThings v2 / v3 hub’s ZigBee network) , and plenty of Hubitat hub users have found the same.
I would highly recommend reading this thread I started over on the Hubitat Community Forums which contains a lot of very helpful information on keeping your Xiaomi / Aqara devices happily connected to your ZigBee network:
In the least, make sure to read through my opening post of that thread.
To my knowledge, only the XBee ZigBee modules can be configured like that. All other ZigBee repeater devices are “hardwired” with their particular settings.
It would fix it for the most part. As I understand it, if the ZigBee network was down or inaccessible long enough, Xiaomi / Aqara devices would be dropped and then wouldn’t rejoin when requested.
Also, adjusting that end device timeout would not fix any issues that some repeaters have in simply not forwarding messages from Xiaomi / Aqara devices (as I mention in my reply to @rumrunner424, above.
Thanks for the good information. I’m still wondering what is the difference between my 10 sensors connected straight to st hub and 10 sensors connected via ikea repeaters. It really seems to be the problem that in power cut those sensors connected via ikea repeaters drops offline. Sensors connected straight to hub are always okay and back in business after hub comes back online. Why those 10 sensors connected straight to st hub are acting differently? There was power cut at weekend and hub and repeaters were offline for a 20min. After that short time ikea repeater (just one of them) was shown as offline and same happened all those sensors behind it. When pressing ikea bulb “on” from st app it turned normally on and offline status disappeared. Then I had to open those Doors with offline sensors (I manually opened Door so that status changes). They came back online after opening and closing Door manually.
If I would left them as they were after power cut, Xiaomis would have changed to offline and then they have to be manually rejoined. It might take hour or two but in the end ST app would have shown that xiaomi sensors behind that repeater are offline and they do not wake up anymore just by changing open and close status. They have to be manually rejoined. So is my problem more of a Ikea bulb/repeater problem which can’t handle power cut for some reason.
Thanks bspranger and others for this handler. Do I have to unplug all my repeaters when connecting? Could I just pair it within inches of the hub itself.
The short answer is that you should not unplug any ZigBee repeaters, and the devices should preferably be paired in room/area where they will be installed, so they connect to the nearest appropriate repeater from the start.
Are you concerned about having repeaters on your network that are incompatible with Xiaomi/ Aqara devices? What ZigBee repeater devices do you have?
I’d recommend reading posts from the past few days - starting with this post - where I explain about incompatible repeaters and also why temporarily unplugging them won’t really help avoid issues.
tldr:
{Yeah, concerned about repeaters getting in the way. I have original xaomi buttons, were working great for a while, now 2/3’s of them dropped off; really no rhyme or reason, hoping batteries. I have to start trouble shooting them, really didn’t want to connect/reconnect repeaters each time.
I have maybe 6-8 peanut plugs, all on their newest firmware. And then a couple of Samsung Plugs, 1 box 1 oval.}
That’s funny that you had just written about it so thoroughly, didn’t think to search. I know previously, the idea was to unplug everything. I was hoping I wouldn’t really have to do that over and over again and could just try to get it connected to the hub by pairing right next to it. I’ve been troubleshooting a bunch of the original wxkg01lm’s.
All of them were working perfectly for months, maybe almost a year, and recently 2/3’s of them dropped. And continue to drop. I’m guessing or hoping it’sthe batteries but it could possibly be interference with maybe 4 wyze wifi cams I’ve recently installed around the house. However, I really don’t think it’s that because buttons in the same room will either be connected or unavailable. I’ve also installed maybe 4 extra peanut plugs throughout the house possibly around the same time, I think I was also updating firmware on those plugs and the others around the same time(bought an almond router to update so I could get watt info). Again, though, specifically in 1 room where the buttons are 6 feet away, 1 stayed connected the other didn’t.
I don’t have many repeaters - by my reckoning just a Aeotec Nano Dimmer and Aeotec Siren - both are my only plugged in Z Wave devices and both are in the same room as the hub. I’ve been pairing up the motion sensor this morning and it’s… interesting but the instructions helped me through it. I had to fully reset it 2-3 times and go through the tapping the reset every 5 or so seconds to make it work. It’s now paired (right next to the hub in my case) so I’ll try moving it to another room as intended later and see if it still works.
Seeing as I’ve paid many times more than this for motion sensors i’m really hoping for success - after all there’s so much clever than can be done if you know people are moving through a room
Hello Gys, I’ve something here that I’m not able to find a solution… Here we go…
I’ve the smartthings modem completely setup with those xiaomi outlets on it using the catchall method, but what happens is that I’ve delete the location and call Samsung, they give me a new welcome code for my modem but I’ve lost everything and need to setup all sensors again, but those xiaomi… no way… I can’t use the catchall method because I think is already setup on my previous modem like everything that I’ve to exclude and include again, but, in this case of catchall… How can I manage that? I’ve tried to exclude but nothing works, tried to catchall again… no luck… any advise will be very welcome!
I just got firmware’d to 25.00026 and here is my feedback so far:
(meant in the most positive way)
The WXKG03LM (2016 revision) displays “Left pushed” in the app, when physically pressed.
The log reads: TV Aqara Switch WXKG03LM: Left button was pushed (Button 1 pushed)
This looks a little odd, given the device only have one button.
If you push the button “virtually” in the app it displays “PUSHED” correctly.
When you press the button either physically or virtually, the app keep showing the “Left pushed”/“PUSHED” message for 30 seconds, before it returns to show “RELEASED”.
This means that you can’t use the button virtually for the next 30 seconds after it is pressed.
(Don’t know if this is a Hub-, button hardware- or DH-issue. But i don’t recall seeing this before)
The round WXKG01LM works great with hold, single, double, triple, quad and shizzle-click.
It also displays is correctly in the app, but keeps showing the “pushed” message for 20 seconds.
If you press the button virtually in the app, it doesn’t show the press in the app - the push is still being recognized and sent to the hub though.
The WXKG12LM also works great with both Hold, Single, Double and Shake.
It also displays is correctly in the app, but keeps showing the “pushed” message for 15-20 seconds.
The WXKG11LM (orig) works great with single, double, triple, quad
It also displays is correctly in the app, but keeps showing the “pushed” message for 20 seconds.
If you double click the button fast, it sometimes only registers a single-click.
I have a WXKG02LM in the mail from China - i’ll get back to you when tested…
All in all it seems that all the buttons reacts faster. The different Smart Lighting rules i have set up to eg. control my smart bulbs, now turns the light on with near zero delay…
That could be the ST firmware - i know - but i would like to think that it’s because of your DH’s.
Once again: THANK YOU for all your effort on keeping the Xiaomi’s alive…!!
The new driver actually does a check of which specific model and revision is being used, and if a one-button model WXKG03LM has been detected, both the log message and event description text is customized with “Button was…” instead of “Left button was…”
I just realized that I made a small error that will make the feature not work, but only for the 2018
revision. I’d like to fix that, but let’s look at why it’s not working for your 2016 revision WXKG03LM.
One thing I want to check is whether you already had the old driver assigned to your WXKG03LM and just assigned the new driver without pairing it. If that’s what you did, then you should try opening up the preferences for it in your SmartThings Classic mobile app, and then hitting the save button. That should force the DTH to check the model again, and may fix the issue.
If that doesn’t work, the next thing to check for is whether the ZigBee model information was received by the hub when the Smart Switch was original paired. Log into your hub’s SmartThings Groovy IDE, go to the “My Device” tab, and then click on the name for your WXKG03LM in the Display Name column, so you can view its device details. Look at the Data and Current State sections.
In the Data section, you should see a model: listed, and for the WXKG03LM the ZigBee model is lumi.sensor_86sw1. Here’s an example screenshot for my 2016 revision two-button model WXKG02LM:
If you see the correct model listed there, then have a look at numberOfButtons in the Current States section. For the model WXKG03LM it should read numberOfButtons: 1. If those two pieces of information don’t match, please let me know. If they do match, there’s one more thing to try, which is to manually force the switch re-join with a new Device Network Id (DNI). Before this, while you are viewing the switch’s device details page, just make sure there’s a hexadecimal string in the “Zigbee Id” section, like this:
To manually force a ZigBee device to re-join with a new DNI, you just follow the same steps as pairing, but don’t remove it from your device list first.
So, in the mobile app, start pairing mode with “Add a Thing”, and long-press the button to put it into pairing mode also. If the one-button is like my two-button model, then after the long-press, there’s a pause before the LED flashes. One long flash means successfully connected, two flashes means unsuccessful (so try long-press the button again.) After that, the DTH should go through the initialization process again to determine the model and set the number of buttons that are used for events in SmartThings. Let me know how that goes.
Second:
That can’t be correct. The tile display and the actual button events are completely separate. Please check your “Recent Events” list in either the mobile app or in IDE to verify that you can continue to press the button and events are recorded.
However, the tile display should not be clearing after 30 seconds. It is set to automatically clear after the last press/hold/etc. after 1 second, because it’s just for user interface display feedback purposes only. With the delays of the cloud-based execution, I normally see it clear within 2-3 seconds (I just tried it now and it took about 2.5 seconds), but definitely never 30 seconds. That would be a SmartThings platform issue and there’s very little I can help with in the DTH.
Third:
That is just the way the WXKG11LM model hardware works. For all double-click capable Xiaomi / Aqara buttons, there is a specific timing to get the double-click correctly, a certain rhythm. The same applies to the buttons with the holding for 400ms to send a “hold” message. I hope that makes sense. Again, there is nothing I can do in the DTH to change or help that.
