PIR Motion Alerts from Node-RED to Telegram or Email
A PIR motion sensor can repeatedly report an active state while movement continues. If every message triggers a notification, a single event can turn into dozens of alerts. A reliable workflow needs to detect the event, apply a cooldown and make notification failures visible.
This guide assumes a PIR-equipped ESP32 publishes its state to MQTT or otherwise provides a clean Boolean/0–1 value to Node-RED. The same logic works with other sensor inputs. It covers the flow design rather than claiming that a particular sensor/module has been physically tested in your installation.
1. Start with a clean sensor state
Use a topic such as solderhub/home/entry/pir/state and send an explicit payload convention: 1 for detected motion and 0 for clear. Do not send arbitrary debug strings into the same topic. In Node-RED, inspect the full message and normalize the payload before using it in a switch or Function node.
Some PIR sensors require a warm-up period and their output may remain active for a hold time after motion. The alert workflow should respond to an inactive-to-active transition, not every sample while the sensor stays active. Sensor placement, field of view and environmental factors affect what it detects.
2. Detect a new event and enforce a cooldown
A simple Function node can ignore repeated active messages during a cooldown. The example assumes the input payload has already been normalized to numeric 0 or 1. It prevents alert flooding within one Node-RED runtime. If you run multiple Node-RED instances or require durable event state across restarts, design persistent/shared state explicitly.
3. Send a Telegram message
Use a maintained Telegram node integration or a supported bot API workflow, and configure the bot token in the node's credential store rather than inside message payloads or exported flow text. The notification text should include a device/area label and timestamp, not private credentials or more personal data than necessary.
Test using a private chat first. Confirm that credentials work and the flow respects rate limiting before adding more sensors or group recipients. Telegram node package names and setup may change; verify current node documentation and permissions for the package you install.
4. Send an email instead
For email, configure a maintained email node or SMTP integration with credentials stored in node configuration/environment settings. Check the SMTP server's expected TLS mode, port and authentication settings; do not copy an old mail-server example blindly. Send a single test notification before connecting the PIR input.
Email delivery can be delayed or rejected, so treat notification as best-effort rather than a safety mechanism. Add a Catch/error branch or equivalent diagnostics so an authentication or provider failure does not disappear silently.
Reliability and privacy
- Use a transition rather than sending an alert on every active reading.
- Add a cooldown and, if needed, a daily cap or summary.
- Test PIR warm-up, retrigger behavior and false positives in the target room.
- Keep message text minimal and avoid unnecessary personal/sensitive data.
- Store secrets in credentials/configuration, never in exported sample flows.
- Decide what happens if Node-RED, the broker or internet access is down.
- Do not make a Telegram/email message the only alarm for a safety-critical use case.
Troubleshooting
Too many messages: verify the payload is normalized and the flow detects rising edges rather than every active sample. Increase cooldown only after understanding sensor hold time.
No alert: test the flow with an Inject node, inspect the message before the notification node, and verify bot/SMTP credentials.
Duplicate alerts after restart: the sample cooldown is runtime context; if it resets on deploy/restart, configure appropriate context storage or external deduplication when persistence is necessary.
Sensor chatters: adjust placement, supply and module settings, and consider a short debounce window while preserving real motion events.