Support for Aqara Smart Vibration Sensor DJT11LM

[Cavemanz]

This seems to be a new item just released. Model: DJT11LM. Any plans to get support for it in Deconz?

https://www.gearbest.com/smart-home-controls/pp_009661787808.html?wid=1433363 https://www.aliexpress.com/store/product/Xiaomi-Aqara-Smart-Motion-Sensor-International-Edition/329388_32912246474.html

https://www.youtube.com/watch?v=odnaG2I387U

[paolotremadio]

log.log more logging, hope this will help

[paolotremadio]

I don't seem to be able to capture the 0x0508 anymore. maybe due to the latest changes?

[ebaauw]

It must be

It should be, but we're talking Xiaomi. I meant: do we need to set the Manufacturer Specific bit and include Manufacturer Code in the ZCL header when reading/writing this attribute?

more logging, hope this will help

21:00:38:394 APS-DATA.indication srcAddr: 0x00158d0002a8ad09, dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
21:00:38:395    asdu: 188c0a0805250f0024049000

Gotcha! Data type 25 = u48. The too big values must be a bug in the deCONZ GUI. @manup?

I don't seem to be able to capture the 0x0508 anymore. maybe due to the latest changes?

Yes, the change to general.xml in https://github.com/ebaauw/deconz-rest-plugin/commit/6a61f2ec8a8eb1cd06bbefb7c0c677aa4a877a4b. Could you edit general.xml, revert 0x0508 to u48, restart deCONZ and check again?

[veeceeoh]

It should be, but we're talking Xiaomi. I meant: do we need to set the Manufacturer Specific bit and include Manufacturer Code in the ZCL header when reading/writing this attribute?

Ahh, that is something I have little experience with since on SmartThings there's an abstraction layer between me writing device handler code and the actual ZigBee packet data sent to the device.

But on that webpage I mentioned he does give more specific example frame data and says that the sensor will respond with a "success" message.

[paolotremadio]

u48 works: 3.log

[manup]

Gotcha! Data type 25 = u48. The too big values must be a bug in the deCONZ GUI. @manup?

Yes could possibly be a bug, u48 wasn't used a lot (if any) in the past. I'm out for a mini vacation and back on Monday then I can check the code.

[ebaauw]

But on that webpage I mentioned he does give more specific example frame data and says that the sensor will respond with a "success" message.

Thanks. Yes, it needs the manufacturer-specific bit.

more logging, hope this will help

21:03:21:278 APS-DATA.indication srcAddr: 0x00158d0002a8ad09, dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -58
21:03:21:278    asdu: 18a30a0505230000e500

Attribute 0x0505?! Better add this one to general.xml as well. Data type 23: u32. Also mentioned on the french web page.

21:01:45:159 APS-DATA.indication srcAddr: 0x00158d0002a8ad09, dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -55
21:01:45:159    asdu: 18920a5500210100
21:01:45:159 button 1007 Shake

21:01:45:183 APS-DATA.indication srcAddr: 0x00158d0002a8ad09, dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -55
21:01:45:183    asdu: 18930a5500210300
21:01:45:183 button 1008 Drop

21:01:51:985 APS-DATA.indication srcAddr: 0x00158d0002a8ad09, dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -58
21:01:51:985    asdu: 18950a55002102000305215300
21:01:51:986 button 1009 Tilt

Attribute 0x0503 always seems to be reported in the same message as 0x0055, but only when 0x0055 has value 0x0002 (Tilt). The french web page seems to make the same observation.

[paolotremadio]

0x0505 is not reported (0 on the UI)

[paolotremadio]

@ebaauw just pulled your master. I've noticed that vibrations are not reported as quickly as before (sometimes not reported at all). It is just my impression or you've changed something about it?

[ebaauw]

I only changed general.xml. I don't see how that can influence reporting times.

Did you get attributes reports already for 0x0505? I don't see any in your 3.log.

[oltman]

@veeceeoh Thanks! I already use and build from the bspranger/Xiaomi set of device handlers and started on one myself last night for this sensor. Though right now I am very early and only capturing codes to figure out events, acceleration sensors, etc. I'm happy to help/test/whatever on your device handler if you want a hand (I'll abandon mine in that case). I'd love to have early access to the DH -- hint hint.

[veeceeoh]

Hi there-- eagerly following this to build a smartthings device handler. I think I have decoded 0x0508-- it is the final resting tilt of the device after motion. This needs to be represented by 3 values for x,y,z and acceleration (since they use an accelerometer to detect tilt)

Based on the values seen, it appears that they are the static acceleration values from gravity, and would need to be converted to the current resting tilt angle. But for that to be useful, we need to know what the raw min/max values are, and what range of acceleration (in the unit g) they represent.

The French webpage I've mentioned identifies the accelerometer hardware as an ADXL362. I've read the ADXL362's technical data sheet, and learned these things:

1. The X, Y, Z axis accelerometer data resolution is 12-bit, but is delivered as sign-extended data in 16-bit data registers as seen in this example of the X-Axis Data Register:

Note that bits 15-12, marked as "SX" above, are the sign-extension bits, and always all the same as bit 11. So what is output from the chip itself for the raw acceleration data is a 12-bit two's complement, equating to a raw decimal output range of -2048 to 2047.

2. The ADXL362 also allows for the host to read just 1 byte (the 8 most-significant-bits) of data per axis to conserve on power, but I think the Xiaomi Vibration sensor is just passing on the 2-byte per axis data straight to the ZigBee attribute report frame data. This can be seen in the example reports posted by @oltman:

Testing: Side Up, 0x0508 raw return, decode: 1st digit, 2nd digit, 3rd digit 1 (squiggle), 04ae 002f 001e = 1198, 47, 30 2 (battery), fcb4 002a 0046 = -843, 42, 70 3 (right), 0086 0038 03e5 = 134, 56, 997 4 (left), 0069 0015 fc91 = 105, 21, -878 5 (opp button), 006a fc2d 0073 = 106, -978, 115 6 (button), 0060 0445 ffff = 96, 1093, 0

I notice that the first hex digit of each 2-byte axis data is only either 0 or f which corresponds to the bits 15-12 shown in the example above either being 0000 or 1111. @oltman's decimal equivalents are correct following this logic, though some online two's complement calculators give a number that is -1 off from the negative numbers listed (e.g. -979 instead of -978).

3. The ADXL362 has three user-selectable sensitivity levels (sound familiar???) which allows the acceleration measurement range to be set to +/-2g, +/-4g, or +/-8g.

So in order to know what the XYZ Acceleration Axis output values represent, you need to know which sensitivity range level has been set. For @oltman's tests, I'm going to guess that his sensor is set to the +/-2g sensitivity level with the highest values near around 1024 (1g). The ADXL362 has these diagrams to show what output to expect based on gravity and resting orientation:

Based on this diagram, my guess is that the order of the 3 values as given in @oltman's example reports is 1) Z-Axis, 2) Y-Axis, 3) X-Axis.

My belief is that what Xiaomi calls the "high" sensitivity level is the +/-2g setting on the ADXL362, because small changes in acceleration would result in larger changes in the raw XYZ output values. But this will need some testing to bear that out.

Questions I still have and can't yet answer are: • When there's an attribute report on 0x0503 of tilt angle, how is that calculated and which spatial plane is the tilt for? Is it the angle of the one axis with the largest change, or an interpolation between the starting and ending point of the 3 axis?

• How can the XYZ acceleration data be useful, especially given that the raw output values likely change according to which of the three sensitivity levels the sensor is set to. From what I've seen so far, there's going to need to be margins of error taken into account even for orientations exactly along the three axis of the accelerometer chip/sensor itself. So is it only accurate enough to roughly calculate which of it's six sides is facing up (like the Xiaomi MiCube, but that does all the calculating for you!) or can the values realistically be used to determine the sensor's resting angle relative to gravity/the floor?

• If the sensor is actively being vibrated/moved, then what is the output of attribute 0x0508? Is it acceleration motion values?

• Does the output of attribute 0x0503 while the sensor is actively being vibrated/moved relate to the acceleration sensor output, or is it a calculation of changes in acceleration sensor output into a number that represents the general level of movement (along some kind of numerical range we haven't yet discovered)?

[oltman]

Thanks, @veeceeoh A few comments on what I did/am doing:

• I did not change the sensitivity from default... not sure if that helps you on figuring out the range I used. Once I build range control into my ST device handler I will be able to assess.

• The datasheet link (ADXL362) is v. helpful, thanks.

• I only get tilt measurements from 0x0508 after all movement is stopped. While this sensor has a higher output rate than that, it looks like we are only going to get one measurement.

• Since I only get tilt measurements once stable, I am assuming I am in a 1g environment when the measurements stabilize. There are a number of ways to convert 3-axis acceleration measurements to tilt. I have chosen to use equations to answer the question of "how far from horizontal are the X,Y,Z axis?" The equations I use are as follows:

  double Angle_X = Math.round(Math.atan(X/Math.sqrt(Z*Z+Y*Y))*180/Math.PI)
  double Angle_Y = Math.round(Math.atan(Y/Math.sqrt(X*X+Z*Z))*180/Math.PI)
  double Angle_Z = Math.round(Math.atan(Z/Math.sqrt(X*X+Y*Y))*180/Math.PI)

  (note that X,Y,Z are the decoded values consistent with my and @veeceeoh 's previous comments. The above is the java code, the equations are: Angle_X = atan(X/sqrt(ZZ+YY))180/Pi) <-- in degrees Angle_Y = atan(Y/sqrt(XX+ZZ))180/Pi) <-- in degrees Angle_Z = atan(Z/sqrt(XX+YY))*180/Pi) <-- in degrees

• Note: The above uses the raw data from the sensor and is not calibrated in any way. In my setup, the resulting calculated angles when set on the six sides all seem to be within 5 degrees of where I think they should be and partial tilts look reasonably accurate. I have thought about calibrating this for offset and gain errors, by taking measurements on the six sides, but have held off on this for now.

• I have also thought about making my device interface accept a 'remember' command that would store the current tilt position and report back whenever the device gets back to within 10 degrees of the stored position. I could see sticking this on my garage door to report open and close states of the door since I don't have a convenient spot for a magnetic sensor.

• @veeceeo I know this is not a ST forum, but wanted to let you know that my DH is using the threeAxis device model. Right now I am storing angles in the model even though the original intent of that model is to store g measurements. I think it would be possible to convert to g within the parser and then compute angle outside prior to display or use.

This has been very helpful forum. I want to thank you all for putting time into this.

[TedTolboom]

My contribution (largely confirmation of above), based on testing to add support for the Aqara Vibration sensor to my Homey app: https://github.com/TedTolboom/com.xiaomi-mi-zigbee

Attribute 0x0055 Value 1: vibration detected Value 2: tilt detected Value 3: drop detected

Attribute 0x0503 Reporting the absolute angle between the previous plan and actual plan (not showing tilt direction and axis). No other reporting purpose (linked to vibration / drop) seen yet.

Attribute 0x0505 Not sure yet... could be RAW gyro data for drop event or vibration data..

Attribute 0x0508 3x 16 bit reporting the force vector (Zout, Yout, Xout), according to the ADXL362 definition.

First 4 hex characters: 2's complement encoded Z axis (+ squigly line side up yields pos values on this, flip to get negative) Second 4 hex characters: 2's complement encoded Y axis (+ button side up yields pos values on this, flip to get negative) Last 4 hex characters: 2's complement encoded X axis (+ right side of device yields pos values, opposite yields negative)

After normalizing of the force vector:

const R = Math.sqrt(Rx * Rx + Ry * Ry + Rz * Rz);

The rotation around the X and Y axis can be determined by

const R = Math.sqrt(Rx * Rx + Ry * Ry + Rz * Rz);
// calculate angles relative to force vector
const Ax = Math.acos(Rx / R) / RAD;
const Ay = Math.acos(Ry / R) / RAD;

Advantage over 0x0503 is that it is possible to show the tilt axis and tilt direction... So it is possible (tested) to show the delta tilt compared to the previous plane / position but also to a reference plane / position. Usage example, roof window opening angle.

[veeceeoh]

Attribute 0x0505 Not sure yet... could be RAW gyro data for drop event or vibration data.

According to the French website, although the sensor's PCB has a spot labelled for a gyro, no gyro device is present.

My guess is that attribute 0x0505 could be the vibration strength report data. Although it does seem to happen after tilt events sometimes, it's not consistent.

Being tagged as uInt32 doesn't mean much, and from everything I've seen only bytes 1-2 are relevant. Examples of output, and possible values:

0x00CA0000 -> 00CA -> 202 0x000E0000 -> 000E -> 14 0x00E50000 -> 00E5 -> 229 0x010C0000 -> 010C -> 268

The ADXL362 has the option of buffered FIFO operation and one of the output registers does provide the number of buffered samples, with a range of 0-512, so attribute 0x0505 could be as simple as that raw data passed on. To test this, the sensor could be put in a constant vibration environment for some minutes and observe if the data values from0x0505 max out at 0200/512.

[paolotremadio]

Good find! What else is missing to fully implement it on deCONZ? (Including the Phoscon UI)

[AndySzr]

It's all here except the 0x0505. just wait until someone finds the time to implement it or start doing it :-)

[TedTolboom]

Attribute 0x0505 Not sure yet... could be RAW gyro data for drop event or vibration data.

According to the French website, although the sensor's PCB has a spot labelled for a gyro, no gyro device is present.

My guess is that attribute 0x0505 could be the vibration strength report data. Although it does seem to happen after tilt events sometimes, it's not consistent.

Being tagged as uInt32 doesn't mean much, and from everything I've seen only bytes 1-2 are relevant. Examples of output, and possible values:

0x00CA0000 -> 00CA -> 202 0x000E0000 -> 000E -> 14 0x00E50000 -> 00E5 -> 229 0x010C0000 -> 010C -> 268

The ADXL362 has the option of buffered FIFO operation and one of the output registers does provide the number of buffered samples, with a range of 0-512, so attribute 0x0505 could be as simple as that raw data passed on. To test this, the sensor could be put in a constant vibration environment for some minutes and observe if the data values from0x0505 max out at 0200/512.

I think your right @veeceeoh.... these first 2 bytes seem to represent the strength of the vibration...

I have been testing to see what the trigger / reporting mechanism is of this attribute. And draw the conclusion that the sensor is reporting this attribute once every 300 seconds after a vibration has been detected...

Below logging of an Aqara vibration sensor through it's driver of the Homey app:

2018-09-19 19:01:24 [log] [ManagerDrivers] [vibration.aq1] [0] onMotionReport_1285 0x580000 88
2018-09-19 19:06:22 [log] [ManagerDrivers] [vibration.aq1] [0] onMotionReport_1285 0x620000 92
2018-09-19 19:11:17 [log] [ManagerDrivers] [vibration.aq1] [0] onMotionReport_1285 0x6F0000 111
2018-09-19 19:16:16 [log] [ManagerDrivers] [vibration.aq1] [0] onMotionReport_1285 0x480000 72

In this experiment I 'triggered' repeatedly and it continuously reported it's value every ~300 seconds. Did a similar experiment with a second sensor connected to the Xiaomi mi hub and noticed similar results.

Adding the sensor to an improvised shaker table (mounted on an electric screwdriver shaking when going through it's torgue limits) did not result in faster reports or higher values.

So 0x0505 would be the maximum vibration strenght measures within 300 seconds after the first trigger.

[veeceeoh]

I think your right @veeceeoh.... these first 2 bytes seem to represent the strength of the vibration...

Thanks @TedTolboom for reporting your findings back here!

I noticed something about your log entries, though:

0x580000 88
0x620000 92
0x6F0000 111
0x480000 72

Those hex values seem to be missing a byte (Attribute 0x0505 includes a 32-bit value). So some of the integer values could possibly be off.

Fortunately, I just received an e-mail that my sensors have been delivered to my home! So I will finally get a chance to do some testing myself very soon, and I will first focus on figuring out what Attribute 0x0505 represents . I will definitely report back here.

[TedTolboom]

@veeceeoh rightly noticed... Homey uses currently the Zigbee Shepherd as core Zigbee driver...

which (in this case unwanted) parses and reports the Uint32 value as integer.. In this case, I manually converted the reported integer to HEX, which does not show the first byte (not relevant since it only contains 0’s).

The actual reported data of the first report:

2018-09-19 19:01:24 [log] [ManagerDrivers] [vibration.aq1] [0] onMotionReport_1285 5767168

I do wonder how you got these high(er) values... I practically had to throw the sensor (by itself) to the table top to get these result..

[veeceeoh]

I do wonder how you got these high(er) values... I practically had to throw the sensor (by itself) to the table top to get these result..

@TedTolboom (and everyone else):

Now that I have two of these sensors, I'm throwing out parts of my theories.

Regarding attribute 0x0505, I still believe it correlates to level of activity in some way, but not providing the raw number of buffered samples output from the ADXL362 accelerometer chip as I guessed before. Here are the values I saw on one of the sensors over a period of 12 hours:

Example attribute 0x0505values observed

Time	Hex value	Int	Notes on prior activity
19:42:25	00d1 0000	209	after a good number of vibration & tilt events
19:56:15	0047 0000	71	after 3 vibration, 3 tilt, & 1 drop events
20:05:38	0006 0000	6	after no events (stationary)
20:11:46	002b 0000	43	after 1 vibration & 2 tilt events
20:26:19	001b 0000	27	after 1 vibration event
20:33:58	0029 0000	41	after 1 vibration & 2 tilt events
20:39:46	0061 0000	97	after 2 vibration, 3 tilt, & 3 drop events
20:46:47	0041 0000	65	after 2 vibration events
20:55:22	004e 0000	78	after 3 vibration, 1 tilt, & 2 drop events
21:05:14	0003 0000	3	after no events (stationary)
21:28:22	0010 0000	16	after 1 vibration event
21:40:43	0009 0000	9	after no events (stationary)
22:21:48	004c 0000	76	after 2 vibration, 7 tilt, & 1 drop events
22:30:58	0036 0000	54	after no events (stationary)
22:48:27	006f 0000	111	after 3 vibration & 6 tilt events
22:49:26	00ca 0000	202	after 3 tilt events
22:55:19	00d2 0000	210	after 4 vibration & 6 tilt events
23:00:17	00ff 0000	255	after 3 vibration, 24 tilt, & 1 drop events
23:05:16	0107 0000	263	after 4 vibration & 24 tilt events
23:10:14	00b4 0000	180	after 2 vibration & 10 tilt events
23:20:29	007e 0000	126	after 4 vibration events
23:28:23	000c 0000	12	after no events (stationary)
03:23:46	0015 0000	21	after 1 vibration & 1 tilt event
03:28:47	000a 0000	10	after no events (stationary)
04:02:05	000c 0000	12	after 1 tilt event
04:52:47	0001 0000	1	after no events (stationary)
05:00:31	000b 0000	11	after 1 tilt event
05:27:44	0001 0000	1	after 1 tilt event
05:45:00	000a 0000	10	after 1 tilt event
05:50:00	000d 0000	13	after no events (stationary)
06:07:19	0056 0000	86	after 2 vibration & 2 tilt events
06:15:02	0049 0000	73	after 1 tilt event
07:28:00	000f 0000	15	after no events (stationary)
07:32:58	0055 0000	85	after 3 vibration & 8 tilt events
07:43:27	006f 0000	111	after 2 vibration & 7 tilt events

Some observations about the 0x0505 reports / values:

• The time intervals between reports are inconsistent, but the most frequent intervals I see are about 5 minutes apart.
• The lowest value I've seen is 1 (0001) and highest is 265 (0107). @TedTolboom - this may show that the 1st byte is relevant, but it seems rare that value reach above 255(00ff).
• There seems to be some correlation between the number of vibration, tilt, and drop events and the value reported from attribute 0x0505, but I think it's not solely related to those events, especially since some events seems to prevent others from being reported when moving the sensor around a lot.
• It doesn't seem so well suited to use for sleep movement detection, unless the sensitivity level has some effect, just based on leaving it under my pillow while sleeping and observing long periods without any reported values.

I have also been looking at the Accelerometer XYZ values given by attribute 0x0508. I can't confirm that the SmartThings device handler code is properly setting the sensitivity level, but it appears that the values may be normalized and unaffected by the sensitivity level setting. Also, I believe that the values reported are interpolated from the raw 12-bit two's complement values output from the ADXL362 chip, because the range doesn't extend out as far as the -2048 to 2047 range given in the chip's documentation. The other thing I have noticed is that the range output from my two sensors is not evenly balanced on either side of the zero value.

Here's a chart of some sampled values given by my two sensors in the 6 resting positions that should show the complete possible range of each of the XYZ axis values, along with the angle change value reported by attribute 0x055:

Resting position	Sensor 1: X,Y,Z	Sensor 2: X,Y,Z	S1 0x0055 Angle	S2 0x0055 Angle
Front side up	19,-30,1194	25,-2,1175	N/A	N/A
Battery side up	30,-20,-709	42,24,-783	175°	176°
Reset button up	-19,981,177	-27,1043,150	102°	97°
Reset button right	-912,-48,181	-922,-27,133	90°	89°
Reset button down	91,-1048,194	103,-1037,137	90°	89°
Reset button left	969,-18,189	989,32,145	82°	85°

For some reason, the Z-axis seems to have an "imbalanced" range from the -700s to around 1200 at the other end, while the other two axes have a more balanced range going from around -1000 to 1000. Given these non-symetrical ranges, it seems it would be challenging to compute exact angles. But computing rough angles (with some tolerances for the variations in reported values) to assign to open and close positions shouldn't be a problem.

[oltman]

Great work there @veeceeoh . Regarding the offset/imbalance-- I have two of these sensors and the balance between positive and negative (opposite sides up) on certain axis is quite different between them. So I can confirm your imbalances.

I went back and read the ADXL362 datasheet and I think the imbalances can be traced to the maximum offset of the part. Those parts can have a ±150mg offset on X,Y axis and ±250mg offset on Z axis. For the 2g sensor range, this would map to 153 and 256 LSBs respectively. The typical offset is stated as ±35mg and ±50mg for X,Y and Z axis which is 35 and 50 LSBs respectively.

I thought about full calibration (both gain and offset), but punted on this when I realized my use case was to detect when something came back to (approximately) a familiar/previously used position which I could assign as open/closed.

[AndySzr]

is anybody working on the implementation of this sensor?

[paolotremadio]

I guess the only bit missing is the support on the UI. Am I wrong? I’ve been using it for two weeks without any issues (by using deconz together with my branch for homebridge-hue)

[AndySzr]

The two way communication to adjust the sensitivity of the sensor is implemented as well?

[paolotremadio]

No, that is still missing.

[ebaauw]

Mine got delivered today. I'll have a look next weekend what I can do to support config.sensitivity. As it's a battery-powered device, we'll have to use config.pending as for the Hue motion sensor.

Frankly, I have no idea how to expose the values from 0x0505 and 0x0508 through the REST API.

[JBS5]

It is neccessery to upgrade the raspbee firmware as well after upgrading the HASS.io Deconz addon to support the Aqara vibration sensor? After pairing, the sensor blinks a few times but is not added to the list of devices in the Phoscon app.

\Edit: After repairing again, events of the sensor are shown in the HASS log now.

[jtitley]

I have it connected to Xiaomi Gateway and using a Xiaomi automation to flip a zigbee switch on and off. This makes a good proxy sensor until it is fully supported. On high sensitivity it works well to detect my garage door open.

[ebaauw]

From this webpage by the creator of ZiGate, the sensitivity level is set with a write command as follows

Cluster: 0x0000, Attr: 0xFF0D, DataType: 0x20 (8bit Integer), Data: • 0x01 = High sensitivity level • 0x0B = Medium sensitivity level • 0x15 = Low sensitivity level

Please note that data type 0x20 is an unsigned 8-bit integer. Also, according to the mentioned site, it is a manufacturer-specific attribute, with Manufacturer Code 0x11f5.

I'll have a look next weekend what I can do to support config.sensitivity.

I cannot test writing this manufacturer-specific attribute through the deCONZ GUI. The sensor itself advertises Manufacturer Code 0x1037 in the Node Descriptor. The GUI won't even show the attribute, since the code from the device doesn't match the code from the attribute.

Can some-one please confirm having been able to set the sensitivity using something different than the Xiaomi gateway?

[corneyl]

Maybe this helps? https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/converters/toZigbee.js#L142

[almirdelkic]

I am running deCONZ Docker Image by marthoc v2.05.47 which is working great. Couple days ago I got two of these Vibration sensors and have some unexpected results when adding them. They show up as "ZHASwitch". I was expecting to see "ZHAVibration" type. Do you have any idea why this is happening?

"11": {
    "config": {
        "battery": 100,
        "on": true,
        "reachable": true,
        "temperature": 3400
    },
    "ep": 1,
    "etag": "a8f2d08c7d1a80931b6e2a16871444e0",
    "manufacturername": "LUMI",
    "mode": 1, 
    "modelid": "lumi.vibration.aq1",
    "name": "Vibration 2",
    "state": {
        "buttonevent": 1009,
        "lastupdated": "2018-11-18T20:02:55"
    },
    "type": "ZHASwitch",
    "uniqueid": "00:15:8d:00:02:a5:1b:c5-01-0101"
}

[corneyl]

I think because it acts as a switch, sending out buttonevents based on the type of vibration. Works quite well btw, I already use it in my home automation system.

[almirdelkic]

Well... they are not showing up in the latest HA v0.82.1 (but that can be a HA issue). Still I was expecting to see them as ZHAVibration because of this dresden-elektronik/deconz-rest-plugin#755. Or did I misunderstand?

[Kane610]

@almirdelkic since they are ZHASwitch they will only be exposed as events in Home assistant

[almirdelkic]

@corneyl & @Kane610, thank you for your replies! Now I can use them in HA. Already started testing and it looks promising :-) Still it doesn't answer why they are not showing as ZHAVibration since @ebaauw's branch was merged and released some time ago. Unless I am mistaken?

[Kane610]

There is a comment in one thread on this github about the reasoning behind it. It has something to do with it being momentary information

[TheNico14]

Is there any news about the sensitivity settings? I'm using a sensor on my desk chair to make the light stay on when I'm still and the PIR doesn't see me, but it needs a lot of motion to trigger. Maybe is there even a non-GUI way that I could use to edit the sensitivity? Thanks

[superwerder]

I would like to hear news on this as well. It seems the sensitivity is quite low. Or what is the default level?

[manup]

Playing around with my shiny new Aqara Vibration Sensor I've also noticed that it is created as ZHASwitch resource as mentioned above.

@ebaauw Works for me, but some questions arise: 1) There is code for creating a ZHAVibration sensor based on the prior IAS assumption, can this be removed or is it used otherwise? Basically I like the idea of having a ZHAVibration :)

2) The Wiki also refers to state.vibration which doesn't match latest code, I'll create a new Wiki page for this sensor which describes the button events.

3) As for the sensitivity I've managed to read/write this attribute after hacking the database node descriptor manufacturer id to 0x115f and correcting the mfcode in general.xml (0x11f5 vs. 0x115f).

I could write successfully 0x01 for high sensitivity, not sure if it really makes a big difference. Anyway we can provide this parameter as config.sensitivity and use the pendig attribute to write it as soon as the next hourly report is received or the button is pressed, since this is the only time the sensor accepts incoming commands. I'll put some code up for doing this.

[ebaauw]

There is code for creating a ZHAVibration sensor based on the prior IAS assumption, can this be removed or is it used otherwise?

It's not used at the moment, afaik. The mapping to ZHASwitch is from before understanding how to interpret the 0x0503 and 0x0508 attributes. To expose those attributes, we would want to go back to ZHAVibration.

Basically I like the idea of having a ZHAVibration :)

Same here, that's why I left it in.

correcting the mfcode in general.xml (0x11f5 vs. 0x115f).

My bad.

[Kane610]

If you plan to completely change this. Please inform in good time so it is possible to prepare ntegrations prior to this in order to avoid breaking behavior for users

[paolotremadio]

@manup can you please send me the general.xml file with the line for setting the sensitivity?

[manup]

@manup can you please send me the general.xml file with the line for setting the sensitivity?

It's part of deCONZ 2.05.50, but it doesn't work without hacking the database since the node descriptor has the wrong manufacturer code.

[maxandersen]

Catching up on this after just getting 3 of these devices. Do I grok it right that for now even the latest beta just reports movement it won't send x,y,z coordinates or similar to detect its position ? (I was hoping to use one to detect if garage door is open or not).

Any plans on adding that ?

[maxandersen]

2. I'll create a new Wiki page for this sensor which describes the button events.

I tried to find this page but didn't - got a link ?

[cristimi]

I have installed the sensors on my garage port trying to use them to track open/close status but I get inconsistent results with them. I am also interested in being able to have some more data (e.g. tilt angle).

[prnzngr]

I am also waiting for more data (angle, drop, tilt, ...)

[WhistleMaster]

Is it now possible to adjust the sensitivity of those ?

[MornLum]

Hallo, any news about adjusting the sensitivity?