Xiaomi Aqara Motion Sensor Component is faulty

Configuration
,
1

Hello Guys,

I moved from FHEM to Hass and think that the Xiaomi Aqara Component is faulty.

I use many motion sensors from Xiaomi.

If the sensor detects motion, it changes the state to “on” for exactly one minute. After exactly one minute, it checks again and if there is motion, it changes the state to “on” again (!). If there is no motion after one minute, it changes to “off”. Then it is constantly waiting for motionand so on.

In FHEM, I used an automation script that turns a light on (for 80 seconds) after motion and everytime it detects motion again (which can be after at least 60 seconds), it goes with another 80 seconds light.

But in Hass, this is impossible. After motion, the state changes to “on” for two minutes. If there is motion or no motion in the meantime, it won’t detect it.

So if I use an automation, the light hast to be on for at least two minutes (before it was at least one minute). If there is bad timing, it could even be possible that hass.io is not detecting any motion and turns the light off.

TLDR: Is Hass using the API wrongly or is it possible to change the two minutes locked state to the considered 60 seconds of the sensor and the Gateway API?

2

There is a whole thread on this which I suggest you read.

3

Please read the mentioned thread of @nickrout. This thread explains the technical background of this limitation.

1 Like
4

thank you for the info.
if you’re using a “generic” gateway, say conbee does this still apply?

5

Yes. It’s a firmware limitation of the motion sensor: hardcoded timeout. The sensor doesn’t publish immediate events via zigbee.

6

Thank you for your reply.
I already read the thread but the given info is wrong.

There is no such hardware limitation of the motion sensor with a two minutes timeout.

I use the sensors since many months and can confirm that the sensor sends new motion exactly 60 seconds after detected motion. Not 120 seconds.

And im 100% sure about that since I used the sensors with FHEM and never had any problems with the 60seconds. Just take a look in the Mi Home App or dirctly use the local API, timeout is one minute.

7

Just change the automation to switch off the light from 80 seconds to something >120 seconds.

8

Do you have an example code?
I tried it but it only works sometimes for me. Most of the time, it still turns the light off when there is motion.

Independently of this, the component is still faulty.

The API sends detected motion immediately and after the first motion.
After that, it sends “no_motion” after 120, 180, 300, 600, 1200 seconds no motion is detected.
But after the first detected motion, it checks of new motion after 60 seconds.
So if there is motion, it sends motion again.

Possible workaround for shorter timeout:
If Hassio detects motion, there should be a configurable motionOffTimer, e.g. 10 seconds.

So the sensor in hassio detects motion and 10 seconds after that, it turns off (instead of two minutes after that).

Because the sensor detects new motion after 60 seconds, it will report motion again and hassio again turns the sensor for 10 seconds on.

This worked perfectly in fhem so I know that it is also possible in Hassio.

If you want to take a look in the working FHEM component, check this out:

9

There is plenty of code in the thread @nickrout mentioned.

10

  1. Where is this API documented?

  2. Please submit a PR if you think you can improve Home Assistant. Otherwise your “this is wrong” talk is a bit out of place.

Cheers.

1 Like
11

Sadly, I didn’t see any official documentation of the API. I looked it up by myself and studied the fhem module.

I will take a look at the existing module and try to fix or improve it. But since I’m not an experienced developer, I can’t guarantee any success.

But the point that many other home automation services are able to use the sensors with a much shorter timeout (and also the official Mi Home App) shows that it should be possible.

12

Unfortunately I can’t decipher anything in that perl component. I find most perl impenetrable!

13

You are right. The hardcoded timeout is 60 seconds:

I don’t see any room for improvement. Which gateway version do you own? There is a difference between LAN protocol v1 (lumi,gateway) and v2 (acpartner.v3). @studentus ping!

14

I was in the same situation using motion_sensor.state
but in your case you should rely on xiaomi_aqara.motion event, it will trigger an event between 60s (hardware sensor delay) and your 80s (if there was motion) to delay your light from switching off
example of motion payload

{
  "event_type":"xiaomi_aqara.motion",
  "entity_id":"binary_sensor.motion_sensor_pantry",
  "event":{
     "entity_id":"binary_sensor.motion_sensor_pantry"
  }
}