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

[jo-me]

Cool, could be interesting for the classic washing machine use case..
Simpler as this:
https://community.home-assistant.io/t/laundry-sensors-with-nodemcu-and-home-assistant/42533

[sumo-89]

I've just ordered 3 of these, I also hope they will be supported in Deconz soon. :)

[ebaauw]

I would expect these to be IAS devices, just as the Xiaomi leak sensor. In that case, adding support should be straightforward. Please post the usual deCONZ GUI screenshots:

• Node, endpoints, and clusters;
• Node info panel;
• Cluster info panel for the Basic cluster after reading the attributes (press the button to wake the sensor while reading);
• Cluster info panel for the IAS Zone cluster (assuming the sensor has one), again after reading the attributes.

Please also try to capture the Xiaomi special packet for this device from the dCONZ log.

[paolotremadio]

I've got mine today. It's my first time on deCONZ so please help me out getting the details 😊

Device:

Node info:

Cluster info (0000 Basic)

Cluster info (0101 Door lock)

Also, some pics of the device:

[ebaauw]

Door lock cluster ?! That doesn't make any sense to me, even for Xiaomi. Do any of the Door lock attributes change when the sensor detects vibration?

I wonder if deCONZ read it correctly. Could you please reset the device (hold the reset button/hole for 10 seconds), remove it from deCONZ, power down all your lights (ZigBee routers), move it close to the RaspBee/ConBee and re-pair it, while shaking it (to keep it awake)?

The leak sensor doesn't show an IAS Zone cluster either. I've copied the logic of that sensor to create a ZHAVibration sensor resource for the lumi.vibration.aq1, assuming a similar of Xiaomi magic packet.

[paolotremadio]

I can confirm. I've paired a brand new one, by standing next to the Conbee USB device. I have no lights on this network (totally separate from the Hue network I have, even the channel is different). The new device is still a door lock... how can I test your changes? Do I have to pull your branch and build?

[ebaauw]

I can confirm.

Thanks. I've seem some other strange, non-functional clusters reported by Xiaomi devices. Do you see any changes in the Door lock attributes when the sensor detects vibration?

Do I have to pull your branch and build?

Yes. Or wait for @manup to publish the next release. I see he just merged the open PRs.

[paolotremadio]

I'm tilting and shaking the sensor as the vibration detection might not be accurate (see https://community.home-assistant.io/t/new-aqara-vibration-shock-sensor/63211/8). The lock is in "not fully locked" and it does not change if I keep moving the sensor. Also, no changes in any of the other params.

[manup]

Latest PRs are now available in 2.05.37, however please make a backup and read the changelog before updating, the release has some larger changes under the hood, hopefully nothing will break.

https://github.com/dresden-elektronik/deconz-rest-plugin/releases

[paolotremadio]

Also, check this for reference too: Koenkk/zigbee2mqtt#295

[paolotremadio]

I've deleted two comments. After upgrading the firmware too and deleting and repairing (several times), here's where i've got:

I shake the sensor, the dot next to the sensor in the map on the GUI flashes blue but no changes in value. When I shake it I can see:

When I stop shaking I see:

[manup]

Interesting, you may also try command line parameters --dbg-zcl=2 --dbg-aps=2 to get more details when receiving data.

[paolotremadio]

deconz.log

I've added some empty line before and after shaking the sensors (shaked first one sensor, added more empty lines, than the second one)

[ebaauw]

That means it does send attribute reports for the Door lock cluster (0x01). Currently deCONZ uses this cluster only for /lights resources (the door lock is exposed as a light), but it can be added to the /sensors logic as well.

According to the zigbee2mqtt thread, the sensor issues reports for attributes "85" (0x0055), "1283" (0x0503), and "1288" (0x0508) - that matches pl[0] of 55 and 8. I have no clue as to what these attributes mean, they're not defined for the Door lock cluster, but 0x0055 is Present value for many of the input and output clusters.
The Basic cluster report with pl[0] of 5 and 1 matches attributes 0x0005 (Model Identifier) and 0xff01 (Xiaomi special).
The Xiaomi special package also contains a lot of info. If I were a betting man, I'd place my money on tags 98, 99, and 9A. According to the gearbest page, the sensor detects vibration, tilt, and fall, so I'd expect different values for these three.

[paolotremadio]

@ebaauw here's the log after compiling and running your master branch (including f68d511):

new.log

I've tilted the sensor first, then pressed the button to capture the special packet

[ebaauw]

That doesn't look good - too many unsupported tag messages. I haven't actually compiled and tested the commit myself yet, still upgrading to v2.05.37 and new firmware.

The asdu message gives the raw package payload. Dissecting the magic package:

                                            1                       2                       3                      4
                     1 2  3 4  5 6  7  8 9  0 1  2 3  4 5  6 7  8 9 0 1 2  3 4  5 6  7 8  9 0  1 2  3 4  5 6  7 8  9 0  1 2 3 4 5 6
         attr tp  l   battery    temp         ?   RSSI dB             LQI         ?         ?         ?         ?                 ?
         ---- -- -- --------- ------- --------- --------- --------------- --------- --------- --------- --------- -----------------
         01ff 42 2e 0121 030c 0328 1f 0421 a813 0521 3b00 0624 0000000000 0821 0803 0a21 0000 9821 2800 9921 7400 9a25 8000fffbb300
vibration:       46    3.075V    31°C  u16       u16       u40              u16      u16       u16       u16       u48

[ebaauw]

Ah there was an if in the original code which should have been an else if.

[paolotremadio]

new2.log
Pulled the new commit, recompiled, updated firmware

[ebaauw]

I'll add the tag 0x0A. Next step is to figure out how these values change for the various actions: tilt, shake/vibrate, and drop.

Looking at the reports for the Door lock cluster, it reports attributes 0x0055 and 0x0503, both u16. I'll add them to general.xml, so you should be able to monitor them in the deCONZ GUI. You need to copy this file to /usr/share/deCONZ/zcl (or create a symlink to where you download the git repository). I'm guessing the 0x0508 attribute is u48, just like the 9A tag. They showed it as two numbers in zigbee2mqtt, I'm guessing u16 and u32 to make up u48. Would be nice if you manage to capture the asdu for that as well.

[paolotremadio]

I think i've cracked the meaning of 0x0055:
Value "1": shake
Value "2": tilt
Value "3": drop

The value 0x0503 seems to be a number between 1 and 100 (but at some point I saw a value like 108, 169, 200 and 230). It doesn't seem to represent an angle. Might be the strength/intensity of the motion.

The value of 0x0508 is usually quite a long number (sometimes 20 digits like 18446744073707061293 or 18446744073708372031 but also 1507201 and 65339396).

The 0x0503 and 0x0508 might stay to the same value, even if the value of the 0x0055 changes.

[ebaauw]

I think i've cracked the meaning of 0x0055

Cool! I couldn’t have been more wrong assuming it would be an IAS zone device. Maybe best to expose the sensor as a switch, re-using the buttonevent values for shake, flip, and drop, from the cube.

Did you get the values from the deCONZ GUI or from the log? If from the log, could you post the asdu for the 0x0508?

20 digits is too long for a u48, more like a u64. In hex, the values are 0xFFFFFFFFFFDA002D and 0xFFFFFFFFFFEE003F.

[paolotremadio]

Cool! I couldn’t have been more wrong assuming it would be an IAS zone device. Maybe best to expose the sensor as a switch, re-using the buttonevent values for shake, flip, and drop, from the cube.

I think that is a good idea

Did you get the values from the deCONZ GUI or from the log? If from the log, could you post the asdu for the 0x0508?

From the UI. Is there a way to run deCONZ to log the output only of a single device? I usually get a stream of events and it's quite difficult to isolate the ones relating to the vibration sensor.

20 digits is too long for a u48, more like a u64. In hex, the values are 0xFFFFFFFFFFDA002D and 0xFFFFFFFFFFEE003F.

I'm really curious to find out what that number means :)

[ebaauw]

Is there a way to run deCONZ to log the output only of a single device?

Not really. I usually just grep -i for the mac address, but that doesn’t match the asdu nor Xiaomi special messages. It does provide the time of the preceding message, so I use that to search the log in an editor.

[paolotremadio]

Ok, will dump a larger set of logs on Wed once I'm back home.

[ebaauw]

@paolotremadio, my latest commit (ebaauw/deconz-rest-plugin@bca9cf2) should support the lumi.vibration.aq1 as ZHASwitch sensor. The values for state.buttonevent are:

• 1007 - shake (cf. lumi.cube's 7007 for shake);
• 1008 - drop (cf. lumi.cube's 7008 for drop);
• 1009 - tilt (new).

@manup, I kept the code for ZHAVibration and CLIPVibration, even though currently we don't support any IAS_Zone vibration sensors. I suppose it won't do any harm and it might come in handy later.

[paolotremadio]

I've been digging into GitHub and I've found this comment:

Danielhiversen/PyXiaomiGateway#86 (comment)

Also, here's a detail of the clusters (translated from French): https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Ffaire-ca-soi-meme.fr%2Fdomotique%2F2018%2F09%2F03%2Ftest-xiaomi-aqara-vibration-sensor%2F%23Compatibilite_ZiGate&edit-text=&act=url

To recap

0x0055 is clear:
Value "1": shake / vibrate
Value "2": tilt
Value "3": drop / free fall

0x0503 should be the bed activity:

bed_activity: this reports a number. It seems to be related to vibration. It might correspond to how much movement was seen during the last reporting period. When sitting on my clothes dryer while it was running, it reported the same number for many reports which seem to come about one minute apart. The numbers reported from 72 to 214. Often the same number would report for multiple minutes. A 0 is never reported.

0x0508 is still a mystery. According to the french article:

This frame makes it possible to avoid flooding of actions. As long as this frame is not started, you can not start any other actions.

but according to the GitHub comment:

coordination: this is three numbers separated by commas. It is reported without any regularity. When in the same spot on my running dryer, it reported different sets of numbers that were fairly close to one another: "51,-24,1207" and "47,-31,1233". When I then walked it to another room and placed it on my desk it reported "-935,40,220", but also, at another time, while near my desk, "5,46,1233"

Implementation

The device continues to report "vibrate" every minute or so when it is on a vibrating surface. However, there is no report when it stops vibrating. There is not a "no_motion" report like we see with the PIR sensors. This means that reporting when vibration stops will require a timer of slightly over 1 minute, most likely implemented in the sensor/xiaomi_aqara Entity code.

Shall we go ahead and implement it as a switch with buttonevent? The problem will be: the sensor doesn't report any "no action" so we have to start a timer and stop the "button pressed" after 1 minute or so (unless more changes have been sent over ZigBee). Would be nice to surface the other data in the rest API.. but not a deal breaker

Screenshot from app

[manup]

@manup, I kept the code for ZHAVibration and CLIPVibration, even though currently we don't support any IAS_Zone vibration sensors. I suppose it won't do any harm and it might come in handy later.

Yes I guess sooner or later more these sensors will be available, so It's wise to keep the code :)

[ebaauw]

Shall we go ahead and implement it as a switch with buttonevent? The problem will be: the sensor doesn't report any "no action" so we have to start a timer and stop the "button pressed" after 1 minute or so (unless more changes have been sent over ZigBee).

That's precisely why I think it should be supported as a switch, rather than a sensor. Switches don't report that the button is pressed. Switches report events (button was pressed, button was released). Sensors, on the other hand, report a current state (door is open, door is closed, temperature is 21°C). Sensors are stateful, switches are stateless. You can query a sensor for its current state; you cannot query a switch for its current event.
Granted, this is a subtle difference, as a new state value (door is now open) is very similar to a state change event (door was opened).

My point is that the vibration sensor sends events. For tilt and drop (sensor was tilted, sensor was dropped), this is very intuitive - you don't expect a state (sensor is falling), since the drop only takes a brief moment. For vibration (sensor was shaken) it is maybe less intuitive, as vibration sounds more like a state (sensor is vibrating), which lasts longer.

Incidentally, we have the same confusion with motion sensors, which basically issue an event (motion was detected), but are implemented as ZHAPresence, suggesting a state (some-one is present). Only some motion sensors actually report that motion is no longer detected. For the others, deCONZ provides a timer, config.duration, to reset state.presence. Then of course, "motion is no longer detected" is something entirely different than "no-one is present".

I don't think we can technically expose the vibration sensor as two different resources for tilt/drop (ZHASwitch) vs vibration (ZHAVibration).

[paolotremadio]

Sounds good to me, I will test it tomorrow.

Just one question: let's say I have the vibration sensor connected to deCONZ and I connect deCONZ to homebridge-hue. Homebridge-hue will expose the switch. We also know that the vibration sensor reports motion from time to time (let's say every 30 seconds).

With that setup, I shake the aqara sensor, the switch gets the event and I can connect an automation in Homekit. If I keep shaking the aqara sensor, will it trigger a new automation after 30 seconds, when deCONZ gets the status update from the sensor?

[ebaauw]

Yes.

[imbaimbaimba]

It does not seem to be an issue with latency or timing. It just seems like it disregards smaller movements, whereas when connected to a Homey, it would register every little angular change.

[Kane610]

In that case it might be something deCONZ does.

[imbaimbaimba]

I think so.

My guess would be that there is some sort of threshold for how much the sensor needs to be affected(sensitivity?), for it to send an updated value. Maybe to save battery in some use cases, it would make sense to disregarding little movements. I think the problem then is that it knows some sort of zero position in space, and then reacts by delta angles when moved. So if it disregards angles smaller than a set value, you can do a series of small movements and you will not see an update even though it has moved(Rotated in planes) considerably.

Anyway, I got no idea how zigbee or programming works, so my guesses are just based off my mechanical knowledge - it could be an entirely other problem.

Hopefully one of the coders can chip in on this?

[Kane610]

Pinging @manup, mind to chip in here

[Smanar]

@imbaimbaimba have you tried different value of sensitivity ?

[imbaimbaimba]

I have not. Unfortunately I am not all that good at figuring stuff like that out. So I honestly don’t know if that would solve it.

[Smanar]

Not so hard, you can just with curl:
curl -H 'Content-Type: application/json' -X PUT -d '{"sensitivity": 21}' http://PHOSCON_IP/api/API_KEY/sensors/SENSOR_ID/config

1 is the more sensible, 21 the less.

I haven't tried for rotation, so IDK if the setting work for it too, make a try.

[imbaimbaimba]

I tried, but could not figure out how to make it work :( I also noticed that the humidity sensors have the same issues. They respond promptly to radical changes, say if I open a window or breath on them, but If they slowly change, it is not reported.
So I have one in our bathroom that turns up the ventilation when humidity goes above 75%. It always turn it up, but rarely turns it back down when humidity falls. This is, as far as I conclude, because it changes slowly gradually.

[flopp999]

I just bought a DJT11LM firmware 20180130
I am using Debian 10, ConBee 2.
I have add it to Phoscon but I only get Battery and Temperature. It is registered as Xaiomi Vibration Sensor.
Phoscon version 2.05.69
Firmware 26490700
I was expecting angle value but I don’t see that in Phoscon.

I am using Domoticz to receive the data from deCONZ and there I see vibration value, On/Off.

Can I expect angle as well in Domoticz/Phoscon or it is not possible at he moment?

[dodopigeonfighter]

I just bought a DJT11LM firmware 20180130
I am using Debian 10, ConBee 2.
I have add it to Phoscon but I only get Battery and Temperature. It is registered as Xaiomi Vibration Sensor.
Phoscon version 2.05.69
Firmware 26490700
I was expecting angle value but I don’t see that in Phoscon.

I am using Domoticz to receive the data from deCONZ and there I see vibration value, On/Off.

Can I expect angle as well in Domoticz/Phoscon or it is not possible at he moment?

Same here, conbee 1 though.

[oncleben31]

Is there a reason to not have the type of mouvement (touch, tilt or drop) in the API ?

[mf-1]

I'm primary looking for x/y/z axis support. Because of needed I sent the stick back. Maybe later it's possible, then I buy a new one.

[Mimiix]

It seems this issue is resolved. If it is not, please re-open!

[Ruugy]

I thing the Problem is still there.

I have the Vibration Sensor DJT11LM and in the Poscon App I only get Battery and Temperature.

is there a solution?

[volschin]

Thias github is for the rest plugin not for the Phoscon GUI, not being open source. The rest plugin works fine, the Phoscon GUI does not show all data.

[Ruugy]

Ok, thank you.

So i can't use it with FHEM?
Or is there a solution?

[volschin]

You can use it with FHEM. FHEM uses the rest plugin and I have all needed readings in fhem like

• orientation
• tiltangle
• vibration
• vibrationstrength

[Ruugy]

That sounds good.

Could you briefly explain to me how to set this up?
I have to use userReadings as Attributes?

Sorry, but i don't know my way around.

[Mimiix]

Phoscon is closed source. I will forward this to their dev, she will move this issue to the Phoscon repo.

[Ruugy]

Thank you to inform their dev to solve this problem. I would prefer this solution, because i dont know about this and so it is easier for me.

Perhaps i can solve it with the rest plugin in the meantime?
But i dont find something how it works, even though in the meantime.

[Ruugy]

@Mimiix
Or do you mean i should ask my question ther again?

[Mimiix]

No, she will move this issue to that repository ;) I added the label, that will inform her.

[YKO-de]

It could be that the sensor has not yet delivered all attributes. I didn't see any vibration just after I learned it. A little shaken. Now it works.

[damajor]

I have some issues to use this sensor on my system (rpi3+raspbee2) with latest firmware.

After some time it appears like this:

On the webgui:

Node info:

Cluster info "Basic"

Cluster info "Identity"

Cluster info "Door Lock"

In the log I can see some "tilt", "shake" & "drop" events:

APS-DATA.indication srcAddr: 0xc9b7, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -46
   asdu: 181a0a5500210100
[INFO] - Button 1007 Shake
ZCL attribute report 0x00158D00032CB168 for cluster: 0x0101, ep: 0x01, frame control: 0x18, mfcode: 0x0000
APS-DATA.indication srcAddr: 0xc9b7, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -46
   asdu: 181b0a5500210300
[INFO] - Button 1008 Drop
ZCL attribute report 0x00158D00032CB168 for cluster: 0x0101, ep: 0x01, frame control: 0x18, mfcode: 0x0000
skip binding for attribute reporting of ep: 0x00 cluster 0x1000 (end-device might sleep)
skip binding for attribute reporting of ep: 0x00 cluster 0x1000 (end-device might sleep)
APS-DATA.indication srcAddr: 0xc9b7, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -40
   asdu: 181c0a0805251a00f5ffaf04
[INFO] - No button handler for: lumi.vibration.aq1 endpoint: 0x01 cluster: DOOR_LOCK (0x0101) command: 0x0A payload[0]: 008
ZCL attribute report 0x00158D00032CB168 for cluster: 0x0101, ep: 0x01, frame control: 0x18, mfcode: 0x0000

Any help to get it working ?

[Mimiix]

Yep, broken since 86. Fix is already merged. Waiting on new release.
dresden-elektronik/deconz-rest-plugin#3455

[damajor]

I just figured it out :) Thank you.