← Back to projects

IoT / Embedded FeaturedPersonal project

ABUS FCA4100 drive integration with Home Assistant

Driving an ABUS motor via Arduino + ESP8266: non-blocking logic, fail-safe limit switches, watchdog and a configurable pulse time, wired into Home Assistant.

Problem

I wanted to control an existing ABUS FCA4100 drive remotely and as part of home automation, without modifying the manufacturer’s original electronics and without risking damage to the mechanism on control errors.

Context

A personal home-automation project. The drive has no native Home Assistant integration, and controlling the motor directly requires safeguards: the system must be resilient to firmware hangs and to any attempt to drive out of range.

Requirements

  • Remote control from Home Assistant (over WiFi).
  • No blocking of the control loop (responsiveness, real-time limit-switch handling).
  • Fail-safe safeguards: limit switches and a watchdog.
  • A configurable control pulse time (push-time).
  • Separation of control logic (Arduino) from connectivity (ESP).

Role

I designed and built everything: the electronics (power, level shifting, driver), the Arduino firmware, the ESP8266 WiFi bridge, and the Home Assistant integration.

Architecture

I separated concerns: the Arduino Uno acts as a deterministic motor and limit-switch controller, while the ESP8266 provides WiFi and a bridge to Home Assistant. They communicate over UART with voltage level matching (5V ↔ 3.3V).

Technologies

Arduino Uno (C++) for control logic; ESP8266 for WiFi and the Home Assistant bridge; a driver/H-bridge for the drive; 5V/3.3V level shifting on the UART lines; limit switches as safety inputs.

Design decisions

  • Uno + ESP split: deterministic control separated from time-variable network connectivity.
  • Non-blocking loop: time-based control (millis), no delay(), so limit switches and commands are handled immediately.
  • Configurable push-time: the pulse duration is a parameter, not hard-coded.

Trade-offs

  • Two microcontrollers means more wiring and level shifting, but much simpler and safer logic on each.
  • “Pulse-based” control (emulation) instead of full integration with the manufacturer’s electronics — less invasive, at the cost of no full telemetry from the drive.

Technical challenges

  • The logic-level difference between 5V (Uno) and 3.3V (ESP) risked damaging the ESP.
  • A delay() in the loop would block limit-switch and command handling.
  • A firmware hang could leave the drive in motion.

Solutions

  • Level shifting on the UART line between the Uno and the ESP.
  • A non-blocking state machine based on millis() — limit switches and commands handled every iteration.
  • A watchdog resetting the controller on a hang, and limit switches hard-stopping motion (fail-safe).

Result

The ABUS drive works as a home-automation device controlled from Home Assistant, while keeping the mechanism safe (limit switches + watchdog) and responsive (non-blocking logic). Network details (SSID, passwords, addresses) are kept in a separate file outside the repository.

Lessons learned

  • In embedded, “non-blocking” is not a style but a safety requirement — delay() can hide real risk.
  • Separating control from connectivity simplifies debugging and limits the blast radius of a single-layer failure.

What I’d do differently today

  • Add MQTT with state confirmations and connectivity-loss detection.
  • Consider motor current sensing as an extra safeguard (stall detection).

Interview talking points

  • Why I separated control (Uno) from connectivity (ESP).
  • How a watchdog + limit switches form a fail-safe layer.
  • Why non-blocking logic is critical when driving a motor.