PIR sensor¶

Switch Input - Switch NORMAL CLIMATE

Introduction¶

A big difference from the regular tactile buttons and a PIR is that a PIR will output a high or low Signal without someone actually pushing a physical button. The PIR uses a pyro detector which will detect change in radiated heat. A person or an animal is always radiating some level of heat and when someone enters the vision of the PIR the amount of heat will change and the PIR will trigger a signal.

Specifications:

Motion (change in heat)
Power needed: 5V (typically)
Output voltage: 3.3V (typically)

Note

Some PIR sensor boards have a jumper which will allow you to have the unit send a single pulse when the motion is detected or send a single repeatedly as long as motion is detected. Good boards also have a sensitivity adjustment and time delay setting which lets you tweak the way the unit is behaving, that could be really helpful if the default settings are triggering too much or not enough.

Wiring¶

ESP               PIR
GPIO (X)   <-->   I/O or OUT

Power
5V         <-->   VCC
GND        <-->   GND

Setup¶

Task settings¶

Device: Name of plugin
Name: Name of the task (example name Motion)
Enable: Should the task be enabled or not

Sensor¶

Internal pull-up: Check if you want to use the internal pull-up of the ESP (not all GPIO pins have this internal pull-up.)
Inverse logic: Sometimes you may want the physical high value to be published as a low value. For example if the button is triggering a high (1) value when you push it you maybe use it to turn of a LED so the Switch#State would then logically be preferred to be set as 0 and thus used as a variable for controlling that LED. See rules example below.
GPIO: Which GPIO should be used, recommended to not use a latching switch that may set the ESP into flash mode if left to high/low.
Switch type: Set the switch type to either “Switch” or “Dimmer”. PIR is a “Switch”.
- Switch: The default way of handling a switch is by a on/off button. It’s either on (1) or off (0).
- Dimmer: Not used by PIR switches, if you still want to use it you can have a look at the Switch page.
Switch button type: Set the type of switch, “Normal switch”, “Push button active low”, or “Push button active high”. * Normal switch: This is the general setting to use for a door (reed) switch.
- Push button active low: Not used by PIR switches (in general), if you still want to use it you can have a look at the Switch page.
Send boot state: If checked the unit will publish the switch state when booting. If not checked you may find yourself with a latching switch caught in limbo. This means that the unit is registering a low/high value but the physical state of the switch might be the opposite. If you use a mechanical switch that may be physically set to a state you should check this option.

Advanced event management¶

De-bounce (ms): How long should the pulse (the time you press the button) be, if set to high you need to have it published for a longer time before the unit will register it as an state change. You could experiment with this setting to find a good behavior of the button if you feel that it’s not responding according to your preferences.
Double click event: Not used by PIR switches (in general), if you still want to use it you can have a look at the Switch page.
Double click max interval (ms): Same as above..
Long press event: Same as above..
Long press min interval (ms): Same as above..
Use safe button (slower): Same as above..

Data Acquisition¶

This group of settings are standard available configuration items.

Single event with all values: When this setting is enabled, all available values will be sent in a single event <TaskName>#All, with all values in order as arguments to the event.
Show derived values: When checked, the Devices overview page, and the /json endpoint (used for updating the Devices overview page) will include any Derived values as defined. See the TaskValueSetDerived and TaskValueSetPresentation commands.
Event & Log derived values: When checked, the Derived values will be generated as Events, to be handled in Rules, and sent to logging devices like the Syslog server and/or SD-card logging.

(The derived values options are only available if String variables feature is included in the build.)

Send to Controller: Select the Controller(s) to send the Values to, either on a TaskRun command applied to the task, or on an Interval time action.

Send to Controller is only visible when one or more Controllers are configured.

Depending on the controller capabilities, some configuration settings may be shown:

../_images/Task_config_page_Controllers_section.png

All configured Controllers are shown here, including the enabled or disabled state (multiple Controllers can be enabled, only a single MQTT Controller can be enabled at one time!).

For each controller the user can select wether the data should be sent on each Interval (or explicit TaskRun).

For the Domoticz controllers the value index (IDX) has to be configured.

For some controllers, like Home Assistant (openHAB) MQTT, there are extra options available.

Group: This represents the group id to combine all values from multiple tasks into a single grouped-device during MQTT AutoDiscovery. Groups, by design, can span multiple ESPEasy devices, if desired, as long as the Task/Valuename combinations are unique. If a group should only combine Tasks from a single ESPEasy unit, the group id should be unique across multiple ESPEasy units. The group description, default Group <n>, can be adjusted in Home Assistant. If the Group value matches the current Unit nr, the Unit name, %sysname%, is used instead of Group <nr>.
- When Group is used, the Discovery unique id, by default, doesn’t include the taskname, causing devices with the same Value name in the same group to be overwritten in the MQTT broker. By setting the checkbox MQTT Discover, Group incl. Taskname on the Tools/Advanced page, the unique id will be made ‘more unique’ by including the Taskname. (Not enabled by default for backward compatibility).
Retained: For MQTT Controllers, this setting can be enabled to send the values for the current task with the Retain flag set. The Publish Retain flag in the Controller settings will override this by sending all task values with Retain flag enabled.
Send derived: This checkbox determines if any configured Derived values should also be sent to the controller (and included in the AutoDiscovery if that’s available and enabled).
Resend MQTT Discovery: When checked, will initiate a resend of the MQTT Discovery process for this task after a random delay after Submit is clicked, so any changed settings will be updated in the MQTT broker. This setting is only available if the controller is enabled, the Auto Discovery feature is available and enabled for the controller. This setting is not stored.

Other controllers, like f.e. FHEM HTTP, do not support additional settings besides the checkbox to enable sending the data.

Indicators/values (recommended settings)¶

Indicator	Value Name	Interval	Decimals	Extra information
State	Detection	0	N/A	Usually you just want the state being published when door is actually being opened/closed. If you want a continuous publishing of the state you may use the interval setting to do so.

Rules examples¶

on Motion#Detection=1 do
  timerSet,1,1
endon

on rules#timer=1 do
 if [Motion#Detection]=0
  //Action if NO motion is detected
 else
  //Action if motion is detected
 endif
endon

Where to buy¶

Store	Link
AliExpress	Link 1 ($)
Banggood	Link 2 ($)
eBay	Link 3 ($)

$ = affiliate links which will give us some money to keep this project running, thank you for using those.