Hardware components | ||||||
 |
| × | 1 | |||
 |
| × | 1 | |||
Hand tools and fabrication machines | ||||||
 |
| |||||
The idea for this project wasn't born in a lab, but from the frustration of a daily situation. One day, I left home in my car, which has the gate opener integrated into the headlight switch. However, I returned driving a different vehicle. As I pulled up to my house, the obvious and annoying realization hit me: I had no way to open the gate. I had to turn around, go get the other car, and only then could I get inside.
On that drive back, a question was hammering in my head: "With so many smart devices around us, why have garage gates been left in the past?" Right then and there, I decided I would build a smart gate myself.
Chapter 1: The First Prototype and the Discovery of MQTT
My first move was to develop a custom control board with an ESP8266 to replace the original one in my gate opener. The goal was to keep the traditional activation method, via 433MHz radio remotes, but add the ability for remote control over the internet.
My first attempt involved a Telegram bot. It worked, but the experience was disappointing. There was a significant delay between sending the command and the gate actually opening, which made the solution impractical.
The real game-changer was migrating the communication to MQTT. I set up a broker on my Ubuntu server (a Contabo VPS) and connected the gate's board directly to it. For the interface, I developed a simple web app using HTML, CSS, and JavaScript, which also connected to the broker via WebSockets. The result was instant and robust. The success was so motivating that my ambitions grew.
Chapter 2: The Lighting Paradox and the STM32 Solution
With the gate sorted, the next target was the house lights. But this introduced a fundamental paradox for any self-respecting home automation project: automation cannot eliminate physical control. I needed to be able to turn the lights on and off from both the app and the existing wall switches.
The solution was to use a more powerful microcontroller to manage the multiple inputs from the switches: the STM32.
I developed a central lighting control hub. The logic is as follows:
Each wall switch is connected to a pin on the STM32.
- Each wall switch is connected to a pin on the STM32.
When a pin's state changes (a switch is flipped), the STM32 inverts the corresponding light's current state (if it was on, it turns off; if it was off, it turns on).
- When a pin's state changes (a switch is flipped), the STM32 inverts the corresponding light's current state (if it was on, it turns off; if it was off, it turns on).
This solved the physical control aspect. To connect this hub to my MQTT broker, I used an ESP8266 acting as a gateway. The remote command flow works like this:
The App sends a JSON command to the MQTT broker.
- The App sends a JSON command to the MQTT broker.
The ESP8266 (gateway) receives the JSON, validates the command, and checks if the target device ID matches its own.
- The ESP8266 (gateway) receives the JSON, validates the command, and checks if the target device ID matches its own.
If valid, the ESP8266 sends the command to the STM32 via serial communication.
- If valid, the ESP8266 sends the command to the STM32 via serial communication.
The STM32 receives the instruction and triggers the corresponding light.
- The STM32 receives the instruction and triggers the corresponding light.
The final step was to integrate my bedroom's air conditioner. Simply sending commands wasn't enough. What if someone used the original remote control? The app would get out of sync.
To solve this, I created a board with an ESP8266 equipped with an IR emitter and, crucially, an IR receiver (TSOP4838).
This created a "two-way intelligence" system:
Control via App: The app sends a command via MQTT, the board receives it and uses the IR emitter to send the signal to the AC unit.
- Control via App: The app sends a command via MQTT, the board receives it and uses the IR emitter to send the signal to the AC unit.
Automatic Sync: If someone uses the original remote, the TSOP4838 receiver on my board "listens" for the command, interprets it, and sends the new state (e.g., "On, 22°C") to the MQTT broker. This updates the state in the app automatically.
- Automatic Sync: If someone uses the original remote, the TSOP4838 receiver on my board "listens" for the command, interprets it, and sends the new state (e.g., "On, 22°C") to the MQTT broker. This updates the state in the app automatically.
Today, what started with a gate that wouldn't open has become a complete and centralized home automation system. Through a single, self-hosted web application running on any browser, I can control:
The garage gate.
- The garage gate.
The lights in the Garage, Living Room, Kitchen, Bedroom, and Bathroom.
- The lights in the Garage, Living Room, Kitchen, Bedroom, and Bathroom.
My bedroom's air conditioner, with its status always in sync.
- My bedroom's air conditioner, with its status always in sync.
The best part is having full control and privacy, without relying on third-party cloud services. For now, I consider the project complete, but I know the platform I've built is robust enough for any new ideas that come along. After all, in a DIY project, imagination is the only limit.
Comments