I have a bunch of both type of the Temperature-Humidity sensors, and they are all reporting with normal expected values. When testing the updated code, I also tried testing both kinds in the freezer, looking at F and C values. No issues.
Can you double check that you're using version 0.8.1 of the Xiaomi Temperature Humidity Sensor driver, and if yes and you don't mind - please PM me with some log output with both info and debug messages enabled, thanks!
Ok just doublechecking the device driver I'm using: Version 0.8.1 and hub firmware 2.0.5.
I have two that read humidity and one that doesn't (I think the square type?) The ones with humidity are working fine now. Here's the current reading from the funky one:
#### Current States
* battery : **83**
* batteryLastReplaced : **Tue Nov 27 23:55:31 PST 2018**
* humidity : **112.9**
* temperature : **-166.0**
* endpointId: **01**
* application: **02**
* model: **lumi.sensor_ht**
* manufacturer:
Last activity: 2019-02-21 4:53:12 PM PST
Maybe it's just broken? I'll re-pair it tonight to see what is going on. I do know before I updated the device driver v0.8.1, all 3 had wildly odd readings... but now it's just this one. I'm not home so I can look at it to confirm if it's the square or round type.
Ok nevermind -- I went to take a look at it at home and now it's working. Who knows ... maybe it was somehow just never updating? Either way, works now so thank you!
####
Current States
* battery : **83**
* batteryLastReplaced : **Tue Nov 27 23:55:31 PST 2018**
* humidity : **54.0**
* temperature : **65.5**
[UPDATE] v0.3b of Xiaomi Mi Cube Controller device driver for Hubitat
I have completed some significant reworking of the code so that all the cube's functions (shake, flip, rotate, slide, and knock) are correctly recognized and generate the corresponding button X pushed events (according to the "cube mode" set in the device's preference settings), along with much more meaningful info log messages as feedback.
The updated working beta device driver code can be grabbed from here.
PLEASE NOTE: This driver is still in beta, and its features and functionality may change.
Major Changes
Resolved all issues with lost functionality in driver v0.2.1b
All cube actions (shake, flip, rotate, slide, and knock) will generate button X pushed events, but I need to evaluate the usefulness of simultaneous button pushed messages for some cube actions when the driver's "cube mode" is set to "Combined". Also, this driver produces a large number of events, and I plan to look at reducing that and making it more efficient.
Helpful info log message output has been added
With "info message logging" enabled in the preference settings, much more relevant and useful log messages will be output for all cube actions.
The voltage range for Battery % has been changed
The minimum / maximum voltage values used to calculate battery percentage have been changed from 2.5V min / 3.0V max to 2.9V min / 3.05V max. This means your reported battery percentages will change from what you have been seeing! It should not be a cause for alarm, however. Keep in mind that using the min / max voltage values to calculate a battery percentage only gives a very very rough estimate of battery health. Also, remember that the min / max voltage values can be changed in the preference settings in the device details page for each sensor.
Added Human Readable Time/Date stamp attributes for Dashboard use
This driver had originally included a custom lastCheckin attribute to produce (UNIX) Epoch-based date format time/date stamps for users. Now users that would like to show the the time/date of the last instance of a particular event in a Hubitat Dashboard can use lastCheckinTime. This is in addition to the original time/date attribute which has been renamed to lastCheckinEpoch. I plan to add custom lastPushedTime / lastPushedEpoch attributes in a future update.
Battery % events will only occur when there's a change in the value
The lastCheckinTime and lastCheckinEpoch attributes will now only generate an event when the check in / battery report message is received from the sensor (either every 50 or 60 minutes, depending on the model), or when the reset button is short-pressed. So, if you've been relying on battery percentage reports to know whether your sensor is still on the ZigBee mesh network, then you'll need to enable and start looking at the lastCheckinTime / lastCheckinEpoch events (see the next change, below).
Time/Date stamp events are now optional(default = disabled)
Custom attributes can add dozens of extra events each day that some people say they would rather not have clutter up their events list. So I've added a preference setting to enable/disable time/date stamp events, one for lastCheckin... The default for this setting is disabled so if you've been making use of any of time/date events, you'll need to go to the device details page for the sensor and enable them.
Detailed Release Notes
Resolved all issues with lost functionality in driver v0.2.1b
Reworked and refactored message parsing code
Removed unused and unnecessary functions, function calls, and custom attributes
Improved info log message output to provide much more helpful and relevant log messages
Fixed debug message output behavior so that "Enable debug message logging" now controls all debug message log output
Added new preference setting to enable generation of lastCheckin___ time/date stamp events. NOTE: the default setting is DISABLED.
Renamed custom attribute lastCheckin to lastCheckinTime, to be used to generate human readable time/date stamp events
Removed any references to WebCoRE for use of Epoch-time/date stamp custom attribute events and replaced with "Apps that can use Epoch time/date stamps"
Added lastCheckinEpoch attrubute, used to generate Epoch time/date stamp events
Changed lastCheckin____ events to only occur when the sensor checks in (at same time as when battery voltage is reported)
Removed isStateChange: true in a number of instances to reduce the number of redundant repeat value events generated by the driver.
Changed default min/max battery voltages to 2.9V/3.05V
Other fixes, reformatting, and reorganization of code
Tagging @vjv and @andrew.rowbottom so you see this driver update - please give it a try and let me know how it works for you!
Just a quick note regarding the updated Xiaomi Mi Cube driver:
I realized this morning that the function to set the number of available buttons based on the Cube Mode set in preferences is not working correctly. There are a number of other minor issues as well.
I have been working fixing these issues as well as on documentation on how to use the driver, but I have run out of time for today, and probably for the rest of the weekend. I will try my best to finish up work on all of that, but it may not come until early next week.
I noticed something odd in the rotation, it just works the first try, for example if you rotate left works but if you continue and rotate again left it doesn't work, so if you rotate right it works, then rotate left it works, then rotate left again doesn't work, rotating is a great way to change the brightness, I noticed the rotate buttons are doing the same, but in the previous driver the rotate buttons worked fine but not the physical rotation of the cube. Thanks for you efforts, take your time.
Edit, I noticed that the problem is on other functions/buttons too, for example if you shake it work but if you shake again it doesn't work, you must use another function like slide then shake to make it work. I reverted the driver to the previous version.
I have attempted to address the errors reported by @earlgreytea, but since I do not own a Xiaomi MiJia Honeywell Smoke Detector, I have to ask that anyone who has this device please try out this updated beta driver, and either PM or post here with any feedback or log output (in the case you experience errors or unwanted behavior).
The beta code is available at a special temporary location here.
EDIT: The driver has been updated and taken out of beta. Please see this post for more information.
Major Changes
Hopefully resolved reported error and other issues introduced in driver v0.5.1
Added Human Readable Time/Date stamp attributes for Dashboard use
This driver had originally included a custom lastCheckin, lastClear, lastDetected, and lastTested attributes to produce (UNIX) Epoch-based date format time/date stamps for users. Now users who would like to show the the time/date of the last instance of a particular event in a Hubitat Dashboard can use lastCheckinTime, lastClearTime, lastDetectedTime, and lastTestedTime. This is in addition to the original time/date attributes which have been renamed to lastCheckinEpoch, lastClearEpoch, lastDetectedEpoch, and lastTestedEpoch.
Battery % events will only occur when there's a change in the value
The lastCheckinTime and lastCheckinEpoch attributes will now only generate an event when the check in / battery report message is received from the sensor (either every 50 or 60 minutes, depending on the model), or when the reset button is short-pressed. So, if you've been relying on battery percentage reports to know whether your sensor is still on the ZigBee mesh network, then you'll need to enable and start looking at the lastCheckinTime / lastCheckinEpoch events (see the next change, below).
Time/Date stamp events are now optional (default = disabled)
Custom attributes can add dozens of extra events each day that some people say they would rather not have clutter up their events list. So I've added two preference settings to enable/disable time/date stamp events, one for lastCheckin___, and another for the other time/date stamp events (lastClear___, lastDetected___, and lastTested___). The default for this setting is disabled so if you've been making use of any of time/date events, you'll need to go to the device details page for the sensor and enable them.
Detailed Release Notes
Reworked and refactored message parse code to (hopefully) eliminate errors introduced in driver v0.5.1
Corrected an undefined object used when parsing IAS Enroll Request messages
Fixed debug message output behavior so that "Enable debug message logging" now controls all debug message log output
Renamed custom attributes lastCheckin, lastClear, lastDetected, and lastTested to lastCheckinEpoch, lastClearEpoch, lastDetectedEpoch, and lastTestedEpoch, respectively, used to generate Epoch time/date stamp events
Removed any references to WebCoRE for use of Epoch-time/date stamp custom attribute events and replaced with "Apps that can use Epoch time/date stamps"
Added lastCheckinTime, lastClearTime, lastDetectedTime, and lastTestedTime custom attributes, to be used to generate human readable time/date stamp events
Changed lastCheckin___ events to only occur when the sensor checks in (at same time as when battery voltage is reported)
Added two new preference settings, one to enable generation of lastCheckin___ time/date stamp events, and the other to enable lastClear___, lastDetected___, and lastTested___ time/date stamp events. NOTE: the default setting is DISABLED.
Removed isStateChange: true in a number of instances to reduce the number of redundant repeat value events generated by the driver.
Other fixes, reformatting, and reorganization of code
Yes. Can you give the above linked updated beta driver code a try and let me know whether it's working as expected?
That error was just on the line that outputs an "info" log message of the Description Text of the event about to be generated.
From that log output it looks like you first had an "All Clear" message, and then a checkin / battery report message. If you look at your smoke detector's Events list, you should hopefully see that those events were still correctly generated.
However, I've identified the cause of the error, and fixed it. It's so minor that I didn't change the version number.
The link to the fixed beta code is the same as above, here.
Thanks for reporting back and please let me know how this works for you.
[UPDATE] v0.3.1b of Xiaomi Mi Cube Controller device driver for Hubitat
After more testing with the v0.3b update, I realized that the method to set the number of buttons according to the Cube Mode selected in preferences wasn't working correctly. Also, I saw that the cube occasionally sends catchall: messages which are of no use, but produce (harmless errors.) Those issues have been fixed. Finally, I re-did the fingerprint data used to match the driver to the cube during pairing, it's working perfectly (for me, at least.)
The updated device driver code can be grabbed from here.
PLEASE NOTE: This driver is still in beta, and its features and functionality may change.
Change List
Added conditional check for catchall: messages to avoid unwanted java exception errors
Removed unused EnrollResponse command and Actuator attribute
Edited fingerprint data to improve selection of driver during pairing
Fixed issues with setting the correct number of buttons according to the user-selected Cube Mode
With the above v0.3.1b update, I am unable to replicate your experience. Here's some log output to show repeat gestures working just fine with my cube (note the entries below are reversed from normal output order, so the first is on the top, last is on the bottom):
Sample cube log output (click arrow to reveal)
12:10:15.239 am [info] Mi Cube: Updating preference settings
12:10:15.249 am [info] Mi Cube: Number of buttons set to 36
12:10:15.251 am [info] Mi Cube: Info message logging enabled
12:11:40.574 am [info] Mi Cube: Rotated by 29°
12:11:40.619 am [error] java.lang.NullPointerException: Cannot execute null+19 on line 349 (parse)
12:13:08.174 am [info] Mi Cube: Stale face data, updating
12:13:08.179 am [info] Mi Cube: Flip to face #3 detected (button 4 pushed)
12:13:08.182 am [info] Mi Cube: Knock detected with face #3 up (button 16 pushed)
12:13:12.928 am [info] Mi Cube: Rotated by 34°
12:13:12.951 am [info] Mi Cube: Right rotation on face #3 (button 22 pushed)
12:13:18.361 am [info] Mi Cube: Rotated by 16°
12:13:18.370 am [info] Mi Cube: Right rotation on face #3 (button 22 pushed)
12:13:23.163 am [info] Mi Cube: Rotated by -24°
12:13:23.170 am [info] Mi Cube: Left rotation on face #3 (button 28 pushed)
12:13:25.559 am [info] Mi Cube: Rotated by -20°
12:13:25.585 am [info] Mi Cube: Left rotation on face #3 (button 28 pushed)
12:13:31.730 am [info] Mi Cube: Flip to face #5 detected (button 6 pushed)
12:13:36.770 am [info] Mi Cube: Flip to face #0 detected (button 1 pushed)
12:13:40.957 am [info] Mi Cube: Knock detected with face #0 up (button 13 pushed)
12:13:44.846 am [info] Mi Cube: Flip to face #1 detected (button 2 pushed)
12:13:47.355 am [info] Mi Cube: Knock detected with face #1 up (button 14 pushed)
12:13:52.053 am [info] Mi Cube: Shake detected with face #1 up (button 32 pushed)
12:13:54.699 am [info] Mi Cube: Shake detected with face #1 up (button 32 pushed)
12:13:57.767 am [info] Mi Cube: Shake detected with face #1 up (button 32 pushed)
12:14:03.625 am [info] Mi Cube: Stale face data, updating
12:14:03.630 am [info] Mi Cube: Flip to face #2 detected (button 3 pushed)
12:14:03.635 am [info] Mi Cube: Slide detected with face #2 up (button 9 pushed)
12:14:06.497 am [info] Mi Cube: Slide detected with face #2 up (button 9 pushed)
If you are concerned about the driver not acting on messages received from the cube, then enable debug message log output, then you'll see every message the driver receives from the cube. Look for entries that start with Parsing message:
What I see, with my cube at least, is that it doesn't send a message every time I interact with it. For example, I have to be deliberate when I flip it, rather than moving it gently, in order to generate a "flip" message.
Also, if using the Advanced or Combined Cube Mode, keep in mind that sometimes the driver loses track of which face is up if the cube is moved in some way without causing any message being sent. For example, I can rotate the cube around in mid-air, gently set it on a surface, and the driver won't know which face is up anymore. The original author wrote code to extrapolate that as best as can be done, but it's an imperfect science. I will be adding a much more complete post on this thread soon to explain how the driver works as it stands right now, along with all the caveats and limitations due to the way the hardware itself works.
You probably noticed there is a java exception error in my sample log output. This is because it's log output from right after I freshly paired the cube, and the driver doesn't have any way to know what face is up if the first thing you do is rotate it. That's something I need to fix, but it's resolved as soon as another type of gesture occurs which supplies face up data. I'll get to fixing it soon, but that error is not breaking anything, though.
EDIT: I just noticed that my cube is reporting it's battery voltage at 2.735 Volts, below the minimum Volts value, so the percentage is calculated at -110%! It's still working fine, so perhaps I need to consider a lower min Voltage threshold for this particular Xiaomi device. Regardless, I'm going to get a new CR2450 just in case the original battery is near the end of it's useful life. Any observations from other cube users on reported battery voltages would be greatly appreciated!
That's wonderful news! I am going to keep it as a beta until I hear from at least a couple other people with the smoke detector, and then I'll make it "final".
By the way, I de-selected the "Solution" tick-box, because this thread isn't really about trying solve a specific issue.
Thanks again for testing the fixed code and reporting back here, much appreciated!
I finally pulled the trigger and updated my HE Hub with it's latest firmware and updated all of my Xiaomi drivers along with it and everything looks good! All temp sensors are reporting correctly!! Nice work @veeceeoh!!
Thank you for taking your time to analyze my problem, I actually updated 1 of my 2 cubes and still not working properly, but I noticed the problem is with hub link app, I have 2 hubs, one is my regular hub with all devices and rules and the other hub is for Xiaomi and Tradfri, with the older driver the multiple pushes for the same button works fine but the last 2 drivers did not work, I can confirm the Xiaomi hub get the logs and see the multiple pushes of the same button, for example the right rotation, but only one push is transferred to the main hub, this is something that probably HE team should know how to fix it but I have no idea how or how to tell them.
Here's the change I made that has led to this situation:
The isStateChange parameter is part of the event Map data that needs to be returned to the hub using the createEvent() method (or sent as part of a maps using the sendEvent() method) in order to generate an event.
If isStateChange is true then an event will be generated in addition to the value of the attribute being updated. However, if isStateChange is false then no event is generated and only the attribute is updated.
There's no official Hubitat documentation on createEvent() yet, so I have to fall back on SmartThing's documentation here.
Basically, if the isStateChange parameter is not specified in the event Map data, then createEvent() or sendEvent() will decide whether it should be true or false based on the current state of the attribute in question.
So for example, if the driver previously sent a createEvent() for the battery attribute with a (percentage) value of 70, and it then subsequently sends another createEvent() for battery with the same value of 70, no event will be generated for the second instance of a value of 70 if the isStateChange parameter is not included in the createEvent() event map. This makes sense, because the percentage hasn't changed and we don't need to clutter up the events list with redundant repeat values.
However, it appears that this same rule is applied to button pushed events. I find this behavior very strange, because in my opinion button events should not be considered a change in state, since buttons can - and usually do - act as a trigger. The only exception to this would be a button with hardware that sends a release message, which could then be considered a change in state. But many buttons only send a pushed message, and isStateChange needs to be true for every push to result in a new event being fired.
TL;DR: I needed to add isStateChange to ALL button pushed events generated by this driver in order for repeat gestures to work as expected. Here's the update:
[UPDATE] v0.3.1b of Xiaomi Mi Cube Controller device driver for Hubitat
Thanks to @vjv's feedback, I realized that the driver was not generating new events for repeated gestures. This has been fixed such that you should now be able to rotate the cube clockwise ten times in a row and get ten button 22 pushed events!!
The updated beta device driver code can be grabbed from here.
Change List
Added parameter isStateChange: true to ALL button - pushed events sent by the driver
removed all unnecessary instances of displayed: false parameter from all events sent by the driver
By the way, @vjv (and everyone else with a Xiaomi Cube), my plan is to remove all of the Commands (except for "Reset Battery Replaced Date" and "Configure") that appear as buttons in the device details page as seen here:
I can't see any reason for keeping them other than for testing purposes, honestly.
Please let me know if you can think of any good reasons to keep them, because there is an opportunity to significantly optimize the code if I can remove them all.
I finally have my Vibration Sensor working reliably, routed through a Trådfri plug. But, it's not quite sensitive enough. I thought you had recommended a technique - something like resetting and immediately sending the sensitivity command - but I see only the above. Is it possible?
What do the set face commands do? I don't currently use the faces, but if the face the driver thinks is up can get out of sync, it might be useful to be able to sync back up in the driver with those commands.
