A soil moisture sensor that reads 24% is just a number. What makes it useful is the system around it — the infrastructure that receives that number, compares it to a threshold, and opens the right irrigation valve for the right duration. The infrastructure that logs the reading, shows it on a dashboard, and sends an alert if it drops to 15% at 2pm.
Most of that infrastructure, if you buy it commercially, comes with strings attached. Cloud subscriptions. Proprietary APIs. Systems that stop working when the vendor changes their pricing or shuts down a service. We’ve built our own — open, local, and designed to outlast any company’s business model.
Built on Home Assistant
The SEIN automation stack runs on Home Assistant — the world’s leading open-source home and building automation platform, with over a million active installations globally. Home Assistant handles the integration layer: connecting sensors, controllers, notification systems, and user interfaces through a unified local server.
We chose Home Assistant because it’s genuinely offline-first. Every automation decision happens on your local network. If your internet goes down, your sensors keep reporting and your automations keep running. If Home Assistant is unavailable, the edge controllers we’ve built continue operating independently, then sync when the connection restores.
We’ve built several components on top of that foundation specifically for agricultural settings — relay control, sensor bridging, and field interfaces that Home Assistant doesn’t natively cover.
The Relay Bridge
Agricultural control requires switching real loads — irrigation solenoid valves, pump motors, heating elements, fans. These operate at voltages and currents that microcontrollers can’t switch directly. Relay boards bridge that gap.
The SEIN relay bridge service manages two types of relay hardware from a single codebase:
Industrial Modbus relay boards — ruggedised units communicating over RS485. We use industrial-grade 16-channel relay boards capable of switching 240V AC or 24V DC loads on 16 independent channels. The Modbus protocol assigns each board a unique address on the RS485 bus, allowing multiple boards to share a single serial cable run — useful when a property has irrigation zones in separate buildings or paddocks, or when a single location needs more than 16 independently switched outputs.
Direct GPIO relays — for smaller deployments on single-board computer hardware where a Modbus bus isn’t warranted. The same service, the same Home Assistant integration, simpler wiring.
Both types register automatically with Home Assistant through MQTT Discovery — the standard protocol for zero-configuration device registration. When the relay bridge starts, each relay channel appears in Home Assistant as a switch entity, complete with state tracking and control capability. No YAML editing required.
Safety is built into the relay bridge at the firmware level. All relay channels default to off on startup and shutdown. Each channel has a configurable safety timer — a maximum on-duration after which the relay cuts power automatically, even if no off command arrives. An irrigation valve cannot be left open indefinitely due to a crashed controller or lost network connection.
A connection status sensor publishes to Home Assistant and triggers notifications if the RS485 bus goes silent — warning you before a silent failure becomes a dead crop.
The MQTT Proxy
Not every device speaks Home Assistant’s native protocols. Field-deployed sensor nodes — microcontrollers running custom firmware, commercial IoT gateways, RS485-to-WiFi bridges — often communicate over HTTP rather than MQTT. The SEIN MQTT proxy bridges that gap.
It’s a lightweight service running in Docker, accepting sensor readings over a simple HTTP API and forwarding them to the MQTT broker where Home Assistant picks them up. Under load it handles over 1,000 requests per minute with under 10ms latency — the sensor polling interval, not the bridge, is the limiting factor.
Each device registers itself on first contact — publishing its sensor metadata so Home Assistant can create entities automatically. Subsequent readings flow through a single endpoint. Bulk publishing allows a sensor node with multiple sensors to send all readings in one HTTP request rather than one per sensor.
Bearer token authentication and configurable rate limiting prevent unauthorised access. Structured JSON logging makes troubleshooting straightforward. A health endpoint lets monitoring systems verify the bridge is alive.
For a market garden with twelve sensor nodes spread across three paddocks, this means all soil moisture, leaf wetness, and atmospheric readings flow into a single Home Assistant dashboard without any per-device configuration — just register and publish.
The Field Terminal
Field workers managing irrigation don’t want to pull out a laptop to check zone status or toggle a valve. The SEIN field terminal puts that control on a handheld device with a screen.
Built on a compact display terminal with a colour touchscreen and physical navigation buttons, it connects to Home Assistant over MQTT and presents a scrollable list of irrigation zones with their current status. The form factor is designed for use with gloves on — rugged buttons, high-contrast display, readable in direct sunlight.
The terminal discovers zones automatically using Home Assistant’s MQTT Discovery data — no manual configuration of which zones exist or what they’re called. Up to 16 zones display with colour-coded status indicators. An environmental sidebar shows current temperature and rain status. Physical buttons handle navigation and control without relying on touchscreen precision.
For a property manager doing morning rounds, this means walking the property with a single device that shows every zone’s state and allows manual control without phone signal or a laptop — just the local WiFi that’s already running for the sensors.
The Full Picture
These components work independently but are designed to work together:
flowchart TD
A[RS485 Sensors] --> B[Relay Bridge / LoRaWAN Node]
B -->|MQTT| C[Home Assistant]
C --> D[Field Terminal\nOn-property control]
C --> E[Grafana\nHistorical dashboards]
C --> F[Mobile notifications\nAlerts anywhere]
C --> G[Automations\nVPD misting · soil moisture irrigation]
A soil sensor reading flows from the field through RS485 to a relay bridge or LoRaWAN node , into Home Assistant via MQTT, triggers an automation that opens a specific valve for a calculated duration, logs the event, and closes the valve whether or not the automation confirmation arrives. The field terminal reflects the updated zone state in real time. Grafana shows the moisture trend over the previous fortnight.
Every piece of this is open-source. Every data format is documented. Every component can be replaced or extended independently.
The Philosophy Behind the Stack
This isn’t about technology for its own sake. It’s about what becomes possible when the infrastructure for farm management is a commons rather than a product.
A small grower can know whether their drip irrigation ran overnight without buying a $50,000 SCADA system. A community garden can monitor their rainwater tank level without paying $200 a month in subscriptions. A regenerative farmer shouldn’t hand their soil data to a platform that mines it and sells insights back to the industry they’re trying to change.
The SEIN automation stack is our answer to that situation: good tools, built in the open, owned by the people who use them.
Get Involved
The relay bridge, MQTT proxy, and field terminal are all active, deployed projects. Code, documentation, and deployment guides are available in our repositories.
We need:
- Growers and property managers who want to trial the stack on their operations and help us understand where it falls short
- Developers with Python, Home Assistant, or embedded firmware experience who want to contribute to tools that run in real agricultural environments
- Electricians and makers comfortable with RS485 wiring, relay boards, and 24V DC systems
The goal is reliable, repairable, community-owned infrastructure for growing food. If that resonates, we’d like to hear from you.
All components are active, open-source projects. Repository links, deployment guides, and wiring diagrams are available and being expanded.
