[Release] Xiaomi device drivers

community_driver

#181

Removed the sensors (just to be safe), changed the driver code, re-paired and now an error is thrown.


#182

Thanks for reporting back - I’m really sorry for the inconvenience. I made another fix to the code, but as I am not home right now, I am unable to test it.

If you don’t mind trying it out, the link I gave in the previous post is still valid for the updated code. You definitely do no need to remove the sensors, just copying in the new code and hitting “save” is all that’s needed.


#183

No inconvenience, whatsoever! I appreciate the work you’ve put into these drivers!
This one looks good now.

The logs look good too. Thanks again, and now I will stop pestering you!:grin:


#184

Have you looked at the Xiaomi smoke detector or their combo natural gas/CO/smoke detector? There’s an api on smartthings for the single unit but I couldn’t find anything for the combo after a quick search.
Xiaomi Honeywell Smoke Detector

Xiaomi Honeywell Combo Detector

Also, has there been any interest in supporting bluetooth devices through Hubitat? This little sucker looks awesome. It’s too bad it’s not zigbee though. LCD screen thermostat humidistat.


#185

I don’t own either of these, but I plan to port over the ST device handler for the Xiaomi Smoke detector soon, if @emilakered doesn’t mind using his detector to test the ported code.

As for the combo unit, I would only be able to create a device driver if someone has / buys one and doesn’t mind working with me to test the code and give feedback.

Also, has there been any interest in supporting bluetooth devices through Hubitat?

Not sure. However, I have started trying to play with the docker-based KuKu Mi ST device handler that I mentioned in March when you asked about the Xioami Mi Remote, and noticed that it’s based on a project that includes control of Bluetooth Xiaomi products. But the BT-portion of the docker server is disabled. Honestly, I think I will probably only get as far as porting the KuKu Mi docker/driver combo for Hubitat (if it does work), and stop there.


#186

I may buy both the smoke and combo unit. I’d be happy to help out. My storage room has a gas water heater and furnace, and will soon have a 3D printer. I want to be able to kill the power to the printer if it detects smoke or a gas leak.


#187

I don’t mind! Still in some kind of slow transition, with maybe 80 % of my devices over at Hubitat now. Just give me a ping when you need something tested and I’ll get right to the smoke detector. :slight_smile:


#188

@rob Did you ever find a solution to the motion sensors not reporting inactive? I was just running into the same issue with my new hub. I think I may have found something to try if you haven’t solved it yet. I have Other Hub Event Pusher setup to send all my devices back to SmartThings and with that sending the motion sensors they never go inactive, but if I remove the motion sensors from Other Hub they appear to work correctly.


#189

The most recent updates seem to have sorted that, combined with resetting Zigbee and reconnecting the devices with the Osram/Sylvania Lightify bulbs turned off - seems pretty stable now.


#190

So I’m starting the port of the ST DTH for the smoke detector, and after searching around, I’m not seeing a combo unit. Here are the two Xiaomi MiJia-Honeywell devices:

Although both work wirelessly via ZigBee, only the smoke detector is battery-powered. The Gas Leak detector is powered via a “wall wart” power supply, and interestingly also includes terminals on the back to allow direct on/off switch control of a fan. Since the manual is roughly translated, it’s unclear whether the connections would work with anything other than the 220V line power found in China.


#191

Aha. You’re right, the description for the device on gearbest falsely suggested it was a smoke, CO and gas detector.


#192

[RELEASE] v0.5 of Xiaomi MiJia Honeywell Smoke Detector Device Driver
Model JTYJ-GD-01LM/BW

For convenience please copy the device driver code from this direct link.

Status Event Support
This driver supports three types of hub events for the smoke attribute:

Event Description
detected Smoke has been detected
clear All clear - smoke no longer detected
tested Self-test completed*

*Note: Hold the smoke detector's button for 1 second for self-test.

Other Features:

  • The Hubitat hub should correctly select this custom device driver when paired.
  • Hubitat Safety Monitor compatibility
  • A custom lastCheckin attribute (for use with webCoRE) with an Epoch Time stamp for every message received from the smoke detector
  • Custom lastDetected, lastClear, and lastTested attributes (for use with webCoRE) with an Epoch Time stamp for each smoke detected, smoke clear, and smoke tested message received, respectively
  • Battery replacement date tracking, stored in batteryLastReplaced state
  • Commands / Preferences include:
    • A Reset Battery Replaced Date command to track battery life
    • A Reset To Clear command to manually override a smoke detected event
    • Min/Max voltage values used to calculate the battery percentage
    • Toggles to display informational and/or debug log messages

Notes:

  • This device driver is not final, and some features or preferences may be added / removed.
  • A check-in message including battery voltage data is sent by the smoke detector every 50 minutes. Because of this, battery percentage may not be seen until the first battery report is received, 50 minutes after pairing.
  • I do not personally own this smoke detector, and was only able to test it with thanks to @emilakered. The driver code was adapted from a SmartThings device handler by foz333, based on work by KennethEvers.
  • For more information on the installation and operation of this smoke detector, please see this English-translated manual.

Pairing Instructions
After putting the Hubitat hub into Discover Devices mode, press the smoke detector's button 3 times to put it into pairing mode.


With this driver release, I am now turning my focus on finishing the port of the Mi Cube device driver, and investigating a port of the KuKu Mi SmartThings DTH-Docker Container solution for the Xiaomi Mi Universal IR Remote Controller.


#193

Finally got my order of devices from China, only took 7 weeks :frowning:

My original motion sensors paired correctly. The cube appeared as a device only.

Sliding and turning to a new side appears to function. Rotating or tapping doesn't generate responses in log.

The advanced pairing details are below:

**Manufacturer:** Unknown Manufacturer **Product Name:** Device **Model Number:** lumi.sensor_cube **deviceTypeId:** 12
[more...](http://192.168.x.x/hub/scanDevice#collapse260)

manufacturer:null
address64bit:00158D0001041F05
address16bit:A58C
model:lumi.sensor_cube
basicAttributesInitialized:true
application:null
endpoints.01.manufacturer:null
endpoints.01.idAsInt:1
endpoints.01.inClusters:0000,0003,0019,0012
endpoints.01.endpointId:01
endpoints.01.profileId:0104
endpoints.01.application:null
endpoints.01.outClusters:0000,0004,0003,0005,0019,0012
endpoints.01.initialized:true
endpoints.01.model:lumi.sensor_cube
endpoints.01.stage:4
endpoints.02.manufacturer:null
endpoints.02.idAsInt:2
endpoints.02.inClusters:0003,0012
endpoints.02.endpointId:02
endpoints.02.profileId:0104
endpoints.02.application:null
endpoints.02.outClusters:0004,0003,0005,0012
endpoints.02.initialized:true
endpoints.02.model:null
endpoints.02.stage:4
endpoints.03.manufacturer:null
endpoints.03.idAsInt:3
endpoints.03.inClusters:0003,000C
endpoints.03.endpointId:03
endpoints.03.profileId:0104
endpoints.03.application:null
endpoints.03.outClusters:0004,0003,0005,000C
endpoints.03.initialized:true
endpoints.03.model:null
endpoints.03.stage:4

#194

I have one of these motion sensors paired to my dev hub, there are no repeaters in this setup and the sensor is a foot from the hub.
It has not stayed on line for very long.
So this morning I fired up the sniffer after resetting the sensor. I'll leave the sniffer running until the sensor drops again, I can't make any solution oriented promises, but maybe this will shed some light on the situation here.


#195

I noticed my bathroom sensor isn't giving motion updates but it is still giving battery updates. Seems odd the one would work but the other wouldn't.

Weird, I turned on debug message logging, and it started showing both debug and motion updates in the rt log.


#196

Thanks, all the same as what I'm seeing with my cube. Still working on the device driver port, and it will take a little longer than with the others because spring is in full swing and it's too nice to be sitting at a computer for hours (when I'm not paid for it!)

Strange, since myself and others are having much better luck since the 698 update. If the end device timeout is longer than the 50 / 60 minute check-in cycle of the Xiaomi devices, then it will be interesting to see what else is going on.

It's also possible that your motion sensor didn't perform it's first check in. I've seen that happen a number of times in my testing - no battery report (an indicator of checking in) until 100 or 120 minutes after pairing.

You should also see motion active events (and the automatically generated motion inactive events) in the events list.

I have not seen this happen with any of my 3 Aqara Motion Sensors. I don't know whether it's related, but keep in mind that both types of motion sensors go into a test mode when paired or if the reset button is short-pressed. During test mode, which lasts about 1.5-2 hours, the hardware resets motion detection sensing 3-4 seconds after motion is detected instead of 60 seconds.

The default driver-generated motion inactive event is based on a runIn countdown timer (with a default of 61 seconds), which gets reset and restarted if there's a motion detected event before the countdown finishes. Due to that 61 second default, during Test mode, motion detected events are still logged every 3-5 seconds, but only after no motion has been detected for 60 seconds would you see a motion inactive event.

After the test mode finishes, then of course motion detected events can only happen at a minimum every 60 seconds.


#197

My cube shows source and target faces which I can use on Webcore:


#199

Hi,

I'm new to all of this and I am considering buying a Hubitat,

I have a ton to read but before I do I am wondering what exactly should I be buying from Xiaomi for a smart home?

Do I need the Xiaomi hub?

Anyone ever make a list of items they purchased for their smart home (Xiaomi)? I'd love to copy it!


#200

You don't need the Xaomi hub. You can pair them directly with Hubitat once you install the community provided drivers. They are not fully compliant with the Zigbee spec, so your mileage may vary.

I strongly recommend you get your hub first, and then if you want to try Xiaomi devices, you should just purchase Aqara devices to "play" with and see how they work in your environment. They are somewhat of a pain to pair, and if you're too far from the hub, they will drop without a plug-in device to repeat the signal and strengthen your Zigbee mesh. I've had good success with them in a small house, but none of the devices are that far from the hub. If you have a larger home, and especially if your hub is not centralized in your home (it should be though, all your hubs and WiFi routers should be), then you're going to have better success if you just purchase a Sylvania Smart+ plug in advance to help strengthen the mesh for Xiaomi devices (but all Zigbee devices will benefit from it).

Read this thread so you are informed about what you're getting into with Xiaomi devices. TBH, you might not want to try the Xbee stuff in that thread initially, but it all depends on your experience.

Some of the Xiaomi Aqara devices are pretty darn solid performers, and so far I have not added a repeater, but don't be shocked if they don't stay connected and you have to re-pair them with the hub from time to time. Again, it's hard to know until you try, so don't go crazy and order a ton of them in the beginning. Also, as you're getting used to Hubitat, I would suggest you work with devices that are compliant with the Zigbee spec and Z-Wave Plus, otherwise you're going to think there's a problem with the hub radio and it's not fair to make that assumption with devices that were never intended to pair with it, but have been made to work thanks to the dedication of the community.

I'm running my hub's Zigbee on channel 13. This doesn't interfere with my WiFi or the Hue bridge near by, and I've had good success with the Xiaomi Aqara devices I own. There are different reports of different channels working better for other people. Some experimentation may be needed.

No Xiaomi device in my setup is more than 20 linear feet from the hub zigbee/zwave stick.
Here's what I have and how they have performed.

Xiaomi Aquara leak sensor: Installed Mar 09, 2018 - No drop-off
Xiaomi Aquara leak sensor: Installed Mar 23, 2018 - No drop-off
Xiaomi Aquara button: Installed Apr 11, 2018 - No drop-off
Xiaomi Aquara button: Installed May 7, 2018 - No drop-off
Xiaomi Aquara motion sensor: Installed June 13, 2018 - One drop-off after an extended hub shut-down due to downed power lines. Pressed pair button once and it came back online, So far it has not dropped again.
Xiaomi Aquara door/window sensor: Installed June 13, 2018 - Had to be reset and re-paired on June 20. No drop-off since
Xiaomi Aquara button: Installed June 17, 2018 - No drop-off

Good luck with the Xiaomi adventure. Enjoy your Hubitat hub. Take your time and as long as you remember it's still in development, you'll have a more satisfying time working with it as it quickly improves.


#201

I wish I could say that I've shared your experience. :frowning:

I've had nothing but trouble with my Xiaomi sensors since migrating to Hubitat. Smartthings rarely dropped a sensor once they were properly paired and reporting battery for me.

With HE, I have had all of my Xiaomi devices to drop at once, and many frequently continue to drop or fail to respond.

I'm at the point now where I don't even bother resetting the sensors, but I'm too lazy to migrate them and their respective repeaters back to ST. So much for keeping it local.