I built a Modbus home automation setup so I could control a lot of I/O without buying expensive modules. I wanted a cheap way to drive relays, read sensors and keep the wiring simple. I used RS-485 for the bus, small microcontrollers for nodes, and open-source home automation software as the master. This is what worked, what failed, and how I tested it.
Modbus is an old automation protocol that maps coils and registers to simple addresses. It runs over RS-485 for multi-drop serial links or over TCP for IP networks. For a home setup I chose Modbus RTU on RS-485 because it is cheap and tolerant of long runs. Wire the bus as a two-wire differential pair, keep runs daisy-chained, fit one 120 ohm terminator at each physical end, and add bias resistors if devices do not idle reliably. Pick one baud rate and parity across every node; 19200,n,8 is a decent compromise for many hobby installs. Give each slave a unique ID. Map real outputs to coil addresses and sensor values to holding registers. That mapping is what your home automation software will use to read and write states.
If you want DIY automation hardware, use an MCU plus an RS-485 transceiver. I used AVR and ESP32 boards with a MAX485 or equivalent chip. The MCU runs a Modbus slave stack and controls output drivers. For low-side switching, a current-sink open collector array works well and keeps costs down. In one build my total parts bill for a DIN-mounted 64-output board came to about £70, versus quoted official modules at roughly £2,500. The board used a chain of shift registers and MOSFETs driven by SPI to keep PCB real estate small. The firmware needs a stable Modbus stack and reliable SPI routines; expect to chase timing and race conditions early on. Add opto-isolation between the RS-485 and local power if you share long runs with mains loads. Give each output a clear spec: voltage, max current, and whether the load is inductive. Use a common 0V and a suitable fuse for each channel if you are switching significant currents.
Testing and troubleshooting are mostly about isolation and addressing. Start with a single slave on a short cable and use a Modbus master tool to poll coils and registers. Tools such as mbpoll or simple Python scripts with pymodbus let you read and write addresses and check responses. If a slave does not respond, check addressing, baud/parity, termination and transceiver direction control lines. Watch for garbage from ground loops; connect shields to protective earth at one end only. Log frames and look for CRC errors. A persistent CRC mismatch usually means wiring or parity mismatch. When you add many nodes, run the bus at sensible speeds, then lower the baud if errors rise. On complex boards, test each subgroup of outputs before fitting all 64 channels. That isolates a bad driver quickly.
For the master or user interface, pick open-source home automation that supports Modbus. Home Assistant has a Modbus integration for RTU and TCP, and Node-RED can sit between Modbus and higher-level logic if you want flows. Set the integration to match your Modbus configuration exactly: unit id, serial port, baud and register mapping. Use short polling intervals for critical state, longer for rarely changing sensors. Keep automation logic in the automation layer, not in firmware, so devices stay simple slaves. When you move from prototype to a final board, freeze the register map and document it plainly. Label addresses on the schematic and include example reads and writes in the README.
RS-485 wiring and termination are the usual causes of trouble. Keep Modbus configuration consistent across all devices. Use simple transceivers and open-source stacks for the firmware. Test in small stages, log frames and fix CRC errors first. With modest parts and some patience you can build a multi-node Modbus home automation system that works with mainstream home automation software and stays manageable.
