Figured this is the best place for musings on what type of PIR sensor to get - the upshot - get one which has both motion and light like a Aqara PIR P1.
Not only does it have a light sensor as well as the motion detector, its small, elegant looking and uses 2 coin batteries for a long battery life (>5 years ?!?). It also has a few other features in Z2M that are worth having .
Overall, My Smarthome system is comprised of Home Assistant running on a R.Pi4 (2G) with a Sonoff dongle in Z2M mode, 2 x Aqara PIR and an INNR power switch.
N.B. I was able to write the automation using just the visual editor (no direct YAML coding was required). This means that if you create a dummy automation, you can paste the following YAML code via the button “Edit in YAML”. Once you have done this, you can go back to the visual editor and you will see all the logic
- In your PIR devices, set the PIR “on time” duration to be as short as possible (I use 2 seconds)
- Where you see the number 3 in the YAML code, change it to the “on time” duration you want (after triggering). Be aware that the automation logic controls the “on time duration”, and not the sensor!
- Where you see number 10 in the YAML code, change it to the max LUX level (maybe 20?) i.e. When ambient light is ABOVE this level, the switch will NOT turn on
Be aware that if you use a combination of “motion only” PIR sensors with a separate Light (LUX) sensor, you cannot reliably code an automation where the light level is always sensed “just before” motion is detected.The reason for this is that between the different devices, you cannot easily synchronise the timing of “light” and “motion” readings in your automation code. You end up thinking that to fix this, you need to regularly get light readings and maybe store the light level somewhere in your automation code. Not only is this awkward, but the regular polling of a light sensor is a waste of network. This is a bad system design approach really. Its better to avoid unneccessary noise in the network.
If you don’t use a light sensor (or “day timing”) in your automation logic, the lights will always come on every time motion is detected. Whilst this is probably OK for areas that do not see natural ambient daylight (e.g. a dark cellar), The light always being turned on will look a bit foolish in areas which do see natural ambient daylight e.g. room (and stairs)
If you use “day timing” in your logic (is it daytime or nighttime?), this will involve the automation code either accessing information from outside your network or accessing “something extra” that has to be taken care of in your internal system. Consider that any “something extra” requires separate maintenance so that it is always correct e.g. Setting the date/time and sunrise/sunset times). Also, any use of “day timing” may not reflect the actual light situation where the sensor and lights are placed e.g. in a dark cellar where there is no natural light
If you were to develop a “motion only” sensor device in ESPhome with the trick of “Don’t send a signal if ambient light is above a set level”, be aware that the automation code ALWAYS needs to recognise any motion re-triggering e.g. when anyone is loitering in the room (or stairs).
If you involve any light reading mechanism into this scenario, then you must also consider that the light that was previously turned on by a motion detection when the room was dark, will likely affect the light sensor reading when any subsequent retriggering of motion detection occurs whilst the light is still on (i.e. it is now not dark).
The answer to all of this is to use a combined “motion and light” sensor like the Aqara P1 (or you develop your own device that communicates both types of information in one message).
Using a device like this means you don’t need to think about “day timing” or storing any previous light level values in automation code because the timing of both types of readings is synchronously sent by the Aqara P1 sensor. Because of this, you always get the correct light level that you really want to use in your automation i.e. “What is the light level just before the motion is triggered”. This also means that you do not need to handle anything extra to support “day timing” information retrieval, and that the same automation code can work without anything needing to be changed for sensors and lights being placed in dark cellar situations or not (e.g. a room with windows or stairs) It just does what you want it to do i.e. “When it is dark where I am and you sense me there, turn on the lights”
If you follow the automation logic as seen below, you will see that if the switch is already turned on, the automation code ignores sending any further “turn on” signals to the switch (which is what you want). If the switch is already on, there is of course, no real need to send yet another “turn on” signal to the switch.
It also easily deals with turning the switch off by just checking for the condition when all PIR sensors have been in a “motion not detected” state for the duration of the “timeout” period. This means that it is always the last PIR “timeout” trigger that gets through the automation logic to turn the switch off. This logic behaviour is effected by using a similar “off for 3 seconds” automation code in both the “trigger” and the “Then do” sections for every PIR sensor . Note that for switch “turn off” logic you don’t need to think about any light sensor readings, you just need to know if the person has left the room (or stairs) for a set period.
alias: Two Aqara P1 "PIR and LUX" Sensors to one switch (after Dark)
description: ""
triggers:
- trigger: state
entity_id:
- binary_sensor.0x54ef441000cc9be0_occupancy
from: null
to: "on"
- trigger: state
entity_id:
- binary_sensor.0x54ef441000cc9be0_occupancy
from: "on"
to: null
for:
hours: 0
minutes: 0
seconds: 3
- trigger: state
entity_id:
- binary_sensor.0x54ef441000ade463_occupancy
from: null
to: "on"
- trigger: state
entity_id:
- binary_sensor.0x54ef441000ade463_occupancy
from: "on"
to: null
for:
hours: 0
minutes: 0
seconds: 3
conditions: []
actions:
- if:
- alias: Does any PIR device signal that it has detected motion & it was dark?
condition: or
conditions:
- alias: PIR 1 detected motion & was Dark
condition: and
conditions:
- type: is_occupied
condition: device
device_id: 91c6a7069e2efc7a950a80733e2e416f
entity_id: 519a8ab8198c1cfa804f39431949b693
domain: binary_sensor
alias: PIR 1 is occupied
- type: is_illuminance
condition: device
device_id: 91c6a7069e2efc7a950a80733e2e416f
entity_id: 9c7cdf0269df754f8df9c3e7638632eb
domain: sensor
below: 10
alias: PIR 1 is Dark
- alias: PIR 2 detected motion & was Dark
condition: and
conditions:
- type: is_occupied
condition: device
device_id: 42d104812a203431608b250f5a40f3f1
entity_id: 15f07c8d67ef79011778bed0304c8973
domain: binary_sensor
alias: PIR 2 is occupied
- type: is_illuminance
condition: device
device_id: 42d104812a203431608b250f5a40f3f1
entity_id: 2ad32273ff54b2d929305428677213a2
domain: sensor
below: 10
alias: PIR 2 is Dark
then:
- type: turn_on
device_id: 7a7a0f46417791c41ac980dfe58cf57d
entity_id: 0fef26dfcfa358ea603ca1184896fb4b
domain: switch
else:
- if:
- type: is_not_occupied
condition: device
device_id: 91c6a7069e2efc7a950a80733e2e416f
entity_id: 519a8ab8198c1cfa804f39431949b693
domain: binary_sensor
for:
hours: 0
minutes: 0
seconds: 3
alias: PIR 1 has been unoccupied for 3 seconds
- type: is_not_occupied
condition: device
device_id: 42d104812a203431608b250f5a40f3f1
entity_id: 15f07c8d67ef79011778bed0304c8973
domain: binary_sensor
for:
hours: 0
minutes: 0
seconds: 3
alias: PIR 2 has been unoccupied for 3 seconds
then:
- type: turn_off
device_id: 7a7a0f46417791c41ac980dfe58cf57d
entity_id: 0fef26dfcfa358ea603ca1184896fb4b
domain: switch
alias: Has every PIR been unoccupied for at least 3 seconds?
mode: single