I have the two-button version of that switch, and yes, the xiaomi-aqara-button device handler will work. After pairing, just manually change to that device handler.
After an update a week ago, all of my Xiaomi devices have remained connected to my Hubitat hub, and with the device drivers that I’ve made (adapted from Brian’s ST repository) they all work great. Especially the “original” Xiaomi Button from you - I was able give user’s full access to its multi-click capabilities! However, despite being really fast because the Hubitat runs everything locally, there’s no mobile App user interface. So there are tradeoffs…
Ok, but how do I pair it? Tried pressing the switch for many seconds and
just 3-4 seconds.
Do you have to use the catchall method?
What you mean by changing the DH? Doesn’t it use the DH mentioned below
Usually I just install the DH and it selects the required DH automatically.
Not sure how to change this?
Thank you for all replies but I have in my house Xiaomi and Aqara devices, so I have other question
bspranger : Xiaomi Aqara Door/Window Sensor - Can I use this for Xiaomi and Aqara?
There is a separate DH for the original.
They are all in the same repo on git hub.
My original Xiaomi contact sensor and motion sensor now work with new Smartthings app (samsung connect app renamed), they didn’t before. My Aqara sensors and the Xiaomi button are still not working in the new app though :).
Have you been given any information on the new cloud setup and DTH changes yet? With the new AWS based solution I would curious what help it might be.
Also With many of us relying on these DTH will you be looking at migrating to the new solution when it is available?
Thanks for all the work so far.
I have not seen anything about the new APIs.
Brian and the rest of us who have worked on the updated Xiaomi device handlers are not “official” software developers. We are just trying to help people who have these unsupported devices.
This means we are just like any other end-user: We will be the last to know what the changes are to the API for local hub-connected devices.
Samsung still has not posted any details about developing device handlers for hub connected devices. Please keep checking this webpage, but for the past month +, it has looked like this:
Has anyone tried with any success putting a Original Temp Humidity in a return duct of a heating / AC system?
That could be interesting. Not seen that page before.
I am interested in the return temp and humidity as it determines if things are working as required. Especially the humidifier.
Thanks for the info, nice job by the way. I plan to cut a round hole in the duct, slightly larger than the sensor. Then make a square patch with sponge weather stripping and a hinge. This way I can open the door to reach the sensor to change batteries. My other choice was to connect two wires to the battery terminals and supply an external power supply.
@veeceeoh, @ArstenA, @AlecM I was looking through your git hub branches and the discussions you guys were having in relation to the options in relation to leveraging hold functionality for the Xiaomi buttons. I know two approaches were being investigated and one ended up being a no goer, just wondering how the other option is currently looking (I’m aware of the outstanding issues) so just what the current feeling is.
I did see some posts by one of the testers whereby they mentioned @a4refillpad code worked sometimes and would eventually. Just to add to that, the code provided initially used to work all the time when he initially created it, however like the tester said now its hit and miss. The only thing that has changed since it used to work are the various ST updates (just providing some background, by no means am i saying it should still work).
In relation to the Zigbee Outlet, I understand why you have the note saying we don’t recommend, but is there anything in your supplied code different than the one provided by @a4refillpad. I have two and i don’t have issues but yes you can have lots of issues with this device based on Wayne’s previous investigative work. Is this a DTH you update to follow the other devices format or is it just a simple fork and won’t be touched?
May I just add, by looking through your GIT HUB discussions, you really have done brilliant work, and I really really really love the engagement in terms of asking seeking , offering, discussing amongst yourselves if this may or may not work. This is hidden away from this ST forum and I know I’ve said it before and I think it was only yesterday @veeceeoh said you are only joe soaps, but you are most definitively working communicating as a coherent team, and regardless of your background it’s brilliant to see from a community view point. So once again, well done, and I tip my hat towards you.
It’s funny you should ask, because last night I just completed testing of what was my final attempt to come up with better-working code for the momentary function of the “original” Xiaomi Button DTH. I haven’t yet posted my findings on the GitHub repository, but long story short, I realize there just isn’t any way to get around the shortcomings of cloud-executed device handler code.
The speed of cloud-executed code just isn’t fast, consistent, or reliable enough to guarantee button messages are processed in the order they are generated, and they absolutely must be processed in order for the momentary button function to work 100% reliably.
So it turns out that a4refillpad’s method works best most of the time. I see no reason why we can’t integrate that code into the bspranger version of the “Original” Xiaomi Button DTH, and then at least user will have correct battery reporting.
No, it’s exactly the same, I’m sorry to say. The best way to improve the DTH would be for one of the people working on the code to actually have one in hand. Doing testing by collaboration between the person working on code and getting reports from an end user testing the code is possible, but takes quite a bit of patience.
Also, thanks for the kind words. I know everyone involved on GitHub has certainly been enjoying the collaboration!
I have nothing against developing the Xiaomi outlet except for the fact that I don’t own one and that I am in the US so the plug form factor is less appealing to me.
If you have a DH that works well/better than the one currently in the git repo please make a pull request and we can update the current one.
As for the buttons, I only have an aqara and it seems limited in its capabilities compared to the original.
I have the two button version, but the pairing process for your should be the same:
- Start “Add a Thing” in the SmartThings (classic) mobile app.
- Hold the switch until you see the LED(s) blink at the bottom, and then immediately release the switch.
- There will be a pause, and the the LED(s) will flash again. If you see 3 consecutive quick flashes, then the SmartThings hub has recognized the switch. If there’s only one long flash, go back to step 1.
- If the switch appears in the SmartThings mobile app, ready to rename, then you’re done! Otherwise, continue with the next step.
- Open IDE for your hub, and navigate to My Hubs --> Scroll down to Events section --> click List Events link.
- Look for an event with name starting with “catchall: …”, like this:
- Click on the date/time of the catchall event entry to view it’s details, and look for the seventh group of hexadecimal values after “catchall:” as seen here:
- Copy or write down those value (there must be four digits) and navigate to My Devices and click “+ New Device” to get to the Create Device webpage.
- Type in all required information in the Create Device page, entering in the 4 hexadecimal values from the “catchall:” message in the Device Network Id: field, and choosing Aqara Button for the device type, like this:
- Click the Create button. You should now be able to use your switch.
Note that the 2-panel switch I have is one of the most difficult Xioami devices to pair in my experience. It may take repeated attempts to get the SmartThings hub to recognize it.
I hope that helps!
By including the existing code logic into the new DTH’s would be great as it means as you said, battery reporting would be improved but also a universal go too place for the various items. In fact, that was why I asked about the outlet, as the code in your own repository is the same as @a4refillpad one, his repository can be removed from the IDE and flipped over to your version.
A single go to repository for the various Xiaomi devices containing all the latest improvements.
I bought two of the Aqara motion sensors, and one of the door/window sensors. The door sensor paired fine and is reporting battery and staying connected. The motion sensors on the other hand will not stay connected for more than a few hours. They eventually slow up as unavailable in smartthings and stop reporting. Any suggestions to get them to stay connected? I’ve tried both these DHs as well as the original ones from a4refillpad