Brilliant. Making my order ASAP. They’re for rarely used rooms, so going to make on off on press and brightness cycling by hold using CoRe.
Speaking as a network engineer…
Pairing in place will work for Z wave plus devices except for some locks.
It will work for Z wave classic devices and for ZHA devices that are within one hop of the hub.
It can’t work for Z wave classic devices or zigbee devices that will require a repeater to reach the hub because that just isn’t how they do their initial pairings. You have to get them on the network, and that requires being within one hop of the hub or, in the case of zwave classic devices, within one hop of a secondary controller like an Aeon Minimote.
Z wave locks and ZLL devices usually require being even closer to the hub, within a few feet.
All of which is to say, if your method works for you, great. 
Or if you only use Z wave plus devices, you’ll be fine. (This is one of the improvements with Z wave plus.)
But most zigbee devices will need to be paired close to the hub, then moved to their permanent location, and then you should heal the network after everything is in place to make sure that all the neighbor tables are up-to-date.
2 Likes
With this in mind - is there any downside in using the stock zigbee button DTH instead of the custom one you created? I just edited one of my buttons to stock and it seems to work well (except held identification). The advantage in using stock DTH is it might run locally on the hub
No difference. However, I really doubt the DH runs locally. Have you looked here at your IDE …/localDevice/list and found that it does run local with the stock DH?
1 Like
I just did and it’s not there.
For whomever still interested, as I promised, I’m working on translating FAQ section from Xiaomi’s official website and here is my work so far:
Currently I’ve only finished two type of devices, but I’ll keep working on it.
If you wish to contribute, please PM me for edit permission.
Edit:
All translation done!
Edit 2:
The translation is no longer maintained. If you’re still interested, download the image below and rename the extension to “.zip” for an exported copy, the file in the Google drive has been deleted.
10 Likes
Since today it seems my Xiaomi sensors are not reporting opening/closing.
Battery reports / Checkin still work for all. Just not reporting opening/closing.
I saw an email that the web-infrastructure of ST has been updated…
Not at home atm, but will keep my eye on this.
Edit:
Door opened, no update in ST.
In the log file i have this message:
2:27:47 PM: error groovy.lang.MissingPropertyException: No such property: result for class: script14919362537642106672897 @ line 214
2:27:38 PM: error groovy.lang.MissingPropertyException: No such property: result for class: script14919388057072106672897 @ line 216
Something must be going wrong i a script, not sure which one though
My door/window sensors are all reporting open/close events normally.
Hi All, first of all thanks to guys who built the handlers “legends”. So I thought I would share my experience with Xiamoi Sensors. Firstly I have been running door sensors for weeks and had no issues, the battery status takes a while initially to show, can even be overnight, but no big deal. I also have the Human / Motion sensor that also doesn’t miss a beat, and each device whatever it is reports in every hour which is great. Setup was easy just hit the rest a few times and ST picks them up, rename them and your away. Now for those having trouble where they drop off, have you thought about the location of the ST hub, mine is upstairs at the rear elevation of the house not downstairs, a colleague of mine has his downstairs and they drop off, so try moving the ST hub. As regards distance I have a large allotment area at the rear of my property with sheds on each shed which has the door sensors on that set off my aotec alarm in the house when opened, these sheds are roughly 60 meters away from the house and all report in hourly and work immediately the door is open.
Hope this helps!
1 Like
Strange, none of my 12 sensors is working, they all give me this error.
I have compared this part my devicehandler with the one on github, they seem identical.
Just copied the handler from github, see if that helps.
Just tested all of my xiaomi device types and all looking good for me. No issues.
1 Like
Rinkelk is this just today?
Yes, worked fine for months until yesterday.
One thing i changed yesterday: i turned off DeviceHealth
(And playing with WebCore, but turned that off now)
It might be worth rebooting your ST hub, I had an email today stating they were upgrading ST`s backend, may be that didn’t help! The upgrade was due today…
I’ll give it a try
Let us know it may effect others…
Keep you all posted
Just for anyone who missed this : -
Hello,
Starting the evening of Wednesday April 12, we will be migrating and upgrading the SmartThings cloud platform to increase the resilience of our infrastructure. The upgrade is scheduled to begin at 12 AM BST and is expected to take up to one hour.
During the upgrade, your SmartThings Hub and mobile app will go offline and events will not be processed. When the update is complete, your Hub will reconnect to the SmartThings platform and devices and automations will resume operating.
Thank you,
SmartThings Support
I just removed all smartapps (except for CoRE) to make sure these are not interfering.
(I made a backup of all WebCore pistons) and rebooted.
Hopefully it starts working again.
As i’m not at home atm testing will have to wait until this evening.
Cheers Rinkelk for the update…
1 Like