Not in HomeyKit, but perhaps in the Home app on iOS (although you don’t have much of a choice there either: switch, light or fan).
Does this App support Aqara vibration sensors?
I don’t see mine in the App (I use it without Aqara hub; Homey does the job).
What about Aqara door sensors? (I’m considering buying a few)
I don’t know what capabilities the vibration sensor uses. HomeyKit supports the following capabilities for sensors: measure_luminance, measure_temperature, measure_humidity, measure_pressure, alarm_motion, alarm_water, alarm_contact, alarm_smoke, alarm_co, alarm_co2.
Looks like the vibration sensor uses these:
- measure_vibration
- measure_tilt
- measure_tilt.relative
- measure_battery
and
- alarm_vibration_true
- alarm_vibration_false
- alarm_tilt_true
- alarm_tilt_false
- alarm_drop_true
- alarm_drop_false
- alarm_battery
So unfortunately not supported?
No. Apart from alarm_battery, those are all custom capabilities (specific to the Xiaomi&Aqara app) anyway.
Thank you. I guess I’m out of luck with the door sensor too?
Besides measure_battery and alarm_battery the only other capability seems to be alarm_contact, which is not in your list either.
So I would need to buy an Aqara hub (instead of my Homey) if I want to use these sensors in HomeKit?
(I suppose Homebridge on a Pi won’t be an option either)
Yes it is 
You could work around it using virtual devices: create a virtual device per sensor where the virtual device has a capability that HomeyKit supports, and change the value of that capability from a flow triggered by the actual sensor.
2 Likes
I’m such a bad reader… This is good news!
I was just about to ask whether that would be a viable route…
Thank you for this suggestion!
Received several Aqara door sensors yesterday and used HomeyKit to add them to HomeKit.
(First impression:) Works like a charm!
Thank you for creating this App!
1 Like
Hello all,
I have added a few new Aqara Doorcontact sensors to my DECONZ setup. They are responding correctly (and perfect) in the Phoscon webpage and in Homey (various flows).
But in Apple HomeKit, via Homeykit, they are detected as a general device and not as a doorcontact. See attached image.
My older Aqara Doorcontact sensors are working correctly.
The Aqara doorcontact sensors have exactly the same version (20161128).
Does anybody know how this can be solved?
I updated my Homey this morning to 7.3 and update DECONZ to the beta version 2.15.01 / 16-3-2022 (this problem also occured in all stable version previously). The firmware from my DECONZ2 dongle is the most recent (26720700).
Also tried to toggle them (Add / Remove) them from HomeyKit.
The only thing I did not try to do is reset Homeyit to default because of the fact that I need to set all devices again in HomeKit. Maybe someone knows the solution before performing this action.
Thanks!
HomeyKit looks at the device’s capabilities and device class to determine what type of device it should present to iOS, so there seems to be a difference between this device and the others.
You can find out the class and capabilities for a device on this page: https://tools.developer.homey.app/tools/devices
Let me know which ones are shown for the “broken” device and which one for the working device(s) so I can hopefully determine what the reason is for this issue.
Hi Robert!
Thanks for the response!
This is one which is working:
|Property|Value|
| — | — | — | — | — | — |
|ID|------|
|Name|Sensor Achterdeur|
|Class|sensor|
|Driver|homey:app:de.dresden-elektronik.deconz — aqara-magnet|
|Ready|Yes|
|Available|Yes|
|Warning|No|
|Custom icon|No|
Settings
|Key|Value|
| — | — | — | — | — | — |
|id|[“2”]|
|invert_alarm|false|
|ignore-reachable|false|
|modelid|“lumi.sensor_magnet.aq2”|
|manufacturername|“LUMI”|
|swversion|“20161128”|
Capabilities
| ID | Title | Type | Value | Set Value | Last Changed |
|---|---|---|---|---|---|
| alarm_contact | Contact alarm | boolean | false | 15 minutes ago | |
| measure_battery | Accuniveau | number | 95 | 15 minutes ago |
The next one is not working:
| Property | Value |
|---|---|
| ID | ------ |
| Name | Sensor Buitendeur Tuin |
| Class | homealarm |
| Driver | homey:app:de.dresden-elektronik.deconz — aqara-magnet |
| Ready | Yes |
| Available | Yes |
| Warning | No |
| Custom icon | No |
Data
| Key | Value |
|---|---|
| id | ------ |
Settings
| Key | Value |
|---|---|
| id | [“38”] |
| invert_alarm | false |
| ignore-reachable | false |
| modelid | “lumi.sensor_magnet.aq2” |
| manufacturername | “LUMI” |
| swversion | “20161128” |
| ids | “["38"]” |
| mac | “------” |
Capabilities
| ID | Title | Type | Value | Set Value | Last Changed |
|---|---|---|---|---|---|
| alarm_contact | Contact alarm | boolean | false | 25 minutes ago | |
| measure_battery | Accuniveau | number | 100 | 25 minutes ago |
I already can see the the class type is different (sensor and homealarm).
Looking forward to your response. Thanks!
Regards, Dion
Yes, and that’s exactly the issue: the alarm_motion capability is only supported for sensor devices, not for homealarm devices. It doesn’t really make sense to use the latter device class, because that’s meant for home alarm controller devices, not for sensors that might be used to trigger an alarm but have lots of other applications too.
Thanks for the explanation @robertklep.
Is there an option to change this? If Yes, where can this be changed?
And ofcourse, if not… we have to deal with it.
It has to be changed in the app.
I don’t know why the deCONZ app is using two different device classes (but perhaps it was changed from “sensor” to “homealarm” between versions of the app and any existing devices that already used “sensor” were left unchanged).
In the HomeyKit app or deCONZ app?
In my opinion in the deCONZ app. Like I said, using the “homealarm” class for this type of device doesn’t seem correct.
Check! I will ask in the deCONZ thread if there is an option to change this. Thanks!
It is the deCONZ app I think
1 Like
