Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding pressure capabilities for the Xiaomi Aqara Temperature Humidit… #6

Open
wants to merge 761 commits into
base: master
Choose a base branch
from

Conversation

bspranger
Copy link

…y Sensor

@bspranger
Copy link
Author

I am trying to create new DH for the Aqara sensors.

tmleafs and others added 29 commits February 8, 2018 11:22
Fix
• The section{} dividers don't do anythings in device handlers, so I removed and replaced them with comments as @tmleafs has done in his current Pull Request
• removed attribute "multiAttributesIcon", "String", a remnant of my failed attempt to use a state object variable in the tiles{} section
• I moved the parseTemperature() function up above parseCatchAllMessage() to match the order of parsing functions in the main parse() routine

No change in how the code runs whatsoever
• The "original" Xiaomi T/H sensor has the text of the Battery Changed tile on one line, and fits just fine, so I changed it here to match
Fixes
• Applied all fixes from the Aqara T/H sensor code overhaul not already applied by @tmleafs
• Removed any unnecessary code including anything to do with pressure report parsing, and also battery voltage parse on reset button press (because the original Xiaomi devices don't provide that function)

Enhancements
• Applied all enhancements and new features from the Aqara T/H sensor code overhaul not already applied by @tmleafs

This device handler is now identical to one for the Aqara T/H, just without any code for pressure reporting or battery report on reset button press, and of course the fingerprint profileId is different
• Added code to divide the raw battery voltage value by 100 if the value is below 1000, based on a user report showing a battery raw voltage reading well below 1V that seems to have resulted from the final zero of the original 4 digit integer value being dropped
• Added code to divide the raw battery voltage value by 100 if the value is below 1000, based on a user report showing a battery raw voltage reading well below 1V that seems to have resulted from the final zero of the original 4 digit integer value being dropped
• Added code to divide the raw battery voltage value by 100 if the value is below 1000, based on a user report showing a battery raw voltage reading well below 1V that seems to have resulted from the final zero of the original 4 digit integer value being dropped
• Added code to divide the raw battery voltage value by 100 if the value is below 1000, based on a user report showing a battery raw voltage reading well below 1V that seems to have resulted from the final zero of the original 4 digit integer value being dropped
• Added code to divide the raw battery voltage value by 100 if the value is below 1000, based on a user report showing a battery raw voltage reading well below 1V that seems to have resulted from the final zero of the original 4 digit integer value being dropped
• Added code to divide the raw battery voltage value by 100 if the value is below 1000, based on a user report showing a battery raw voltage reading well below 1V that seems to have resulted from the final zero of the original 4 digit integer value being dropped
• Added code to divide the raw battery voltage value by 100 if the value is below 1000, based on a user report showing a battery raw voltage reading well below 1V that seems to have resulted from the final zero of the original 4 digit integer value being dropped
• Added code to divide the raw battery voltage value by 100 if the value is below 1000, based on a user report showing a battery raw voltage reading well below 1V that seems to have resulted from the final zero of the original 4 digit integer value being dropped
• Added code to divide the raw battery voltage value by 100 if the value is below 1000, based on a user report showing a battery raw voltage reading well below 1V that seems to have resulted from the final zero of the original 4 digit integer value being dropped
I have gone through all of the Aqara Motion Detector DTH code, and after removing unnecessary function calls and lines of code, removing error-prone code, and looking at the motion reset preference issue, I have discovered that this device is capable of continuous motion detection!!! This is an amazing revelation considering it's price.

It turns out that as long as there is motion detected, it repeatedly sends a read attr - raw: message, usually along with an illuminance reading. The message is the same every time: endpoint: 01, cluster: 0406, size: 08, attrId: 0000, encoding: 18, value: 01. As soon as the motion stops, the sensor stops sending the message, but it doesn't send any "inactivity" message (which would be value 00 in this case).

So the trick is to still use the runIn() scheduler to reset back to the 'no motion' / inactivity state that was already in the code, but find the magic number of seconds that will allow the motion detection events to overlap and is short enough to go back to no motion very soon after the motion has actually stopped being detected.

The magic number I came up with in my testing is 7 seconds. Shorter than that and then the state alternates between motion & no motion while I move around. Longer than 7, and it starts to feel like a lag or delay after I've stopped moving.

However, I assume other people may find a different ideal number, so I changed the preference setting slightly, to only accept values from 1 to 60 seconds, and the description has been changed (and it's much shorter!)

I am extremely happy with how the code is working, but I really want some others to test it to see how if works for them.

I also need to go through the "original" motion detector code to clean it up as well, and then someone who actually has one of those needs to do some testing to find out if it also is capable of continuous motion detection.

Note that I created this Pull Request commit off of @tmleafs Standardization branch, so it should be merged first and this one afterwards.
veeceeoh and others added 30 commits September 26, 2018 00:22
Changes
* The UI main tile now displays correct vibration, tilt, and drop events as they happen
* Main UI tile displays these statuses: "Stationary", "Vibration/Shock", "Tilt", or "Drop"
* The secondary information in the main UI tile has been changed to display the date/time of the most recent event of any kind
* The other UI tiles have been rearranged to 3-Axis & Battery in first row, Angle Change, Vibration Level, and Sensitivity Level in the second, followed by the Battery Changed date in the last row
* Events for vibration (Motion = _active_), tilt (Acceleration = _active_), and drop (Button = _pushed_) correctly occur and are displayed in events list
* Added user preference setting for time until Vibration/Shock status is cleared and Motion state reset to _inactive_. The default is 65 seconds.
* Tilt (Acceleration = _active_) events are now automatically reset after 2 seconds to "Stationary" / Acceleration = _inactive_
* Drop event status is now automatically reset after 2 seconds to "Stationary"
* The hardware sensitivity level setting can now be changed by pressing the "Sensitivity Level:" UI tile. The preference setting for setting the sensitivity level has been removed.
* Fixed parsing of model name message when reset button is short-pressed
* Changed device Health Check interval time to 3 hours, 2 minutes to allow two missed check-ins before Health Check (if enabled) marks the sensor as "offline"
* Changed battery report log message from [debug] to [info] log message type
* Minor fixes to formatting of event / log message output

Still to do
* Implement open/close position functionality, using Accelerometer XYZ values to store user-set positions, which trigger Contact = _open / close_ events
* Clean up of UI
Changes:
* Added "Motion Sensor" capability so vibration events can be used in SmartApps.
Changes & Fixes
* Added NEW FEATURE: Open/Close position, which links to the Contact Sensor capability. Using code kindly shared by GitHub user @_Oltman, custom open and close positions can be stored by pressing the _Set Open_ and _Set Closed_ UI tile buttons while the sensor is in your desired open & closed positions. Once set, the DTH will generate `contact - open` and `contact - closed` events when the sensor is in nearly the same positions. 
* Changed the method to initially set and display hardware Sensitivity level when the sensor is paired (If sensor is already installed, open preferences and press "save" to set up the Sensitivity level UI button.
* Improved the code that cycles through the 3 levels when Sensitivity level UI button is pushed
* Changed "Vibration Level" to more representative name "Last Activity Level"
* Moved code to reset to Stationary status from `updated()` to `configure()` so that that status isn't reset to _Stationary_ when preference settings are saved, instead only resetting it when the sensor is first paired
* Added code to initialize _Last Activity Level_ and _Last Angle Change_ UI tiles to display "--" if no reported values have been received yet.
* Various code cleanup and formatting fixes
Changes
* Added two new UI tiles to display current `Motion` (vibration) and `Acceleration` (tilt) states
* Added "refresh" tile to initialize blank UI tiles if needed
* Removed icon displayed in main sensor status tile
* Reorganized UI tiles
* Fixed object names in code that handles closed/open position calculations
* Added check that open/close position have been set by the user before comparing stored positions to current calculated position
* Changed set Open/Closed position code to immediately send `contact - open` or `contact - closed` event
* Fix mapSensorEvent to correctly set a status reset timer of 2 seconds for Tilt or Drop events
* Changed the timer reset code for Tilt/Drop events: If a Vibration/Shock event is followed by any Tilt or Drop events, the main UI tile will display "Tilt" or "Drop" for approximately 2 seconds, and then change back to display the "Vibration/Shock" status until the Vibration/Shock reset timer is finished (or until another different event occurs.)
* Changed calculated Psi, Phi, & Theta angle precision level to 0.1
* Added info log messages to report open/close/unknown position
* Added info log messages to report successfully set open/close positions
* Reorganized and cleaned up code
Changes/Fixes
* UI Refresh code now correctly initializes and displays the sensitivity level at low when the sensor is paired, or if not initialized at pairing, when the user saves preferences or presses the refresh UI tile button
* Added initialization of a "blank" battery UI tile at pairing (or when preferences are saved / refresh UI tile button is pressed). Like with all Xiaomi devices, the battery tile will only display a percentage after the first battery voltage report is sent by the sensor, usually 1 or 2 hours after pairing.
Changes

* Removed initialization of battery UI tile because sending an event with a value of "--" seems to prevent a newly paired sensor from being added to the SmartThings device list in the "Classic" mobile app.
changelist
* added parsing of current wattage power load messages from the outlet
* added generation of power load events
* added parsing of wattage power metering messages from the outlet
* added generation of power metering events
* added device power and energy meter value display tiles
Add power metering to power support to device handler
This driver is being added for users of SmartThings hubs still running firmware version 24.x and older.

SmartThings v2/v3 hub owners running firmware 25.20 and newer should use either:
* xiaomi-aqara-button.groovy for Aqara Button models WXKG11LM / WXKG12LM
* xiaomi-aqara-wireless-switch.groovy for Aqara Wireless Smart Light Switch models WXKG02LM / WXKG03LM
This driver is being added for users of SmartThings hubs still running firmware version 24.x and older.

SmartThings v2/v3 hub owners running firmware 25.20 and newer should use the xiaomi-button.groovy device driver.
changelist
* added support for multi-click actions (double, triple, quadruple, and > 5-click)
* removed preference setting to send `button 2 pushed` event on hold (button hold now always sends `button 1 held` event)
* added method imports to match device handlers on GitHub/SmartThingsPublic
* removed unneeded `endpointId` and `profileId` from device fingerprint
* added `ocfDeviceType` to definition in attempt to get device handler working with new SmartThings Samsung Connect mobile app
* added preliminary support for Device Watch
* added initial button event for proper configuration during device pairing
* improved followup in `updated()` after user saves preference settings
* added more helpful inline comments to code
* minor code cleanup and reorganization
changelist
* Model WXKG11LM (original revision) - added compatibility with hub firmware v25.20 and newer
* Model WXKG11LM (original revision) - added support for multi-click actions (double-, triple-, and quadruple-click)
* Model WXKG11LM (new revision) - added support for "button 3 pushed" event when button is released after being held
* Model WXKG12LM - added support for "button 4 pushed" event when button is released after being held
* added method imports to match official device handlers on GitHub/SmartThingsPublic
* removed unneeded `endpointId` and `profileId` from device fingerprint
* added `ocfDeviceType` to definition in attempt to get device handler working with new SmartThings Samsung Connect mobile app
* added preliminary support for Device Watch
* added incompatible device handler warning to users running firmware 24.x or earlier
* added initial button event for proper configuration during device pairing
* improved followup in `updated()` after user saves preference settings
* added more helpful inline comments to code
* minor code cleanup and reorganization
changelist
* Model WXKG11LM (original revision) - fixed an issue where single-click messages were not correctly recognized
* removed duplicate call to `initialization()` because model information is normally not available until `configure()` is called during pairing
changelist
* Model WXKG11LM (original revision) - all button click actions should now generate correct `button pushed` events
* Model WXKG11LM (original revision) - all button click actions should now be correctly displayed in main tile for the button viewed in the SmartThings Classic mobile app
changelist
* Model WXKG11LM (original revision) - all button click actions should now generate correct `button pushed` events
* Model WXKG11LM (original revision) - all button click actions should now be correctly displayed in main tile for the button viewed in the SmartThings Classic mobile app
This driver has been added for users of SmartThings hubs still running firmware version 24.x and older.

SmartThings v2/v3 hub owners running firmware 25.20 and newer should use either:
* xiaomi-aqara-button.groovy for Aqara Button models WXKG11LM / WXKG12LM
* xiaomi-aqara-wireless-switch.groovy for Aqara Wireless Smart Light Switch models WXKG02LM / WXKG03LM
Aqara Wireless Smart Light Switch
Models WXKG02LM / WXKG03LM (2016 & 2018 revisions)
Initial beta release v0.9b

This device handler was split off from the "old" Aqara Button device handler in order to best support the two revisions of the one and two-button Aqara Wireless Smart Light Switches. The code has been written so that this device handler can be used with any firmware version, but for users with hub running on Firmware 25.20 or newer, all three actions of the older 2016 revision two-button model WXKG02LM are now recognized: left, right, and both button(s) pushed.

Although this device handler is still considered in beta, it should be fully functional.

initial release notes
* started with v1.3.5 of Aqara Button device handler and removed all references to square Aqara Button
* 2-button model WXKG02LM (2016 revision) - added firmware 25.20 & newer support for all three possible actions: press left/right/both button(s)
* 1-button model WXKG03LM (2018 revision) - completed support for all 3 possible actions: press/hold/double-click button
* 2-button model WXKG03LM (2018 revision) - completed support for all 6 possible actions: press/hold/double-click left/right/both button(s)
* added method imports to match device handlers on GitHub/SmartThingsPublic
* removed unneeded `endpointId` and `profileId` from device fingerprint
* added `ocfDeviceType` to definition in attempt to get device handler working with new SmartThings Samsung Connect mobile app
* added preliminary support for Device Watch
* refactored "raw" read attribute message parse code
* improved identification of model and revision at pairing to correctly set number of buttons available to Smart Apps
* added initial button event for proper configuration during device pairing
* improved followup in `updated()` after user saves preference settings
* added more helpful inline comments to code
* minor code cleanup and reorganization
Changelist
* Fixed log output and event description text for 1-button model WXKG03LM (2018 revision) to use "Button was..." instead of "Left button was..."
changelist
* Fixed incorrect code used to calculate kiloWatt/hour energy usage (thanks for @Tiago_Goncalves for spotting the issue)
* Added lastCheckinDate attribute for Epoch time/date stamp events that can be used with WebCoRE
* Added Temperature Offset preference setting
* Added device name to all debug messages
* Improved `refresh` command function
* Improved text of debug messages for clarity
* Removed unnecessary / unused code in `parse()`
* Minor code reformatting
changelist
* changed device definition name to hopefully get GitHub Integration to work correctly
changelist
* changed device definition name to hopefully get GitHub Integration to work correctly
changelist
* changed device definition name to hopefully get GitHub Integration to work correctly
changelist
* changed device definition name to get GitHub Integration to work correctly
changelist
* changed device definition name to get GitHub Integration to work correctly
changelist
* Fixed incorrect code used to calculate kiloWatt/hour energy usage (thanks for @Tiago_Goncalves for spotting the issue)
* Added lastCheckinDate attribute for Epoch time/date stamp events that can be used with WebCoRE
* Added Temperature Offset preference setting
* Added device name to all debug messages
* Improved `refresh` command function
* Improved text of debug messages for clarity
* Removed unnecessary / unused code in `parse()`
* Minor code reformatting
changelist
* fixed issue with erroneous battery level events from `catchall:` messages that don't actually contain battery voltage data
changelist
* added additional fingerprint lines to help correctly pair variants of this sensor model
changelist
* added model designation to header section of code
* added additional fingerprint lines to help correctly pair variants of this sensor model
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.