edi/irrigation_system
edi
/
irrigation_system
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
irrigation_system/docs/concept.en.md

5.8 KiB
Raw Blame History

🇩🇪 Deutsch | 🇬🇧 English

Concept: Modular Irrigation System

This document describes the concept for a modular, smart irrigation system that is centrally controlled via Home Assistant.

1. Architecture Overview

The system is divided into three logical layers to ensure high flexibility and maintainability:

  1. Control Layer (Home Assistant): All logic, automations, and the user interface reside in Home Assistant. This is the "brain" of the system.
  2. Gateway Layer (ESP32): A pure protocol translator that acts as a bridge between the home network (WLAN/Thread) and the physical bus system of the plant. It contains no control logic of its own.
  3. Actor/Sensor Layer (Slave Nodes): Robust, specialized modules that are controlled via a bus and perform the actual tasks (switching valves, reading sensors).

System Architecture

2. System Components

  • Water Tank: An IBC container serves as a water reservoir.
  • Water Supply: A "rain thief" on the downpipe directs rainwater into the tank.
  • Pump: A pump with an integrated pressure expansion tank provides the necessary water pressure.
  • Actuators: Motorized 12V ball valves to control the water outlets.
  • Level Sensor (precise): A QDY30A with 4-20mA output and RS485/MODBUS interface for continuous measurement of the water level.
  • Level Sensors (Min/Max): Optional capacitive sensors (XKC-Y25-NPN or similar) as redundant protection against running dry and overflowing.

3. Gateway

The central communication interface is implemented as a "dumb" gateway.

  • Hardware: An ESP32C6-based board.
  • Function: The gateway acts as a transparent MODBUS TCP/IP to MODBUS RTU converter. It receives commands from the home network and forwards them to the RS485 bus and vice versa. It does not execute its own control logic.
  • Connection to Home Assistant: The connection is made via the home network, either via WLAN or in the future possibly via Thread/Matter. In Home Assistant, the official MODBUS integration is used to address the gateway and the slaves behind it directly.

4. Slave Nodes

The slave nodes are the working units in the field. To keep the effort low for small series production (e.g. at JLCPCB), a universal board design for all slave types is sought.

  • Microcontroller: An STM32G431PB. Although powerful, it offers all the necessary peripherals (multiple UARTs, ADCs, CAN) and enables a uniform hardware and software design.
  • Peripherals per Node:
    • Two High-Side Outputs (+12V): Realized via a VND7050AJ. Perfect for controlling the 12V motor valves (Open/Close). The Sense line of the driver is read out via an AD converter to realize an end position detection without physical limit switches by measuring the motor current (motor current at standstill ≈ 0).
    • Two Low-Side Outputs (0V): Outputs switched via N-channel MOSFETs. Can be used to control 12V LEDs in buttons or to switch the solid-state relay for the pump.
    • Two digital inputs: Direct, protected inputs on the controller for connecting buttons or the capacitive NPN sensors.

5. Bus System: MODBUS-RTU via RS485

MODBUS-RTU is consistently used as the bus system.

  • Reasoning: This choice is pragmatic, as the level sensor already requires MODBUS. This means that only a single, simple and widespread protocol is required for the entire system.
  • Physical Layer: The cabling is done via RS485. Commercially available Cat-7 Ethernet cable with RJ45 plugs is used:
    • 1 twisted pair for the bus signals A and B.
    • 3 pairs of wires in parallel for +12V and GND to supply power to the slaves.

6. Software

  • Operating System (Slaves): Zephyr OS. It is a modern, powerful real-time operating system that enables a clean and maintainable firmware structure.
  • Logic Implementation: The entire control logic (e.g. "If level < 20% and day of the week = Monday, then switch on valve 3 for 10 minutes") is mapped exclusively in Home Assistant via its automation engine.

6.1. Firmware Update of the Slaves (OTA)

The firmware of the slaves can be updated during operation via the bus without the need for direct physical access.

  • Concept: The MCUBoot bootloader is used. This is decoupled from the communication protocol.
  • Procedure:
    1. A script in Home Assistant reads the new firmware file (firmware.bin).
    2. The script breaks the file down into small data packets and sends them one after the other to the target slave via MODBUS command.
    3. The running application on the slave receives these packets and writes them directly to the secondary flash memory ("update slot").
    4. After successful transmission, the slave is restarted by command.
    5. MCUBoot checks the signature of the new image, copies it to the primary slot and starts it.
  • Security: The new firmware must mark itself as "functional" after starting. If it does not do this (e.g. due to a crash), the previous, stable firmware version is automatically restored by MCUBoot on the next restart by the watchdog.

7. Safety and Robustness Concepts

  • Fail-Safe Behavior: Each slave node implements a watchdog. If no valid MODBUS query is received from the gateway over a defined period of time (e.g. 15 seconds), the slave goes into a safe state: all valves are closed and relays (e.g. for the pump) are switched off.
  • Electrical Protection Circuits: All external interfaces are protected. The RS485 bus lines (A/B) are protected against overvoltages with TVS diodes on each board. Inputs and outputs receive basic ESD protection.
  • Power Supply: The 12V bus voltage is regulated on each slave node with an efficient TPS5430DDAR step-down converter to the required 3.3V for the microcontroller and the bus drivers.