Considering the fact most info was incorrect on these sensors, I returned them. No use for data we can not rely on, and devices pretending to be offering data, while in fact they are mostly inaccurate have no place in a serious home controlling setup imho. I fear the Aqara line of ‘cheap little gems’ won’t do…
They do for me
Regarding the vibration sensor: when I was setting it up it seemed to work okay, I could see the tilt angles change to reasonable values when I flipped/switched the sensor. But in the end, the state value (which, afaik, means “vibration detected”) worked just fine. I did play a bit with the sensitivity setting of the sensor.
I need a little help, I am a noob in soldering, and I might ruined my aqara motion. (i know its not expensive, but I wanna learn what mistake I made.) I did connect the pins as it discribed, but now the button is dead. If I remove the battery and add it again, it flashes 3 times, than dead again.
Thanks for any help in advance
That’s seems ok, doesn’t register it motion in deconz?
I does not connect at all.
I had those in ZHA, too.
I found out that it is not enough to change the state of the entity in HA.
Instead I had to change the state of the ZHA device itself via a ZHA service call!
After that, all ghost switching were gone…
btw. I changed the timeout to 4 seconds, so that a motion detection after exactly 5 seconds is not missed (had that sometimes before…).
You could use the automatisation above:
alias: Aqara motion sensor - reset ZHA cluster description: '' trigger: - entity_id: binary_sensor.lumi_lumi_sensor_motion_aq2_ias_zone platform: state from: 'off' to: 'on' condition: - condition: state entity_id: binary_sensor.lumi_lumi_sensor_motion_aq2_ias_zone state: 'on' action: - service: zha.set_zigbee_cluster_attribute data: ieee: '00:15:8d:00:xxxxxxxx' # your Aqara IEEE endpoint_id: 1 cluster_id: 1280 cluster_type: in attribute: 2 value: 0 mode: single
or a short appdaemon app:
aqara: module: aqara class: Aqara timeout: 4 motion_sensors: - binary_sensor.motion_eg_flur_ias_zone - binary_sensor.motion_eg_flur_innen_ias_zone - binary_sensor.motion_eg_kueche_ias_zone - binary_sensor.motion_eg_wohnzimmer_esstisch_ias_zone - binary_sensor.motion_eg_wohnzimmer_wohnsofa_2_ias_zone - binary_sensor.motion_eg_wohnzimmer_wohnsofa_1_ias_zone - binary_sensor.motion_eg_hauswirtschaftsraum_ias_zone - binary_sensor.motion_eg_bad_ias_zone - binary_sensor.motion_eg_treppenhaus_ias_zone - binary_sensor.motion_og_flur_ias_zone - binary_sensor.motion_og_bad_ias_zone - binary_sensor.motion_og_k_ias_zone - binary_sensor.motion_og_l_ias_zone - binary_sensor.motion_og_n_ias_zone - binary_sensor.motion_og_schlafzimmer_ias_zone - binary_sensor.motion_og_abstellraum_ias_zone motion_IEEEs: - 00:15:8d:00:05:49:bb:0b #binary_sensor.motion_eg_flur_ias_zone - 00:15:8d:00:05:d0:07:96 #binary_sensor.motion_eg_flur_innen_ias_zone - 00:15:8d:00:05:d0:07:97 #binary_sensor.motion_eg_kueche_ias_zone - 00:15:8d:00:05:cf:4c:e3 #binary_sensor.motion_eg_wohnzimmer_esstisch_ias_zone - 00:15:8d:00:05:6a:7d:85 #binary_sensor.motion_eg_wohnzimmer_wohnsofa_2_ias_zone - 00:15:8d:00:06:41:1c:6e #binary_sensor.motion_eg_wohnzimmer_wohnsofa_1_ias_zone - 00:15:8d:00:05:cf:4d:2c #binary_sensor.motion_eg_hauswirtschaftsraum_ias_zone - 00:15:8d:00:05:49:bb:53 #binary_sensor.motion_eg_bad_ias_zone - 00:15:8d:00:05:bd:25:c6 #binary_sensor.motion_eg_treppenhaus_ias_zone - 00:15:8d:00:05:7f:8b:37 #binary_sensor.motion_og_flur_ias_zone - 00:15:8d:00:05:7f:8a:e6 #binary_sensor.motion_og_bad_ias_zone - 00:15:8d:00:05:4c:e0:07 #binary_sensor.motion_og_k_ias_zone - 00:15:8d:00:06:33:1c:8c #binary_sensor.motion_og_l_ias_zone - 00:15:8d:00:05:4c:c1:a6 #binary_sensor.motion_og_n_ias_zone - 00:15:8d:00:06:3d:dd:a3 #binary_sensor.motion_og_schlafzimmer_ias_zone - 00:15:8d:00:04:5e:bb:09 #binary_sensor.motion_og_abstellraum_ias_zone
import json import time import hassapi as hass MODULE = 'aqara' CLASS = 'Aqara' CONF_TIMEOUT = 'timeout' CONF_MOTION_SENSORS = 'motion_sensors' CONF_MOTION_IEEES = 'motion_IEEEs' DEFAULT_TIMEOUT = 4 class Aqara(hass.Hass): def initialize(self): """Initialize the Aqara app.""" # define global variables global motion_sensors motion_sensors = self.args.get(CONF_MOTION_SENSORS, ) global timeout timeout = self.args.get(CONF_TIMEOUT, DEFAULT_TIMEOUT) global motion_ieees motion_ieees = self.args.get(CONF_MOTION_IEEES, ) # create listeners for entity in motion_sensors: self.log("Aqara: Listen to entity: %s with timeout: %s", entity, timeout, level="INFO") self.listen_state(self.motion_sensor_state_off, entity, new = "on", duration = timeout) def motion_sensor_state_off(self, entity, attribute, old, new, kwargs): """Set motion sensor state to off""" current_ieee = motion_ieees[motion_sensors.index(entity)] # reset motion status in ZHA self.log("Aqara: reset motion status of entity % s in ZHA, ieee: %s", entity, current_ieee, level="INFO") self.call_service("zha/set_zigbee_cluster_attribute", ieee = current_ieee, endpoint_id = 1, cluster_id = 1280, cluster_type = "in", attribute = 2, value = 0)
btw.: If somebody knows how to query the IEEE of an entity_ID in appdaemon or how to construct the args much nicer (device_ID and IEEE not separated), feel free to contribute
I am using ZHA with a Sonoff Zigbee bridge and hardware hacked Aqara motion sensor. After seeing a few examples of automations to reset and the need for delay, I thought why not just add the delay directly to the reset automation. I am not sure what other implications there may be but this method is working flawlessly so far and without the AppDaemon motion sensor app.
alias: State Reset description: '' trigger: - platform: state entity_id: binary_sensor.master_bath_motion_zone from: 'off' to: 'on' condition: - condition: state entity_id: binary_sensor.master_bath_motion_zone state: 'on' action: - delay: hours: 0 minutes: 0 seconds: 15 milliseconds: 0 - service: zha.set_zigbee_cluster_attribute data: ieee: 00:15:8d....... endpoint_id: 1 cluster_id: 1280 cluster_type: in attribute: 2 value: 0 mode: single
Did you ever figure this out?
Unfortunately no, I tried to rewire to the back micro controller. It flashes in the beginning 3 times. But after do nothing. the button doesnt work or at least give no response.
I did more testing with the reset automation and found that I can get the motion to reset and re-trigger after the specified delay without the need for the hardware hack.
Can someone explain/show how to do it with a pencil? I don’t have any soldering equipment
Literally just draw a pencil line between the two points on the PCB. It works best with a softish pencil, but I used an HB pencil and just overdrew the line a couple of times to deposit enough graphite.
I have 2 aqara motion sensors. One of them resets at 5 seconds without any hardware modification, the other does not (I’ve set deconz.configure duration 5 for both). Weird
Are you sure it actually resets? From what I know, setting the deCONZ duration will make it send a “no motion detected” event after that many seconds regardless of whether the sensor is ready or not. So does the sensor trigger again after 5 seconds?
It does trigger again. I ended up setting a 15 sec delay in node-red, cause it was triggering too often.
The other one resets in HA, but does not trigger.
I checked and they both have the same firmware version, so I don’t know what’s the difference. Maybe one was from a test batch or something
Update: the second one works now on 5 seconds too, without me doing any hardware mod. I’ve just been tinkering with them in HA / deconz, pressed the side button once, I have no idea what changed.
- service: deconz.configure data: entity: binary_sensor.office_motion_sensor_presence field: /config data: duration: 5
For german spreaking - or at least understanding - people, I created a video about this topic (ZHA with hardware hack) on youtube. Enjoy: https://youtu.be/VIXZz9oy68w
Für deutsch sprechende bzw. lesende Leute habe ich zu dem Thema ZHA und Aqara Motion Sensor Hack ein Video erstellt: https://youtu.be/VIXZz9oy68w
so all of your sensors now work without the hardware hack? only with your automation?
Thats correct. No hardware hack, just the ‘reset’ automation. I was surprised as you are
But from what I see in your automation you reset the sensor state after 15 seconds: why?
15 seconds are much longer than the 5-seconds reset interval with the hardware hack: could it work also if you set the delay to 5 seconds in the automation? and without ghost re-activations?