Here are the design decisions and the reasoning behind them.

DIN-rail form factor

A standard DIN-rail module unit is 17.5 mm wide. “4 units” means 70 mm — but in practice, DIN modules are 72 mm wide, with the 2 mm shared between adjacent modules. This means the PCB must be narrower than the enclosure, typically by about 4 mm on each side.

For the relay board I ended up at 72 mm wide × 90 mm tall. The PCB sits on a custom front panel (the part you can see when the cabinet is closed) that snaps onto the DIN rail clip.

The key constraint is height. DIN-rail cabinets use horizontal rail spacing, and most standard cabinets have rails spaced 125 mm apart. Your module (PCB + front panel + whatever protrudes from the back) must fit comfortably in 125 mm.

Relay selection

The relays are the physically dominant component. I went with the Omron G5LE-1 (5V coil, SPDT, 10A @ 250V AC). They’re common, well-documented, available from multiple distributors, and the footprint is standard.

The coil is 5V, which is unusual for a 24V-powered board. I drive the relay coils from the onboard 5V rail (from a 24→5V DC/DC), switched by N-MOSFETs (BSS138) controlled by the STM32 GPIOs. Each MOSFET has a flyback diode (1N4148) to absorb the coil’s inductive kick when the relay de-energises.

I considered 24V coil relays to eliminate the 5V rail entirely, but the MCU still needs a low-voltage supply and the RS-485 transceiver runs at 3.3V, so a multi-output DC/DC was unavoidable regardless.

Creepage and clearance

This is the part that trips up most PCB designers who are new to mains-voltage boards.

IEC 60664-1 (the relevant standard for insulation coordination in low-voltage equipment) specifies minimum distances between conductors at different potentials:

• Creepage (distance along the PCB surface between conductors)
• Clearance (shortest distance through air between conductors)

For 230V AC mains on a PCB intended for use in a fixed installation (Pollution Degree 2, Overvoltage Category II), the minimum clearance is 3 mm and creepage is typically 6 mm.

This affects relay footprint design, conductor routing near relay contact pads, and the PCB edge clearance. It also means you cannot route any 3.3V signal traces near the relay contact pads without explicit spacing checks.

In KiCad, I set up a custom net class for the mains-side nets with expanded clearance rules and ran DRC to verify. It’s not perfect (KiCad doesn’t do full IEC 60664 calculations), but it catches obvious violations.

The RS-485 driver

The SN65HVD3082E from TI is a robust choice: 15 kV ESD protection on the bus pins, ±12V common-mode range, and a low-power standby mode. I added a pair of TVS diodes (SMAJ6.5A) on the A and B lines for additional surge protection — the RS-485 cable runs close to mains wiring inside the cabinet, and induced transients are a real concern.

The driver is configured in half-duplex mode (single pair, direction controlled by the MCU’s DE/RE pins). The STM32’s USART in RS-485 mode handles the DE/RE assertion timing automatically, which is a nice hardware feature.

PCB stackup and copper pour

I used standard 2-layer FR4, 1 oz copper. The ground plane is on the bottom layer; signal and power traces on top. The key decision was the pour strategy near the relays: I excluded copper pour on the top layer inside the relay contact area to maintain creepage distances, and added a fiducial mark to help visual inspection.

What I changed in revision 1.1

The first prototype had two issues:

1. Power LED too bright — 3mm green LED with a 470Ω series resistor. Changed to 2.2kΩ. Now it’s visible without being aggressive in a dark cabinet.

2. DIP switch placement — I put it on the back of the PCB in revision 1.0. Inconvenient for address changes after installation. Moved to the front panel in 1.1, accessible from the front without removing the module.

The KiCad files in the repository are for revision 1.1.

Here’s what I learned.

The config_flow

The thing that makes an integration feel native is the config_flow — the UI-based setup wizard. Without it, users have to edit configuration.yaml, which is not a friendly experience for something that should be plug-and-play.

HA’s config flow is a multi-step wizard driven by Python classes. Each step returns either a form schema (asking the user for input) or a result (success, error, or abort). The tricky part is that you need to validate user input on the server side and report errors back to the form in a way HA understands.

For Domoriks, the flow has three steps:

1. Serial port — dropdown of detected ports + baud rate
2. Module discovery — non-interactive, shows discovered modules
3. Output naming — dynamic form generated per module per channel

The dynamic form on step 3 was the interesting challenge. HA’s vol.Schema (voluptuous) is evaluated at class definition time, but the number of fields depends on what modules were found at step 2. The solution is to build the schema dictionary dynamically in the step handler and pass it to vol.Schema() at runtime.

Entity lifecycle

HA entities need to be set up, maintained, and removed cleanly. Domoriks uses the DataUpdateCoordinator pattern:

1. The coordinator runs a background task that polls the bus on a fixed interval
2. All entities subscribe to coordinator updates
3. When the coordinator gets fresh data, all entities update their state in one cycle
4. If the coordinator encounters a bus error, all entities are marked unavailable

This is cleaner than having each entity poll independently, and it ensures all state updates arrive atomically (no partial updates where relay 1 is current and relay 8 is stale).

The gateway device

Something I added that isn’t in many integrations: a dedicated “gateway” device that represents the serial connection itself, not any physical module. It has:

• last_rx and last_tx sensors (useful for confirming the bus is actually alive)
• A bus_status sensor that goes to timeout or error if modules stop responding
• A raw command text + button pair for debugging

The raw command interface was particularly useful during development. Rather than writing a test script every time I wanted to send a Modbus frame, I could just type the hex bytes in a HA dashboard card and press the button. It’s now documented as a feature, but it started as a debugging tool.

Diagnostics

HA has a built-in diagnostics framework — implement async_get_config_entry_diagnostics and HA adds a Download Diagnostics button to the integration page automatically. The returned dict gets serialised to JSON.

I include bus stats (TX/RX counts, error rates), module states, and entity metadata in the diagnostics dump. When someone opens an issue, asking them to share their diagnostics JSON gives me almost everything I need to understand their setup.

Testing

Integration testing against a real RS-485 bus from a CI environment is tricky. I solve this with a lightweight test harness: a Python script that simulates a Modbus RTU slave over a virtual serial port (socat creates a pty pair). Tests run against the fake device on every PR.

# In CI:
socat PTY,link=/tmp/ttyDMR0,rawer PTY,link=/tmp/ttyDMR1,rawer &
python tests/fake_modbus_slave.py --port /tmp/ttyDMR1 --address 1 &
pytest tests/integration/ --port /tmp/ttyDMR0

It’s not perfect — it doesn’t simulate RS-485 bus errors or timing jitter — but it catches regressions in the integration logic.

What I’d do differently

The output naming step in the config flow generates one field per channel per module. With two modules of 8 channels each, that’s 16 fields on one form. Workable, but not elegant. I’d like to split this into a per-module flow where you name one module at a time, like HA’s own Zigbee integration does.

If you’re building a HA integration and have questions about any of this, open a discussion on the repo. Happy to help.

When I decided to automate the lights, I spent a few weeks researching options. Most of them shared one or more of the following problems:

Cloud dependency. A surprising number of “smart” products are dumb hardware with a cloud relay. If the company decides to shut down, pivots their business model, or just has an outage, your lights stop working. I own my house. I want to own my home automation too.

Replacing the switches. Most smart switch solutions require replacing your existing switches with new “smart” ones. In Belgium, many people have built-in wall plates that are architecturally integrated — not something you want to rip out. And if you’re renting, forget it.

Complexity hidden in simplicity. I tried a few “easy” solutions. They were easy until something went wrong, at which point the debugging surface was enormous — cloud, app, Wi-Fi, firmware, hub — and I had no visibility into any of it.

Price. Eight “smart” bulbs from a major brand, plus the hub, comes to a lot of money. For what is, functionally, some relays and a wireless radio.

What I wanted

My requirements were simple:

1. Works entirely locally — no internet required
2. Existing wall switches continue to work physically, not just as “smart” devices
3. Lives inside my distribution cabinet, not on a wall somewhere
4. Standard HA entities — I can automate them the usual way
5. Open schematics and source — I can fix it myself in five years

RS-485 with Modbus RTU is the obvious answer. It’s used in industrial automation for exactly this reason: simple, robust, long distances, no IP stack required. An STM32 with a handful of relays and a 485 transceiver is a very small, very understandable system.

Building it

The first relay board took about two evenings in KiCad. Ordered prototypes from JLCPCB. Soldered them by hand. Wrote a minimal Modbus RTU slave implementation from scratch — it’s maybe 400 lines of C.

The Home Assistant integration took longer. The existing Modbus integration in HA is powerful but complex to configure via YAML. I wanted something that felt native: UI setup, named entities, no configuration.yaml editing. Python, pymodbus, the config_flow API.

The result is Domoriks. It’s in my own distribution board right now, has been running for several months, and has worked correctly every day since commissioning. My regular wall switches still click satisfyingly. The HA dashboard has a switch for each circuit. Automations work the same as with any other entity.

What’s next

The immediate plan is to tidy up the documentation, add the switch input module (for reading push buttons and toggle switches without the mains circuit involvement), and publish everything properly.

If you’re building something similar — or want to adapt this for your own house — the repos are all public and the licence is MIT. Open an issue if you have questions.