Overview
The Conditional Logic Builder lets you define automation rules in plain IF/THEN terms — no coding required. Each rule watches one or more conditions on your sensors and actuators, and when those conditions are met it automatically takes action: toggling an output, adjusting a setpoint, enabling or disabling a PID controller, or sending an alert.
Rules are compiled into logic that runs directly on your Raspberry Pi inside Node-RED. This means your automations keep working even if the device temporarily loses its internet connection. The dashboard is only needed to create and manage rules; execution happens at the edge.
The Conditional Logic Builder is available on the Maker plan and above. Free and Hobby plans will see an upgrade prompt in place of the rule list.
How to Create a Rule
Open your device dashboard and navigate to Settings, then Automation Rules. Click Add Rule to open the rule editor.
Step 1 — Give the rule a name
Type a descriptive name such as "High Temperature Fan Override" or "Night Mode Lighting". The name appears in the rule list and in alert messages, so choose something that will be clear when you return to it weeks later.
Step 2 — Set priority and cooldown
Priority controls which rule runs first when multiple rules fire at the same moment. Lower numbers run before higher numbers — a priority 1 rule always runs before a priority 10 rule.
Cooldown sets the minimum number of seconds that must pass before the rule can fire again. The minimum is 30 seconds. Use a longer cooldown for rules that might otherwise fire continuously, such as a temperature threshold that hovers near its trigger point.
Step 3 — Add conditions
Conditions are the IF side of the rule. Click Add in the Conditions section to add your first condition. You can stack as many conditions as you need.
Each condition has a type:
Sensor Reading — checks the current value of any sensor on the device. You pick the sensor ID, a comparison operator (greater than, less than, at least, at most, equal to, not equal to), and a threshold number. For example: temperature sensor greater than 28.
Actuator State — checks whether a specific output is currently ON or OFF. Useful for rules like "only turn on the backup heater when the primary heater is already off".
Time Window — restricts when the rule is allowed to fire. You can set an after time and a before time in 24-hour format. For example, after 06:00 and before 22:00 means the rule only operates during daytime hours.
Duration — requires that the overall condition has been continuously true for a minimum number of seconds before the rule fires. This prevents brief spikes from triggering actions.
Step 4 — Choose AND or OR logic
When you have more than one condition, the AND/OR toggle at the top of the Conditions section controls how they combine.
AND means every condition must be true at the same time before the rule fires. Use this when you want a more specific trigger — for example, temperature greater than 28 AND humidity greater than 70.
OR means any single condition being true is enough to fire the rule. Use this when any one of several warning signs should trigger a response.
Step 5 — Add actions
Actions are the THEN side of the rule. Click Add Action to define what happens when conditions are met. A rule can have multiple actions that all fire together.
Each action has a type:
Toggle Actuator — turns a specific output ON or OFF. Provide the actuator ID and choose the desired state.
Change Setpoint — updates the target value for a PID controller. Provide the setpoint ID and the new numeric value. This lets rules dynamically shift temperature or pressure targets based on conditions.
Enable/Disable PID — starts or stops a PID controller. Useful for rules that switch a controller on only during certain hours or when prerequisites are met.
Send Alert — pushes a notification to your in-app notification center. Type a custom message such as "Reservoir level critically low — check immediately". Alerts sent this way also appear in the Activity timeline.
Step 6 — Save the rule
Click Create Rule. The rule is saved to the cloud and automatically mirrored to your Pi within a few seconds. You will see it appear in the rule list with a brief IF/THEN summary.
To pause a rule without deleting it, use the toggle switch on the right side of the rule card. A paused rule stays configured but will not fire.
AND vs OR Conditions — Choosing the Right Mode
Think of AND as a checklist — every item on the list must be checked before anything happens. This is the safer choice when you want to prevent false triggers. A rule like "temperature above 30 AND fan is currently OFF" will only fire when both things are simultaneously true, avoiding unnecessary on/off cycling.
Think of OR as a watch list — any single item on the list is enough to trigger a response. This is useful for catch-all rules where you want to respond to any of several possible problems. A rule like "pressure above 150 OR flow rate below minimum" fires the moment either reading goes out of range.
You cannot mix AND and OR within a single rule. If you need complex logic such as (A AND B) OR C, create two separate rules that each target the same action.
Use Cases
Temperature-based fan control
You grow microgreens in a climate-controlled rack. During summer the ambient temperature sometimes climbs too high even when the PID controller is running normally. You want a safety override that turns on an auxiliary fan whenever the air sensor exceeds 29 degrees Celsius.
Create a rule named "Auxiliary Fan Override". Add one condition: sensor reading, temperature sensor ID, greater than, 29. Add one action: toggle actuator, auxiliary fan ID, ON. Set a cooldown of 60 seconds so the fan is not rapidly cycled. Set a second rule to turn the fan OFF when temperature drops below 27 to avoid hysteresis ping-pong.
Nighttime setpoint adjustment
You ferment beer and want the temperature setpoint to drop by two degrees between midnight and 6 AM to slow yeast activity during the cold-crash phase.
Create a rule named "Cold Crash Night Mode". Add one condition: time window, after 00:00, before 06:00. Add one action: change setpoint, fermentation setpoint ID, value 18. Create a second rule named "Cold Crash Day Resume" with a time window of after 06:00 and a change setpoint action that restores it to 20. Both rules will repeat automatically every day.
Troubleshooting
The rule fires immediately and keeps repeating
The cooldown is set too low for how quickly the triggering condition changes. If a sensor reading hovers near the threshold, the rule can fire, the cooldown expires, and the rule fires again in a tight loop. Increase the cooldown to a value that gives your system time to respond — typically 120 seconds or more for actuator-based rules.
The rule never fires even though I can see the sensor reading is over the threshold
Check the sensor ID in the condition. The ID must match exactly the identifier used in the Configurator and shown in the sensor registry — it is case-sensitive and may include underscores. You can find the correct sensor ID by hovering over any sensor card on the dashboard; it appears in the tooltip or in Settings under the sensor list.
Also check that the rule is enabled. If the toggle on the rule card shows the rule is paused, it will not evaluate conditions regardless of sensor values.
Finally, verify that the device has received the latest rules. After creating or editing a rule, the Pi syncs within a few seconds, but if the device is offline at the time of creation it will sync the next time it reconnects. Check the device status indicator on the dashboard header.
A rule was deleted but the action still seems to be happening
Deleting a rule removes it from the cloud and from the Pi. However, if a rule had already turned on an actuator before it was deleted, that actuator stays in its last commanded state — there is no automatic undo. Manually toggle the actuator from the dashboard to restore it to the desired state.
My action says Change Setpoint but the PID controller is not responding
The setpoint ID in the action must match the PID setpoint identifier exactly. Check the Configurator to confirm the setpoint ID for the controller in question. Also confirm the PID controller itself is enabled — if it is disabled, a setpoint change will be stored but the controller will not act on it until it is re-enabled.
Known Issues and Limitations
A maximum of 20 rules per device is enforced. If you reach this limit, delete unused rules before adding new ones.
The minimum cooldown is 30 seconds and cannot be lowered. This protects your actuators from rapid cycling and prevents excessive RTDB writes.
All conditions in a single rule share one AND/OR operator. You cannot nest condition groups within a single rule. For complex branching logic, create multiple rules and use actuator state conditions to chain them together.
Duration conditions measure elapsed time from when the rule last began evaluating, not from when a specific sensor crossed a threshold. If the Pi restarts, duration timers reset to zero.
Time window conditions use the Pi's local system clock. If your Pi clock drifts or is in the wrong timezone, rules with time conditions will fire at unexpected times. Ensure your Pi timezone is set correctly in the system settings.