FWIW I just paired a new door/window sensor too (new app). I’m not sure if that at least rules out interference?
OK, so finally I had some success!
I started monitoring the livelogs at /ide/logs. I am sure this made no difference, but I wanted to observe in any case. Whilst absent-mindedly trying to pair again using the classic app, the logs registered the discovery of the sensor.
I am not sure what advice to give based on this, but I must have tried pairing around 50-60 times since I got the sensor last Saturday. Perseverance, I guess?
Sad to say, I’m slowly switching out my Aqara/Mijia motion and door sensors. They were stable for aaaaaages (apart from one that refused to work which I put down to an issue with it rather than ST), then I moved a couple of zigbee outlets around, and suddenly everything is awful.
I now have one working motion sensor and one working window sensor. I’ve powered off everything, I’ve taken the batteries out of the hub and left everything for an hour, I’ve deleted and re-added next to the hub, I’ve re-added in-situ, I’ve re-added from the new app and the old. No joy. Nothing I try will make these things stay on the network beyond that fatal first check-in. Thankfully, the Sonoff Zigbee motion sensors I’ve bought seem to be a lot more stable.
I always add these devices via the IDE, start the search, get the Catchall ID, wait and capture the ZB JOIN as well. I find if that doesn’t appear in the logs creating the device will not associate. Create the device, save and publish. It will show up and work.
If it drops you can look at the IDE and look at the hop path. If it’s anything but straight to the hub or repeated through an ST product I find the only solution is to delete the device and add it again as if it was new then leave it next to the hub for a day or 2 and check the hops.
I did that in the beginning, but I’m sure I remember some issues around catchall registration vs hitting the button until it appears in the app?
I’ll give a formerly reliable one another go using catchall/zb join, but I’m not holding out much hope.
NB: All my repeaters are UK ST outlets, of various generations, although the V3 ones aren’t necessarily set up right (I need to double check which DTH they should be using).
Has anyone had issues with adding Xiaomi Mijia Switches/Buttons (WXKG01LM) recently? I added one of these years ago and it has been solid the whole time. I bought one a couple months ago, and it is not able to stay connected. I can add/pair to the hub (v2 in my case), it will work for maybe an hour, and then stop working. In the app it still shows as available/connected, but pressing the button doesn’t register any activity in the device. Got a replacement and the same thing happens. Perhaps newly produced Xiaomi buttons have a change in polling behavior? Any ideas?
After migrating to new app, I’m having a heck of a time trying to keep my Aqara vibration sensor online. It worked forever in the old app but in the new app, it’s stuck on “Checking status” message and goes offline. DTH is Xiaomi Aqara Vibration Sensor so not sure if I should use something else.
Route shows => This Device (XXXX)↔ Unknown Route (???) ↔ [Home Hub]
What is the “Unknown Route (???)” hop as that wasn’t there before?
When you get is I find it has encountered a Zigbee repeater that is not Sleepy End Device complaint. You have to remove the device and re-associate it to get it back to Device -> Hub
What I miss in the new app is the ability to override the status of a motion sensor or door/window sensor.
Sometimes my door closes but the “closed” status is never picked up. In the Classic app, I could hit override to force it to report as closed.
Anyone have any tips?
I agree. I just had this happen yesterday where a door was closed but the sensor did not report the close. Using the manual override in the Classic app fixed it and it’s been working fine for now.
I wonder if there’s a way to do a manual override in an Automation or Webcore.
Weird, I went to check device in IDE and it now says This Device (CXXX)↔ [Home Hub] so didn’t have to take any corrective measures and it’s stayed online for 5 days so far instead of dropping off after an hour. Now need to figure out how to get rid of the annoying “Checking status…” in the new app.
Missing this feature in the new app as well. Let me know if you figure out a workaround, for when the classic app goes away. Edit: figured out a way, for Android anyway. See below.
I also miss being able to see the last checkin for the Xiaomi sensors. Helps verify no devices have dropped off and stopped talking.
Migrated today, and the new ST app feels incredibly half baked. It looks nice, but almost every area feels like a major step backwards in usability and features. Really, really frustrating.
Edit: I figured out a way to override open/close, via SharpTools on Android. Created a SharpTools widget, selected Xiaomi Door/Window Sensor, then selected the specific sensor, then the resetClosed command. Adds a widget to the home screen and pressing it overrides the state with closed. SharpTools cost like $3 i think, but I already use it with Tasker as a direct path to SmartThings.
They are just custom commands. They can be triggered by webCoRE and other apps that recognise such things.
They need to be replaced by custom capabilities to be accessible in the UI of the new app. That part of custom capabilities isn’t quite ready for prime time yet, though elements of it are working and the access via webCoRE etc works just the same. Ultimately Automations will be able to work with the commands. They can be controlled from the REST API too.
I realized you can also do the resetClosed command in Webcore. Since I use Webcore for everything, I can easily create a virtual button to perform the resetClosed command on that sensor.