You leave your ST hub active and load the Other Hub Event Pusher, and BAM all your hubitat devices show in the ST mobile app and can be controlled ! The setup has about 12 steps, just go slow and read carefully. You'll need to install apps on BOTH hubitat & smartthings to get this working.
I just had to redo my whole setup last night, as I discovered my device prefix was too long and resulted in cutting off critical sensor names. I reccommend the prefix of "H", that's it
We have Kevin Laframboise to thank for developing this amazing app
That's correct. I set up the mechanism in the device driver for changing the sensitivity level, but it's missing the correct command to send to the sensor. I have some good news, though:
Just in the last couple of weeks, I have figured out what the correct command should be. Also, after a bunch of reading and viewing of YouTube video reviews of the vibration sensor, I realized that when used with the Xiaomi/Aqara hub, the user must push the reset button on the sensor itself after selecting the sensitivity level in the Xiaomi mobile app.
I believe the reason for this is that short-pressing the sensor's reset button is the only way to make sure it is "awake" and ready to receive the change sensitivity level command.
So, in my next beta version of the device driver (which I am releasing today!) the method for changing the sensitivity level has been changed so that each press of the reset button on the sensor will cycle through the sensitivity levels.
HOWEVER... In my testing, I still don't see any evidence that the sensitivity level is changing. Unfortunately, the sensor won't respond to what are called "read attribute" commands, which is the only way to check if the sensitivity level has changed. Except if you have a ZigBee network sniffer device.
So I have ordered a ZigBee sniffer, and hope with the help of that to be able to put this to bed after it's arrived.
Whe you receive the sniffer there are a couple tests that would be interesting for you to do (in the back of my current ordeal with support).
Have it sniffing a few devices that are connected to the HE radio directly and through an IKEA outlet for example. Just curious if the outlets will do some "translation" services.
I'm surprised you couldn't do this with the xbee. I was googling it earlier and got side tracked by work related stuff. Damn work. Would have been a nice bonus with xbee.
[BETA] v0.7b of Aqara Vibration Sensor Device Driver
The new beta device driver code can be found here .
Although the main functionality of the driver remains the same, I've made significant changes "under the hood", especially in terms of how events are reported as well as adding control over the volume of custom events that are reported. This is a change I am planning to make to all of the Xiaomi/Aqara device drivers moving forward.
Beyond this, there are some new preference settings that can be accessed in the device details page, and probably the most important change is that I am now very very close to getting the sensitivity level change function working.
Major Changes
Changing the sensitivity level
As mentioned in my previous post, I realized that the sensor's reset button must be short-pressed before the command to change the sensitivity level is sent. So the "button" in the device details page has been removed, and now the only way to send the sensitivity level change command is by short-pressing the reset button.
The setting will cycle through the 3 levels on each press: low -> medium -> high -> low, etc. However, in my testing, the sensitivity level still does not seem to be changing and the only way I can troubleshoot at this point is by using a ZigBee network sniffer. I have ordered one and will post my findings here as soon as I've received it and got it working. If you happen to have a ZigBee sniffer and an Aqara Vibration sensor, please let me know if you'd like to try to help before my sniffer arrives.
Time/Date stamp events are now optional(default = disabled)
There are a number of custom time/date attributes I included in the device driver for users that would like to use either for displaying the time/date of the last instance of a particular event, or to use with WebCoRE (if you dare) or other automation apps that may need the (UNIX) Epoch-based date format.
All of the custom attributes begin with last and the human-readable time/date stamp ones end with Time and the Epoch-based ones end with Epoch. So for example if you want to display the time/date stamp of the last time the hub received any message from the sensor in a Hubitat Dashboard, you'd want to use the attribute lastCheckinTime.
However, these custom attributes add a good number of extra events that some people would rather not clutter up their events list. So starting with this beta device driver, I am adding preference settings to enable/disable lastCheckin events, and another setting for all of the other last_____ events. The default for these settings is disabled so if you've been making use of any of them, you'll need to go to the device details page for the sensor and enable them, like this:
New setting: Margin of error for open/close position
The open/close contact feature of this driver uses some "complex" math to convert the accelerometer XYZ data to a position in 3D space, but since doors and things don't always open or close in exactly the same position, there needs to be some way to adjust how far off from the originally set open/close positions the sensor can be in order to be considered in the open or closed positions.
That margin of error value is now opened up to users to adjust as seen in the above screenshot. The default is 10.0, and larger numbers will increase the range of positions that will be considered open/closed. Don't ask me how many inches there are to a change of 1.0 in the value, because it doesn't work that way! It's based on the XYZ angles, so this is a setting that needs to be tested for each particular use case/installation.
Repeat/redundant events are not posted anymore
Another thing I am changing in the Xiaomi/Aqara device drivers to reduce "clutter" in the events lists is to stop posting events that are redundant or repeats of the same information. This is a really important thing to be aware of if you have been looking at battery percentage reports as an indication of "device" health. With this change, battery events will only occur when the percentage changes from the previous value. There is one exception to this, which is TiltAngle events, because it is entirely possible for the sensor position to change with the same change in tilt angle as the last time the sensor was tilted.
Note that this change to the way events are posted does not change info and debug log output (if it has been enabled in the preference settings).
Other Changes
See the Detailed Change List, below.
IMPORTANT: For detailed information on the features / functionality of this device driver, please see my post from the initial beta release. For quick reference, here's a chart of the available functions taken from that post:
Changed method of changing sensitivity level - the sensor's reset button must be short-pressed to cycle through levels (low > medium > high > low, etc.)
Renamed custom attributes lastCheckin, lastDrop, lastStationary, lastTilt and lastVibration to lastCheckinEpoch, lastDropEpoch, lastStationaryEpoch, lastTiltEpoch, and lastVibrationEpoch, respectively
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"
Added Preference Settings to enable/disable all events that use 1) custom attributes lastCheckinEpoch and lastCheckinTime, and 2) all custom time/date stamp attributes (e.g., lastDropEpoch, lastDropTime, etc.) with a default of DISABLED for both settings
Added Preference Setting to change the "Margin of Error" range value used when determining whether the sensor's position matches either of the user-set open / close positions
Changed method of storing current XYZ angle values (angleX, angleY, angleZ) to state objects (currentAngleX, currentAngleY, currentAngleZ) instead of custom attribute events
Removed Three Axis capability and recording of threeAxis events
Removed isStateChange: true parameter from all events except TiltAngle to avoid any redundant repeat events being posted
Removed unnecessary displayed: true & false parameter from all events
Removed redundant vibration/movement, tilt, and drop detection description text from motion active, acceleration active, and button pushed events
Fixed reset battery replaced date command function
Change date formate used for battery replaced date to MMM dd yyyy (e.g., "Jan 17 2019")
Improved initialization and configuration when sensor is first paired
Reorganized code (order of functions, some refactoring)
Added more (hopefully) helpful comments to code
Edited and cleaned up log and event description output
So a Xiaomi Button fell into my lap.
I was trying to see what all of the buzz was about.
I got stuck initializing while trying to connect it.
I grabbed the Zigbee address and pasted it into a virtual device with a driver I found here.
It wasn't really working, and I wanted to try to re-pair it but when I try to delete it I get an Error 500: A Server error has occurred.
I know support is taking a break or ramping back up.
Anyone here have this issue?
No, but searching for "Error 500:" leads me to think it may be related to the model, etc. name fields found in the "Data" section of the device information not being populated because you made a virtual device for the Xiaomi Button.
If you can't revert using a previous hub backup, I'd suggest blanking out the Zigbee Id, changing the Device Network to a random word, and changing the device Type to some generic Hubitat built-in driver, hit "Save Device" and then try removing the device.
Which button did you get? The circular one (model WXKG01LM)?
That worked.
Then I successfully paired the device next time and now the next day it's stopped working.
I think this thing will fall out of my lap right about now.
I'm thinking it "fell off" the zigbee network...
If you have any Zigbee devices that act as repeaters, then yes that's probably what happened.
Here's the story:
Xiaomi devices aren't very well-behaved guests of the Zigbee mesh party.
Although Hubitat made the party host (your hub) a little more patient about how often Zigbee guests should check in with it, most assistant hosts (repeater devices) aren't as patient and follow strict rules about kicking guests off the Zigbee mesh party list if they don't check in frequently enough. And Xiaomi devices are slow to check in, so the assistant hosts give them the boot.
Then when Xiaomi devices finally try to check in, even though the hub or repeater requests them to rejoin the party, those little rebellious devils simply refuse to do as told. Bad Zigbee citizens!
The way us Xiaomi lovers get around that problem is to only let lenient assistant hosts (repeater devices) join the Zigbee mesh party. XBees and IKEA Tradfri Smart Outlets are two such devices friendly to Xiaomi devices.
Excellent explanation, I was a big Xiaomi zigbee hater, but after looking and looking and get angry with their prices I finally used a spare hub exclusively for Xiaomi and Tradfri plugs, after having a stable mesh I ordered 8 contact sensors, 2 cubes and 1 motion, they arrive in February but I keep my 2 humidity sensors and 2 Tradfri playing nice until I get the rest of the party.
Using a second Hubitat Hub just for Xiaomi devices is a perfect workaround to the checkin timeout / rejoin issue, by creating a "sandbox" environment. I missed my chance with their recent discount sale, but I plan to get a second Hubitat in future when there's a good deal (or someone sells one!)
If you need any info from my hub I'm available, right now I just have zigbee for Xiaomi and Tradfri, z wave is turned off. I had plans to get a sniffer but I'm not a coder so I have no use for the data.
I just installed 2 Xiaomi door contacts yesterday, they are working great, love the size, price and speed. I have some more coming and a few motion sensors too. I have 5 ikea tradfri outlets splashed around the house/garage so maybe thats why im having good luck with them, granted its only been a short time
Thanks for the breakdown. The only zigbee repeater near the button overnight is an Ikea Tradfri switch oddly enough. I'll be returning it to the kind friend. I'll just buy another Samsung button when the time is right.
What do you think about using our old smartthings hub for the xiaomi devices? I too have becoming frustrated with them dropping off, but I have too many xiaomi devices to just scrap them... Would smartthings give them the boot because of the aforementioned check in frequency?
