On July 21, 2022, as part of the ongoing migration to edge drivers, we migrated devices using one of a number of Device Handlers (DTHs) including the SmartSense Motion Sensor. As reported on this thread, we learned that multiple devices using this DTH were migrated to the incorrect driver. We recognize and apologize for the inconvenience this has caused. We do a lot of internal testing prior to performing these migrations in an effort to minimize disruptions to you, our beta testers. In this case we found a new problem, and are now able to fix it so that more users are not affected in the future. We are thankful for your participation as it is deeply important to us to help ensure that more users are not affected in the future. Your communication is always valued and important to us.
Please see more information below regarding the reported incident:
Affected Population: Some hubs in the Hub Firmware Beta Group with Zigbee motion sensors using the SmartSense Motion Sensor DTH.
User Experience: Some (not all) Zigbee motion sensors using the SmartSense Motion Sensor DTH were incorrectly migrated to the Zigbee Contact sensor driver. As a result, these devices do not show motion status in the app and do not work with SmartApps or automations that use the motion sensor capability. In addition, these devices were automatically removed from any Routines that were triggering on motion.
Root Cause: Identified, due to a caching issue with the migration to edge drivers
Work around available Now: Driver Switching
Make sure that the Zigbee Motion Driver is installed on your hub. To check, please navigate to the Production Beta Driver Channel. Make sure your hub is enrolled and then click “Available Drivers”. Next, click “Install” under the Zigbee Motion Driver if it is not already installed.
In the app, navigate to the affected motion sensor device and on the device detail page open the “menu” (three-dot symbol in the upper-right corner)
Tap on “Driver” and then on “Select different driver”
Select the “Zigbee Motion Sensor” Driver and tap on “Use this driver”. Click on “OK”. Note: You might have to close and reopen the app, as we have seen intermittent issues with the menu not properly displaying on Android.
Fix any automations that were using the motion sensor capability of these devices.
Fixed Planned : SmartThings will be working on a script to migrate affected devices to the correct driver, an ETA for this is planned for next week to give us adequate time to verify the fix. Note that unfortunately we will not be able to rebuild the automations that were associated with these devices. If you had an automation associated with an affected device, you will need to rebuild the automation after we move your device to the right driver.
Once again, thank you for your involvement. We are listening and taking action.
The SmartThings Engineering team
Thanks for getting back with us @alissa.dornbos , it’s much appreciated.
@alissa.dornbos yes, thanks for some info on the problem.
More communications is good
I would suggest to create some backup tool for automations before going GA.
In addition, I think it would be better instead of automatically removing user defined routines, just to disable them (in case the device does not expose the capability, participating in automation). That way if user changes the driver later, it would require only to re-enable routine, instead of creating it.
The following community FAQ explains:
FAQ: Why does the IDE list “placeholder” for my device? Can I change that?
Hi @alissa.dornbos, i just wanted to let you know that i had 3 more Zigbee switches go offline yesterday evening that required resetting and rejoining even though their last update were just a few seconds to a minute. Its as of ST is seeing device state changes when using the switches manually.
This is an important update in regards to the incident reported here, on July 21, 2022 where some Zigbee motion sensors using the SmartSense Motion Sensor DTH were incorrectly migrated to the Zigbee.
We have performed a migration this morning specific to the affected devices to correct the bug. All devices that were incorrectly migrated, should now be migrated to the Zigbee Motion Sensor Driver. Please confirm if this fix worked for you.
As a reminder, we regret that automations affected by this error have been removed and will need to be rebuilt.
Thank you for your continued support.
Hi @alissa.dornbos ,
Could you please elaborate about the root cause of the issue?
From your post it looks like the issue is merely related to migration from DTH to Edge.
However, I have have seen some reports that motion sensors, managed by community drivers are also having issues (specifically, with Aqara Motion sensors, controlled by my driver).
I would really appreciate as much technical details as you can provide.
Hey John, Thanks for sharing.
I want to make sure I understand the steps you are seeing, can you correct me if I am misunderstanding what is happening?
- Zigbee Switches, backed by Lua (feel free to tell me which ones)
- You manually used the switches bu physically interacting with the device
- On the device card your seeing them as Offline.
- After the devices were the devices unresponsive withen the ST App, if you tried to manually interact with them, they still showed offline.
Was the only way you got the devices to not be in this state by, resetting and rejoining? Would they go back into this offline state after you interacted with the switches again? Does this happen every time with these devices backed by Lua?
The issue was that SmartThings migrated motion sensors, to be contact sensors. There was a subset of devices from our Hub Beta population, that were backed by the SmartSense Motion Sensor DTH that this specific bug would be limited to. Only these devices backed my SmartThings owned DTHs were involved with a migration June 21, and migrated to the wrong SmartThings owned driver. This was due to a cashing issue during the migration. The root cause is known and has been fixed.
What issues are you seeing with your community driver that supports Aqara Motion Sensors?
Hi @alissa.dornbos ,
You’ve got steps 1-4 spot on. The devices have always been different switches, in other words, I’ve not had the same switch go back offline once I reset it and rejoined. So yes, the only way to get the Zigbee switches back online was to reset them (not delete) and rejoin. Resetting the GE/Jasco switches is an easy 10 taps on the paddle.
So far since these switches have moved to an edge driver, I’ve have about 10 go offline. This time I had these to reset:
Front Soffit Lights
Master Bed Tray Lights
This does not happen every day, but maybe every several days to a couple weeks. It’s been about that long since I had to do this.
Hope that helps.
Are these all devices, that SmartThings have migrated for you? Or are these devices that you newly joined with a Beta Driver?
My motion sensor properly updated and is working as expected again! Thanks!
And bonus, since I use this in a Smart Lighting rule it didn’t get lost in the shuffle
Thank you for a quick response.
- Devices go offline (even when signal strength values are good)
- Battery is not updated (I suspect zigbee binding has been lost)
- Automations are not triggered, even though the event is registered by device and is shown in device history
I should add that those issues are not deterministic, they are usually fixed by either just scanning for new devices (without removing the device) or by re-pairing (re-onboarding).
I personally don’t experience offline or battery issues, but have seen missed automations
These were ones ST migrated for me.
If you back these devices with a community-written Groovy DTH, do you still see these issues?
Sorry to ask another question, just thinking about this more and want to make sure I am capturing it.
When you mention “This does not happen every day, but maybe every several days to a couple of weeks. It’s been about that long since I had to do this.”
- These were devices that were migrted to Lua by SmartThings.
- After migration to Lua you started seeing this.
- Every Several Days to a couple weeks, when you flip the switch it goes off line, then you have to deliver and rejoin.
- You have had to do this multiple times for a few devices.
^Is that right?
If so, this is probably not related to ‘migration’ itself and the team will most likely need to look at the driver.
No worries, ask as many questions as you’d like! I’ll answer each one:
First part is correct, but not the second. I usually find the device is offline because an automation failed to execute, and then I look in the mobile app and see that it’s offline. I also verify via the IDE.
Like right now. My device titled “Spare Room Vent Right” is a Keen vent that was migrated and it’s offline. It could be out of battery, but the app says 50% so it should be fine. I’ll go upstairs shortly and get it back online.
Yes that’s correct, for several devices actually. I’d say over a dozen and all were switches until the Keen vent just now. I’ve only had to do this once per offline switch, not multiple times for the same device.
On that offline Keen vent, I just got that back online by pulling the battery and dropping it back in. Battery level went from 50% to 25%, which is still good for these vents.
EDIT: @alissa.dornbos I had another Keen vent go offline, and all I did to get it back online was the same thing I did for the other one for earlier this week.
I noticed that the device image no longer updates to blue and showing the fan icon rotating like it did with the Groovy DTH. It stays grey all the time no matter if it’s on or off. Both vents are doing that, so I’m going to look at all my other vents but this seems to only happen with vent that went offline and came back online. All vents are using ST’s Edge driver.