My 7-year wired smart home stack, now made reusable: Controllino, ESP32, MQTT, Node-RED and Home Assistant

labodj · April 15, 2026, 1:18pm

Seven years ago, while renovating my house, I decided that I did not want the wired part of the installation to depend on cloud services or on a generic all-in-one controller.

So I started building my own stack.

Today the house runs on six Controllino Maxi controllers distributed across multiple electrical panels. Each panel has an ESP32 bridge that exposes the controller runtime over MQTT and Homie, and a Node-RED component in the middle handles discovery, health checks, and distributed automation logic. Home Assistant sits above that layer rather than owning the low-level behavior directly.

One practical reason it ended up this way is that a common field bus between all panels was not realistic in my specific installation, so a local Wi-Fi bridge per panel became the most workable option.

For a long time I kept all of this private because it was too tied to the real house, and because the early versions were honestly too messy to publish.

Over the years I kept refactoring the reusable part on purpose, because I did not want it to remain a one-off personal installation. I wanted the core to become something other people could actually inspect, reuse, and potentially adopt for their own setups.

That is why I eventually split it into four separate public repositories:

lsh-core for the controller-side runtime
lsh-bridge for the ESP32 serial-to-MQTT / Homie bridge
node-red-contrib-lsh-logic for the orchestration layer
lsh-protocol for the shared wire contract

Project entry point:

What stayed private is mostly the installation-specific composition: naming, panel mapping, OTA and deployment details, and the exact topology of the real house.

I am not posting this as a universal recommendation or as a stack that everyone should copy as-is. But I did convert the core of it into reusable libraries and documented it because I would genuinely like it to be useful to other people with similar constraints.

If someone wants to adopt parts of it, adapt it, or even try the overall approach, that is exactly why I finally made the reusable side public.

The design choices that mattered most for me were:

wired controllers first, network second
local logic should still remain coherent when Wi-Fi or the broker misbehaves
the network should extend the installation, not define its basic behavior
Home Assistant discovery should be generated from the orchestration layer instead of maintained by hand

If anyone here has built something similar around wired inputs, PLCs, MQTT, or Home Assistant sitting above a separate control layer, I would genuinely like to hear what worked for you and what did not.

And if anyone is interested in actually trying or adopting parts of the stack, I would be very interested in that as well, especially to understand what is still unclear or missing from the public documentation.

A couple of photos as well: one current panel snapshot and one early renovation-stage shot.

labodj · April 15, 2026, 1:23pm

I also documented the hardware side separately here:

github.com/labodj/labo-smart-home

HARDWARE_OVERVIEW.md

c933f3203

# Hardware Overview

This document describes the hardware pattern used in the current Labo Smart Home installation.

It is not a wiring manual and it is not meant to replace the official Controllino documentation, local electrical regulations, or the review of a qualified professional. It exists to explain how the public software repositories relate to the real hardware stack.

The current public snapshot of LSH is built around **six Controllino Maxi PLCs**, each paired with an **ESP32 bridge** inside one of the house electrical panels.

## Installation Pattern

The live installation is built around multiple electrical panels, each centered on a **Controllino Maxi PLC** and an **ESP32 bridge**.

At a high level, the controller owns the field I/O and deterministic local behavior, while the ESP32 bridge exposes the controller runtime over Wi-Fi through MQTT and Homie.

```text
12/24 VDC power supply
        |
        +-------------------------------> Controllino Maxi
        |
        +--> 5 V buck converter -------> ESP32 bridge

This file has been truncated. show original

labodj · May 4, 2026, 7:38pm

Small update since I posted this on April 15.

I kept working on the public side of the stack, mostly to reduce the amount of context someone needs before they can actually try individual parts.

The main changes are:

lsh-core is now TOML-first. Controller topology, relays, buttons, indicators and click behavior are described in lsh_devices.toml, then compiled into static firmware profiles.
lsh-core and lsh-bridge are now published on the PlatformIO Registry.
the central orchestration runtime has been split into a standalone Node.js package: GitHub - labodj/labo-smart-home-coordinator: Standalone MQTT coordinator for devices implementing the public LSH protocol contract. · GitHub
node-red-contrib-lsh-logic is now the Node-RED wrapper around that coordinator runtime.

The updated landing page is here:

The goal is still the same: keep the wired controller side local and predictable, while making the public pieces easier to inspect, install and try independently.

labodj · May 4, 2026, 7:44pm

The Home Assistant-related part also changed in a useful way.

Home Assistant MQTT discovery has been moved out of LSH into a generic Homie discovery package:

There is also a separate Node-RED wrapper for that discovery path:

That split is probably the most relevant part for Home Assistant users who do not care about the whole LSH stack.

The discovery package listens to Homie MQTT metadata and publishes retained Home Assistant MQTT discovery payloads. It supports Homie v3.0.1, v4 and v5, and the mapper is deliberately conservative: it handles common cases automatically, but it does not try to guess complex Home Assistant domains from generic Homie metadata alone.

When the metadata is not specific enough, overrides can be used for stable IDs, names, platforms and entity-specific details.

I would be very interested in feedback from people who use MQTT discovery at scale, especially around stable IDs, retained discovery payloads and conservative entity mapping. That part is now generic enough to be useful outside my own LSH installation.