Build Your First Local Node-RED Automation With Test Data

What are you building?

Build a small flow that classifies fictional study sessions by their recorded duration. Start with a manual trigger, route the record through one rule, and display the result. Keeping the input and output visible makes it easier to explain, test, and repair the automation.

Use the practice record {"task":"Read a chapter","minutes":25}. The acceptance rule is deliberately narrow: a numeric duration of 25 minutes or more goes to a branch named “Longer session”; a duration below 25 goes to “Shorter session.” These labels classify a record, rather than measuring attention or judging study quality.

Sketch the intended route in your notes: Inject, Switch, then a Debug node on each branch. Node-RED messages are JavaScript objects; payload commonly holds the main data. The Debug sidebar can expose the structure and value types. [1] Keep the original record intact while learning so that you can compare the input with the selected branch.

How should you prepare the local editor?

Use the current official installation instructions for your operating system and a supported Node.js version. Start Node-RED on your own computer, open its local editor, and keep the exercise away from public access. Confirm that the runtime starts without an installation error before building.

Follow Node-RED’s installation page instead of copying an old version number from a video. Its local guide explains the prerequisites, start command, editor address, and runtime log. [2] Record the versions shown in your own log; they will help if you later need support.

This exercise does not need a router rule, public tunnel, cloud server, or third-party node. The official security guide warns that the editor is unsecured by default for anyone who can reach it. [3] Do not expose it publicly. If you need remote access later, treat access controls and transport security as a separate setup task. For same-computer practice, set uiHost to 127.0.0.1 in the settings file and restart Node-RED. The configuration reference describes that binding. [6]

How do you inspect the first message?

Connect an Inject node directly to a Debug node before adding a decision. Configure the input as a JSON object, deploy the flow, and trigger it once. Inspect the resulting object and confirm that the duration is a number rather than a quoted string.

Create a new flow tab and name it “Study session practice.” Add an Inject node, open its settings, and configure msg.payload as the practice JSON object. Use the editor’s JSON/object input type rather than pasting JSON into a plain text field. Give the node a descriptive name such as “25 minute sample.”

Wire it to a Debug node configured to display msg.payload. Click Deploy, open the Debug sidebar, and press the Inject button. Node-RED’s introductory tutorial explains this basic trigger, wire, deploy, and inspect sequence. [4] Expand the payload. If the sidebar shows one long string instead of an object with task and minutes, correct the input type before continuing.

How do you add the routing rule?

Insert a Switch node between the input and the output. Test the message property holding the duration, compare it with the numeric threshold, and send unmatched values to a second output. Name both Debug nodes so the sidebar shows which branch handled the record.

Replace the direct wire with a Switch node. In its property field choose msg. and enter payload.minutes. Add a greater-than-or-equal rule with the number 25. Add an Otherwise rule after it. Wire the first output to a Debug node named “Longer session” and the second to one named “Shorter session.” Keep both displaying the payload.

The Switch node routes messages according to configured rules; Otherwise matches when earlier rules do not. [5] Deploy again and inject the sample. You should now be able to explain the route from the visible duration and rule. Avoid adding a timer yet: repeated messages make a simple wiring error harder to isolate.

Which test records should you try?

Test values on both sides of the rule and exactly at the threshold. Send one record at a time, compare the observed branch with your expected result, and investigate mismatches before extending the flow. Treat missing or invalid data as a separate problem, not a successful short session.

Duplicate or edit the Inject node to try the following records. Keep your expected result in a small note rather than relying on memory.

Then remove minutes, and separately try a negative value or a quoted value such as "25". These are data-quality probes. Record how your configuration handles them; do not assume Otherwise means “valid and short.” Before using external records, add explicit validation so malformed input can be rejected or flagged rather than silently classified.

What should you save before extending it?

Save the flow and a short record of its purpose, sample inputs, expected outputs, and known limitations. Reopen the saved work and rerun the boundary cases. Add an automatic trigger or external integration only after you can identify failures without guessing where the message disappeared.

Use the editor’s export function to keep a copy of the selected practice nodes, and store it beside your test notes. Use a descriptive filename and record the threshold. Inspect exports before sharing them; future flows may include addresses, configuration, or other information that should remain private.

Your finished exercise should meet these checks:

• A manual click sends one visible record.
• The payload remains an object with a numeric duration.
• The 24, 25, and 26 tests reach their expected named outputs.
• Invalid-data behavior is written down.
• A saved copy can be reopened and understood.

A useful next improvement is an explicit invalid-record branch. That teaches a more transferable automation skill than connecting several services before the basic rule is dependable.