Node-RED is convenient for assembling irrigation scenarios: MQTT inputs, conditions, delays, relay commands, notifications and logging are connected visually. This is a powerful tool for those who understand data flow. But precisely because of the flexibility of Node-RED, it is easy to turn automatic watering into an opaque scheme, where it is not clear why the pump turned on.
For plants, Node-RED is best used as a script layer, rather than as a place where all the knowledge about the zone is hidden. GrowerHub should see events and reasons: the sensor is below the threshold, the limit is checked, the pump is turned on for 20 seconds, stopped by a timer, there is no leakage.
Where Node-RED is useful
Node-RED is good for combining sources: MQTT from ESP32, Zigbee2MQTT, Home Assistant state, webhook, schedule and notifications. It is convenient for prototypes and difficult conditions: for example, watering is allowed only in the morning if the humidity is below the threshold for two measurements in a row, there is no leakage and there has been a pause since the last start.
It is also useful for integration with external channels: Telegram, email, local files, HTTP API. But every action must leave an event in GrowerHub or another log.
Where Node-RED is dangerous
Danger begins when flow becomes the only place of safety. If they forgot to handle the loss of the sensor, the old MQTT message can start the pump. If there is no separate stop timer, the relay may remain on. If flow is changed without comment, diagnostics turns into viewing nodes.
Critical restrictions must be explicit: maximum duration, pause, daily limit, leakage, service mode. It is better to duplicate the stop constraint closer to the controller than to rely only on a long flow.
Flow structure
Divide the flow into blocks: input data, freshness check, watering conditions, limits, command, confirmation, log. Do not mix sensor processing and pump command in the same node without a clear name. Add debug only for debugging, and send persistent events to the log.
MQTT topics must be designed in advance. The article MQTT-automated watering suggests separation of state, commands, availability and events.
Testing
Before real watering, test flow on a dry start: the command does not turn on the pump, but writes an event. Then check for sensor failure, leakage, repeated message, restart Node-RED and loss of internet. If, after a restart, flow forgets the state of the last watering, the pause between starts may be disrupted.
Reliability without the Internet is described in the article reliability of automation without the Internet.
Conclusion
Node-RED is great for watering scenarios if the flow is transparent, we test and write events. Don't hide security in unobvious nodes. For GrowerHub, a log of cause and effect is important, otherwise the visual diagram will become another black box.