Is support for the door/contact sensor for the 2017 or 2018 version? Or does it not matter? D
Doesn't matter unless @veeceeoh says it does. He ported these drivers for HE and is very good at keeping up with them and the new versions. The first post has all the drivers. The "Original" and Aqara door/window sensors are connected.
I'm using the button, door window (original Aqara version), motion, leak and temp/humidity/pressure sensor. All work perfectly.
the reason I asked is there's the Original Xiaomi (non Aqara branding), Aqara, and now 2017/2018 Aqara (though, I'm assuming 2017 is the first Aqara)? Or quite possibly Aliexpress is not entirely accurate in listing
I get you. The latter is probably the most accurate assessment. Keith will chime in if I'm wrong, but he is pretty on top of this and would have said they're not compatible. I have no actual idea what any of that Original vs Aqara stuff means. Everything I've ordered from Gearbest and the one thing I ordered off ebay all came in boxes labelled Aqara. So even my door/window sensors that are supposedly the "Original" were labelled Aqara on the box.
Well been running for two weeks now and everything works a treat, thanks guyeeba !
I am not aware of any difference between different versions of the Aqara Door/Window contact sensor, and nobody has reported troubles with contact sensors purchased this year. If I new version needs changes to the device driver, I will do my best to support it.
However, there are different versions of other Aqara devices, and even some devices which have the same model number printed on the exterior, but report different Zigbee device IDs.
Here is a complete list of all Xiaomi / Aqara devices that I am currently aware of:
Xiaomi Device Name | Device Type | Model / SKU | Zigbee Model | Hubitat Driver? |
---|---|---|---|---|
Aqara Cube Controller | Multi-function Controller | MFKZQ01LM | lumi.sensor_cube | beta driver |
Original Door and Window Sensor | Magnetic Contact Sensor | MCCGQ01LM | lumi.sensor_magnet | available |
Aqara Door and Window Sensor | Magnetic Contact Sensor | MCCGQ11LM | lumi.sensor_magnet.aq2 | available |
Aqara Door and Window Sensor T1 | Magnetic Contact Sensor | MCCGQ12LM | not yet known | not yet |
Original Motion Sensor | IR Motion Sensor | RTCGQ01LM | lumi.sensor_motion | available |
Aqara Motion Sensor | IR Motion Sensor | RTCGQ11LM | lumi.sensor_motion.aq2 | available |
Aqara Smart Bulb | Smart Bulb (E27) | ZNLDP12LM | not yet known | not yet |
Original Smart Plug | Plug-in Outlet Switch | ZNCZ02LM | lumi.plug | no |
Aqara Smart Plug | Plug-in Outlet Switch | ZNCZ12LM | lumi.ctrl_86plug.aq1 | no |
Original Temperature and Humidity Sensor | Temp & Humidity Sensor | RTCGQ01LM | lumi.sensor_ht | available |
Aqara Temperature and Humidity Sensor | Temp & Humidity Sensor | WSDCGQ11LM | lumi.weather | available |
Aqara Wall Outlet | In-wall Outlet Switch | QBCZ11LM | not yet known | no |
Aqara Wall Switch - Single (no Neutral) | Wall Switch (no neutral) | QBKG04LM | lumi.ctrl_neutral1 | from guyeeba |
Aqara Wall Switch - Double (no Neutral) | Wall Switch (no neutral) | QBKG03LM | lumi.ctrl_neutral2 | from guyeeba |
Aqara Wall Switch - Single (w/Neutral) | Wall Switch w/Neutral | QBKG11LM | lumi.ctrl_ln1.aq1 | from guyeeba |
Aqara Wall Switch - Double (w/Neutral) | Wall Switch w/Neutral | QBKG12LM | lumi.ctrl_ln2.aq1 | from guyeeba |
Aqara Wall Switch S2 - Double (w/Neutral) | Wall Switch w/Neutral | QBKG20LM | not yet known | not yet |
Aqara Water Leak Sensor | Water Contact Sensor | SJCGQ11LM | lumi.sensor_wleak.aq1 | available |
Aqara Water Leak Sensor T1 | Water Contact Sensor | SJCGQ12LM | not yet known | not yet |
Original Smart Wireless Switch | Multi-function Button | WXKG01LM | lumi.sensor_switch | available |
Aqara Wireless Mini Switch | Multi-function Button | WXKG11LM (2015) | lumi.sensor_switch.aq2 | available / beta |
Aqara Wireless Mini Switch | Multi-function Button | WXKG11LM (2018) | lumi.remote.b1acn01 | beta driver |
Aqara Wireless Mini Switch | Multi-function Button | WXKG12LM | lumi.sensor_switch.aq3 | available / beta |
Aqara Wireless Mini Switch T1 | Multi-function Button | WXKG13LM | not yet known | not yet |
Aqara Wireless Remote Switch - Single | Multi-function Button | WXKG03LM (2016) | lumi.sensor_86sw1 or lumi.sensor_86sw1lu | beta driver |
Aqara Wireless Remote Switch - Single | Multi-function Button | WXKG03LM (2018) | lumi.remote.b186acn01 | not yet |
Aqara Wireless Remote Switch - Double | Multi-function Button | WXKG02LM (2016) | lumi.sensor_86sw2 or lumi.sensor_86sw2Un | available / beta |
Aqara Wireless Remote Switch - Double | Multi-function Button | WXKG02LM (2018) | lumi.remote.b286acn01 | not yet |
Aqara Vibration Sensor | Accelerometer Sensor | DJT11LM | lumi.vibration.aq1 | beta driver |
MiJia Honeywell Smoke Detector | Smoke Detector | JTYJ-GD-01LM/BW | lumi.sensor_smoke | available |
Notes:
- All the devices listed as "not yet" in the "Hubitat Driver?" column are either new devices for which I am working on a supporting driver, or new devices recently announced with ZigBee 3.0 certification but not yet shipping.
- For some devices there are combined drivers, so you only need to install one driver for all of its supported devices. This includes the drivers for both models of Door/Window sensors, for both Temperature/Humidity sensors, for the 1 & 2 button Aqara Smart Wireless Switches, for the 1 & 2 button Aqara Smart w/Neutral Wired Switches l, for the 1 & 2 button Aqara Smart Wired No Neutral Switches, and for all three currently shipping variations of the Aqara Wireless Mini Switch.
I will add this list to my opening post of this thread for easy access. Also, I am working on a Google Sheets version of this list for which I will post a link soon.
The WXKG03LM (2018) lumi.remote.b186acn01 works fine with the driver you did for the 2016 model, in fact all the single button switches I have are all the 2018 model.
Thanks for posting this...worked like a charm!
Hello Fellow "Xiaomians"- anyone have experience with the Wink Zigbee Ceiling Fan controller & Xiaomi devices?
I asked the wink support about the specifc end device timeout and they seemed to quote me the general zigbee spec, and said they weren't sure(40 mins they said).Which leads me to believe they will cause Xiaomi devices to fall off , if routed thru the fan controller.
I'd rather have my xiaomi devices stable, and if forgetting about the fan controller does that, so be it
BTW- I just discovered the sylvania RGBW LED strips caused 4 xiaomi devices to fall off, an it's going back to amazon, don't need it really
I just got into Hubitat and cant believe the community involvement, Thanks for your work!
Do you have any plans on including the plethora of other Xiaomi devices that can be controlled, such as Air Purifiers, etc...
GitHub - fison67/Mi-Connector-Hubitat is another repository of devices that can be controlled by hubitat, but you have to set up a separate service running in docker to act as a gateway. I would rather hubitat just be able to do it...
In case anyone uses my driver for QBKG03LM or QBKG04LM no neutral wall switches (or any other DTH, but wants to add a sexy, but in most cases quite useless new feature):
I updated my driver with three new features!
- Added double click capability
- Added temperature measurement capability
- Buttons can be separated from switch (buttons and switches work just fine, but they work independently)
Do these only work with 220v like stated in the documentation or has anyone tried these in the US on 120v?
Ahh, yes, it will work for single-press, but the 2018 models of the wireless wall switches also support double-click and hold. Would you be willing to test an updated device driver that adds those capabilities?
40 minutes is shorter than the check-in interval of any Xiaomi / Aqara device. Maybe someone else can chime in here because I don't have that Ceiling Fan Controller myself, but based on what Wink support told you, it probably won't allow Xiaomi / Aqara devices to remain connected.
I got one of those when there was an amazing deal for them on Amazon, and only discovered it wouldn't work with my Xiaomi / Aqara devices after it was too late to return. I haven't sold it yet because I am considering using my SmartThings v2 hub to handle incompatible ZigBee repeater devices (just a few). I wish there was a way to block certain repeaters from picking up ZigBee end devices to route...
Unfortunately I do not, as that plethora of other Xiaomi devices are not ZigBee and would be outside the scope of my experience and abilities, not to mention the nightmare of creating drivers and supporting them for device I don't own.
And that would be quite an undertaking to port over the Ubuntu-based Mi Connector service to run entirely as a Hubitat App. I'm not even sure it's an appropriate use of one's Hubitat hub's resources. Perhaps someone else with oodles of free time may think differently.
Nice! So the wired Aqara wall switches have temperature sensors?
Only one way to find out. Hope you have a good homeowner's insurance policy!
Yes, they do, even though they don't seem to be as accurate as the dedicated sensors. e.g. no decimal places, and weird readings sometimes... most probably beacuase it is the CPU temperature... deep within the wall. But with a well-tuned offset they can be useful for informational purposes.
And the two-wire (neutral) versions even have energy monitoring capabilities! I'll try to figure out how to reset the meter, and release an updated DTH for them, too.
Veeceeoh, how are you going with the update to the drivers code that has a human friendly time?
Christmas is not just around the corner or anything else like that!
I changed the time code on my Xiaomi contact sensors with the following. Maybe it can help out?
Make a copy of the original driver first and make changes on the copied version.
Search for value: now() and replace with value: new Date()
In the contact sensor there are 2 locations for the change. See below for explicit example of one of the changes.
BEFORE:
sendEvent(name: "lastCheckin", value: now())
AFTER:
sendEvent(name: "lastCheckin", value: new Date())
`
I think I've said it before, but I'll say it again.
I am not a paid developer. I am an end-user. I am not a coder by trade. I took up learning Groovy language last year with the purpose of helping to improve Xiaomi / Aqara Zigbee device handlers for SmartThings, and after buying my Hubitat hub, I ported them over. For free.
I don't receive anything for what I do, other than the custom device drivers and apps by other users who have also decided to freely share the products of their time, energy, and efforts.
In fact, I pay for what I do. I have bought devices just for the purpose of helping others to be able to make use of them. I can't really afford to buy loads of devices I might not actually use myself, so this makes the testing process a lot more difficult, not having them in front of me to work with.
Furthermore, since this is not my paid job, I can only use spare time to maintain, improve, and introduce device drivers, as well as to field a constant stream of questions from other users on both platforms. Spare time that I don't have a lot of. So even though it shouldn't have to be said, apparently I have to ask for some patience.
But if you really need to know how I am going with the update, here you go:
I have been working on updates to the entire set of Xiaomi / Aqara device drivers for Hubitat. This includes working adding support to some device drivers for a number of recently released new revisions of some Aqara devices I don't own myself.
Add to this the fact that I have been having major issues with the overall speed of my Hubitat hub, despite removing all custom apps. So while I have been trying to troubleshoot that for more than two months, at the same time I've working on updates for numerous Hubitat device drivers and SmartThings device handlers. If you look at my recent post with the table showing all Xiaomi / Aqara ZigBee devices and their various revisions, you'll see that there are a LOT of them.
The slowness of my Hubitat hub directly affects the ability of some of the device handlers to execute time-sensitive operations as expected. One of them is the device handler for the "original" Xiaomi Button, which is making it very very difficult to test improvements I'm trying to make to the reliability of the software-based button held feature. But since you've mentioned it @mike, I assume the "original" Xiaomi button driver is the other one you're really hoping can have human readable date/time stamp events when the button is pushed to use in a Hubitat dashboard. With that in mind, I'm going to share a beta update for that device driver (see below) which only includes the custom attributes for human readable time/date stamps as well a big update to the Aqara button driver to maintain consistency.
[BETA] Hubitat Device Driver for Xiaomi "Original" Button version 0.85b
Device driver code available here.
Changelist
- Renamed custom attributes
lastCheckin
,buttonPressed
,buttonHeld
, andbuttonReleased
tolastCheckinEpoch
,buttonPressedEpoch
,buttonHeldEpoch
, andbuttonReleasedEpoch
, respectively, - Added custom attributes
lastCheckinTime
,buttonPressedTime
,buttonHeldTime
, andbuttonReleasedTime
, which are used to generate human readable time/date stamp events - Removed all references to WebCoRE for use of Epoch-time/date stamp custom attribute events and replaced with "Apps that can use Epoch time/date stamps"
[UPDATE] Hubitat Device Driver for Aqara Button version 0.6
Device driver code available here.
This update takes v0.55b out of beta as a full release. It now provides support for all three known versions of the Aqara Button:
Model WXKG11LM (original revision)
- Single click results in
button 1 pushed
event - Double-click results in
button 2 pushed
event - Triple-click results in
button 3 pushed
event - Quadruple-click results in
button 4 pushed
event - Button release is automatic, based on user-adjustable timer, resulting in
button 0 pushed
event
Model WXKG11LM (new revision)
- Single click results in
button 1 pushed
event - Hold for longer than 400ms results in
button 1 held
event - Release of button results in
button 1 released
event - Double click results in
button 1 doubleTapped
event
Model WXKG12LM
- Single click results in
button 1 pushed
event - Hold for longer than 400ms results in
button 1 held
event - Release of button results in
button 1 released
event - Double click results in
button 1 doubleTapped
event - Shaking the button results in
button 2 pushed
event
Changelist (from v0.5)
- Changed driver's name to "Aqara Button"
- Added specific device join names to all the fingerprint entries
- Removed
deviceId
s andendpointId
s from fingerprint entries - added compatibility for the new revision of Model WXKG11LM (ZigBee reported model:
lumi.remote.b1acn01
) with help from Hubitat user @guyeeba - changed event type functionality for Model WXKG12LM to include
DoubleTapableButton
andReleasableButton
capabilities, so thatpushed
,held
,doubleTapped
, andreleased
events are all assigned tobutton 1
, and shaking the button results in abutton 2 pushed
event. - added a routine to determine model at time pairing / when saving preferences and set appropriate number of buttons available to Hubitat apps
- added
buttonPressedTime
,buttonHeldTime
, andbuttonReleasedTime
attributes used for generating human-readable date/time stamp events which can be utilized for Habitat dashboard display - Renamed custom attributes
lastCheckin
,buttonPressed
,buttonHeld
, andbuttonReleased
tolastCheckinEpoch
,buttonPressedEpoch
,buttonHeldEpoch
, andbuttonReleasedEpoch
, respectively - renamed
updateCoREEvent()
toupdateDateTimeStamp
- Removed all references to WebCoRE for use of Epoch-time/date stamp custom attribute events and replaced with "Apps that can use Epoch time/date stamps"
- changed default battery voltage range used for calculating percentage to 2.9 V minimum / 3.05 V maximum
Fixed error in info log messages displayed when button is pushed, double-clicked, held, etc. - removed redundant call to
init()
function ininstalled()
- removed
push()
andhold()
command "trap" functions which are no longer necessary - various minor formatting / comments fixes
In my testing, instead of new Date()
, it's better to use new Date().toLocaleString()
which will make sure the time/date stamp is correct for your location's time zone (and presumably 12 or 24-hour clock setting).
However, the above two updates incorporate new Date().toLocaleString()
, so you could just try using those, for the Xiaomi / Aqara Buttons at least.
Ho can I have information like this on Hubitat, Max/Min/Battery screen shoot from ST
Hubitat does not have a graphical mobile app like SmartThings. So the answer is no, this cannot be user interface cannot be presented in the same way using a Hubitat hub.
However, there is a Hubitat feature that allows you to see the visual status for some aspects of device, called the "Dashboard". Please see here for more information:
https://community.hubitat.com/t/hubitat-dashboard-documentation/1347?u=veeceeoh
Vibration sensor:
I'm interested in getting one of these for mail delivery detection. The mailbox is all-metal and I plan to mount it on the underside. For delivery, the latch is pretty sturdy, so the box shakes when it is opened/closed. Do you think this will detect the box vibrations?