I built a HRV and have some DHT sensors in it to measure temp and humidity.
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
delete the motion sensor from SmartThings and then remove power from any Zigbee router/repeaters
(non battery powered Zigbee devices such as Zigbee light bulbs, light switches, power plugs, outlets) on SmartThings and re-pair the motion sensor. Then restore power to the previous devices.
Can I ask if the aqara motion sensor’s lux sensor is working fine?
working fine for me.
Are you having a particular issue… not reporting values, values are outwith expected figures, you have 2 and they both report different values?
These are all the devices on my hub with ZigBee IDs. Only two of them are switches, the other four are battery powered door sensors or motion sensors
Do hue bulbs count as zigbee devices? I have about 10 of those
curious what brand and model of switches
You could try disabling one and then re-pairing and then put the power back to the switch you disabled.
See if it does not fall off.
Try and figure out which one is causing it or maybe both of them are.
but when you re-pair it is hit and miss if the Xiaomi will route through the switch or go directly to your hub.
once paired you could just take the power off the remaining switch and see if the Xiaomi stops working if it doesn’t then it is connected directly to the hub.
I have another 11 zigbee switches/plugs that the Xiaomi could have been failing on and 2 are in my attic so to much of a pain to figure out which one is causing the failure.
I may have found a zigbee outlet that does allow Xiaomi sensors to router/repeat through it but want to test a few more things. Running it on a seperate hub.
I will try cutting the power to both of these when I get home from work and re-pairing the Xiaomi Motion Sensor and we’ll see how that goes. I guess the Xiaomi door sensor I’m using managed to connect directly to the hub, but these motion sensors are being stubborn.
Hue bulbs are capable of repeating if they’re connected directly to your ST hub, but people have reported them as being unreliable:
You’re on the right track here. Only mains powered Zigbee devices can be capable of repeating, so there’s no need to worry about any other battery-powered devices.
Generally people have reported issues with Xiaomi devices that are initially through a repeater, but there’s a higher level of success in keeping Xiaomi devices connected if they are first paired to the ST hub, and then moved to their install location, where they may change their connection to a local repeater device.
SmartThings started adding an attribute called “offlinePingable” to the device health piece of device handlers. No clue what it does, but may be good to add to the Xiaomi handlers
I have the same switches on my SmartThings hub
could you try leaving the switches powered and just unscrewing the hue bulbs and then try pairing. No guarantee that they would pair through the switches but if they did it would confirm that they work as Xiaomi repeaters.
It would cut my testing of repeater devices in half.
I suspect that the problem is the bulbs.
Thanks for the heads up, but the “ping” feature is part of SmartThing’s DeviceHealth, which is only available for local-execution devices - a subset of SmartThings “officially” supported device list.
Xiaomi devices are not “official” supported, and the DTH’s are most definitely not being executed locally.
It works for cloud devices too. I’ve added it to several handlers.
Well I have yet to be able to test this since smartthings has been down all night but I’ll let you know once I do…