Node-RED Automations: Schedules, LDR Lighting and Context Variables
A dashboard waits for a person to click. An automation reacts when a condition becomes true, a time arrives or an event is received. The challenge is making the rule predictable when sensor values wobble, messages repeat or the runtime restarts.
This guide introduces scheduled triggers, a light-dependent-resistor (LDR) rule and Node-RED context. The LDR example assumes the input value has already been calibrated into a documented lux-like scale. A raw ADC count is not lux; calibrate your voltage-divider and sensor before assigning physical units.
1. Use scheduled Inject nodes deliberately
An Inject node can run once at startup, be triggered manually or repeat on a schedule. It is useful for time-based tasks such as a daily status summary or scheduled request. Verify runtime timezone and daylight-saving behavior where applicable—server local time and the intended household timezone may not be the same.
For schedules that control a real load, define what happens after a missed event or a restart. A missed “turn off” schedule should not leave a load on indefinitely without another safety rule. For high-consequence actions, use local hardware or independent interlocks rather than relying on one timer.
2. Add hysteresis to an LDR threshold
If a lamp turns ON below one threshold and OFF above the same threshold, noisy measurements near that boundary can cause rapid switching. Hysteresis uses two thresholds: turn ON when it gets darker than the low threshold, and turn OFF only after it becomes brighter than the higher threshold.
Example: turn a light ON below a calibrated 80 lux and OFF above 120 lux. These are illustrative thresholds, not universal values. Measure your sensor's behavior in its installation and adjust. Add a minimum interval between switching actions if the controlled device needs it.
3. Understand node, flow and global context
Node-RED context stores values between message executions. Node context belongs to one node; flow context is shared within a tab/flow; global context is shared across flows. Use the smallest scope that meets the requirement. In the example above, flow context remembers the current LDR-driven light state so the threshold rule knows which side of the hysteresis band it is in.
By default, context may be in memory and therefore lost when the runtime restarts. Persistent storage can be configured, but persistence does not automatically make every state safe to restore. Consider whether a state is a remembered decision, latest telemetry, or an actual physical output state; those are different concepts.
4. Reject stale and invalid sensor input
A sensor may stop reporting while Node-RED keeps its last value in context. That last value should not be treated as current indefinitely. Track the receive time and stop making new automatic decisions when the reading is too old. Decide whether stale data should hold the last state, turn a load off or raise an alert according to the application—there is no single safe default for all devices.
Validate payload type, range and source at the system boundary. Do not convert missing data to zero: zero lux might mean darkness, while zero caused by a failed sensor would create a false light command.
5. Test the rule before connecting a lamp
Use Inject nodes to simulate lux values. Test very dark, very bright, values between the two thresholds, nonnumeric input, out-of-range data, stale data and runtime restart. Confirm that the automation emits a command only when the state transition is intended.
When connecting a relay, check its active polarity, boot state and load interface. MQTT command publication is a request, not confirmation; update reported state from the device when possible. Keep physical safety independent from schedule logic.