My 7-year wired home automation project, refactored into reusable Controllino + ESP32 libraries

Projects Showcase
1

Hi all,

I wanted to share a long-term Arduino-based project that started during a house renovation about seven years ago and that I finally cleaned up enough to publish in reusable form.

The live installation currently uses six Controllino Maxi controllers distributed across multiple electrical panels in the house. Each controller handles the real field I/O, and each panel also has an ESP32 bridge that exposes the controller runtime over MQTT and Homie.

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 I went with local controller + Wi-Fi bridge pairs instead.

At the hardware level, the recurring pattern is:

  • 12/24 VDC power supply feeding the Controllino
  • the same source feeding a 5 V buck converter for the ESP32 bridge
  • TTL serial between Controllino and ESP32 through a 3.3 V / 5 V level shifter
  • low-voltage buttons and indicator lights on the controller side
  • higher-voltage loads switched within the Controllino limits

The controller side owns the real I/O and local click logic. The ESP32 side handles the network bridge role. That separation mattered a lot to me because I wanted the controller behavior to remain coherent even when Wi-Fi or the broker had problems.

The software started out much more monolithic. Over the years I kept refactoring it because I did not want it to remain a one-off personal installation forever.

The reusable public side is now split into:

  • lsh-core for the controller-side runtime
  • lsh-bridge for the ESP32 bridge runtime
  • lsh-protocol for the shared contract between the layers
  • node-red-contrib-lsh-logic for the orchestration side above MQTT

Project entry point:

Controller-side runtime:

ESP32 bridge runtime:

The installation-specific composition and deployment parts are still private, but the reusable core is public because I would genuinely like it to be inspectable, reusable, and possibly adoptable by other people with similar constraints.

I am not posting this as a universal recommendation or as a stack everyone should copy exactly. It is simply the result of years of building around a real house, real wiring constraints, and long-term maintainability.

If anyone here has built serious Arduino/Controllino projects that had to live for years in a real installation, I would be very interested in your feedback.

HAC-single-media-collage
HAC-single-media-collage1900×1120 420 KB

2 Likes
2

I also documented the hardware side separately here:

One thing I cared about a lot over time was serviceability. Early versions were much messier; the later panels are much more deliberate about connector quality, wiring clarity, and bridge maintenance access.

1 Like
3

Nice project, thank you for sharing. I love seeing other people's creations :smiley:

1 Like
4

Thanks, I appreciate it!

1 Like
5

Nice Job, thanks for posting.

1 Like
6

Good stuff, my sort of project.
With pressures on energy usage etc., the standard house build by jobbing tradespersons of consumer unit, room thermostat and badly fitting windows and doors for ventilation, just isn't going to hack it.
A house fit for the future needs the sort of controls and monitoring that go into the most basic modern vehicle.
If you can do it yourself, so much the better. The average trades van has enough stickers already.

1 Like
7

Exactly, that is very close to how I see it as well.
A lot of the basic building infrastructure is still surprisingly “dumb” compared to the level of control, feedback, and fault visibility we take for granted in other systems.
That was one of the motivations for me: not just automation for convenience, but a system where inputs, loads, state, and behavior are explicit and observable.
And yes, doing it yourself also means you get to understand the boundaries and maintain it properly later, instead of ending up with a pile of opaque branded boxes.

1 Like
8

Yes, and don't expect governments to take the lead.
It will be down to individuals with some initiative to do it.
And it's going to have to be better than policies like pushing out "smart" metering.
The only smart bit is laying off meter readers.

9

For me the key point is just having a system that is explicit, observable, and maintainable.
That was a big part of the motivation behind this project.

10

Working on it. My system is about 25 years old, all hard wired, with a PC controlling about 128 devices (24V and mostly 120V). It runs under DOS and has been very reliable.

The replacement, now in design, is CAN based with significant room for expansion. Each node acts as both master and slave and includes its own I/O. Each node will eventually contain its own schedule stored in FRAM.

Initially, a Pi will be used to control outputs through their associated nodes. I am currently testing with several control nodes and have not encountered any problems. No internet or WiFi is required for full operation.

The nodes can be any processor that supports CAN. In my case, this is mainly Arduino Nano, but I also have WeMos R1 D1 and UNO boards working, along with several Linux systems on the bus. The Linux systems are used for testing, monitoring, and development of the Pi software.

The Linux and Windows systems connect via a simple USB-to-CAN adapter.

11

The average cost of a pack of cigarettes in the United States is $8.00, with prices ranging from $6.11 in Missouri to $11.96 in New York as of 2026.

12

@gilshultz thanks for sharing that CAN-based direction.
That is a very interesting contrast to my setup.

My installation ended up with one local controller plus one Wi-Fi bridge per panel mostly because of the physical constraints of the house during renovation.
A shared wired bus between all panels was not realistic in my case, so I kept the controller side local and used the ESP32 bridge only as the network-facing layer.

The design goal is still very close to what you describe: the important behavior should
remain local and understandable, and the higher-level system should extend it rather than being required for every basic action.

Since the original post, I kept working mostly on making the Arduino/Controllino side easier to approach from the outside.

One practical change is that lsh-core is now TOML-first and published on the PlatformIO Registry:

Instead of writing the controller topology directly in C++, a consumer project describes devices, relays, buttons, indicators and click behavior in lsh_devices.toml.

A pre-build step validates that file and generates the static C++ profile before compilation.

A small example looks like this:

[devices.kitchen.actuators.ceiling]
pin = "R0"
auto_off = "30m"
[devices.kitchen.buttons.door]
pin = "A0"
short = "ceiling"
long = { after = "900ms", action = "off", target = "ceiling" }
[devices.kitchen.indicators.ceiling_led]
pin = "D0"
when = "ceiling"

The ESP32 bridge side is also published on PlatformIO now:

That package exposes the controller runtime over MQTT/Homie, while the controller remains responsible for the actual field I/O and local fallback behavior.

I would especially appreciate feedback on whether the TOML-first controller configuration makes the Arduino/Controllino side understandable from the outside.

The stack is still not meant to be a plug-and-play product, but I do want the reusable parts to be inspectable and realistic for people building long-lived wired systems.