Case Study: Custom Smart Curtain Automation Controller
Automated curtains are easy to demo and hard to productize. Getting a motor to open and close on command is the simple part; building a controller that a product company can put its name on, install reliably across a whole building, and operate from the cloud is where most off-the-shelf hardware stops short. DigitalMonk was commissioned by a US product company to design that controller from the board up — a compact ESP32-S3 device that drives a curtain motor and speaks two protocols: Modbus RTU over RS485 for reliable wired installations, and MQTT for remote and cloud control. We designed the PCB, wrote the firmware, and manufactured the units. Five are already in the client's hands and working; twenty more are in the production pipeline, delivered as finished hardware rather than a design to hand off.
The Client's Challenge
Our client is building a curtain-automation product line and needed control hardware they could own, not source from a third party and hope it kept shipping. The market gave them two unsatisfying options. Consumer curtain motors come with a closed app and a proprietary cloud, which is fine for a single home but useless as the foundation of a product — you can't build a brand on hardware you don't control. Industrial actuators, on the other hand, are reliable and wired but assume a building-management system and offer no path to app-based or remote control.
What they needed sat in between and didn't exist as a single part: a controller reliable enough to be wired into a multi-unit installation and daisy-chained across a building, but also network-connected so an end user could operate a curtain from a phone or a schedule. It also had to ship in two physical forms — one that mounts to a wall or enclosure, and one compact enough to disappear into existing curtain-rod hardware. No single off-the-shelf board did all of that, which is why the controller had to be built from scratch around exactly those requirements.
The Engineering
At the core of each unit is an ESP32-S3, chosen for its onboard Wi-Fi — which the MQTT path depends on — and for the processing headroom to run the motor-control logic and both communication stacks without contention. The board runs on 5V and is mains-connected rather than battery-powered; a curtain controller lives permanently in a wall or a curtain track, so designing around a battery would have added cost and a maintenance burden for no benefit. Motor drive is handled by a MOSFET stage that switches the curtain motor in both directions for open, close, and stop. The whole board comes in smaller than a credit card, with a USB-C connector for programming and configuration, a 4-pin terminal block for motor and power, and a JST header for additional peripherals. This is work our ESP32 developers own end to end, from schematic to a board that behaves the same across a production run.
The firmware, written in ESP-IDF, is built around the dual-protocol requirement, and this is the part worth being precise about because it's the real engineering decision on this project. The controller speaks Modbus RTU over RS485 for wired installations: RS485 is a differential serial bus that shrugs off electrical noise and runs reliably over long cable runs, and Modbus RTU gives each unit an address so many controllers can share one bus and be commanded individually — exactly what a multi-curtain building install needs. For remote and cloud control, the same firmware publishes and subscribes over MQTT to a HiveMQ broker, so a curtain can be driven from an app or a schedule over the network. Supporting both isn't redundancy; the two protocols answer two different deployment realities. A hotel or office wiring dozens of curtains onto a reliable local bus doesn't want each one depending on Wi-Fi, and a homeowner operating a curtain from their phone doesn't want to run RS485 cable. Building both into one controller means the client sells one product into both situations. Underneath, the control logic is a small state machine — idle, opening, closing, stopped — that responds identically whether a command arrives over the wired bus or the network, so behavior is consistent no matter how the unit is being driven.
The two form factors ship on the same core PCB, which is a deliberate production choice rather than two separate designs. One variant carries an integrated mounting frame with fixing holes for wall or enclosure installation; the other omits the frame for a compact board that integrates directly into existing curtain-rod hardware. Keeping one electrical design behind both means one firmware image, one bring-up procedure, and one set of parts to source and test — the installation context changes, the engineering underneath doesn't. That kind of decision is what full PCB design and manufacturing under one roof is for: the same team that designed the board decided how it should vary in production, so the variants stayed cheap to build and support. It's also why the network side of the product — the MQTT connectivity that turns a wired controller into a remotely operable one — was designed in from the start rather than bolted on afterward.
Production and Delivery
Designing a working board is one thing; producing units that all behave the same is a separate discipline, and it's where end-to-end capability actually shows. This is a small-batch production run — five units delivered and confirmed working, with twenty more in fabrication for the same client, for twenty-five total across the two variants. Every board carries a QR-coded serial number on the back, numbered sequentially from 0001, so each physical unit is individually traceable through assembly and into the field — the kind of production hygiene that matters when a client is going to deploy and support hardware under their own brand rather than treat it as a one-off. Units are assembled, flashed, and bench-tested before they ship, so what arrives is hardware that works on unpacking rather than a board that still needs bring-up.
The repeat order is the part worth reading closely. The client didn't commission a prototype and stop to evaluate — the first five went out working, and twenty more are already in production for the same line. A follow-on order of that size is the clearest signal available that the hardware does what it needs to in the client's hands, because a product company doesn't scale up on a controller it isn't confident putting its name on.
Outcome
The first units are with the client and working, and the twenty-unit follow-on run is in fabrication. We're being deliberately measured here: this is an OEM building a product on top of our hardware, so there's no public deployment to point at and no customer testimonial to quote, and we won't invent either. What there is happens to be the outcome that matters most for a hardware project — a working first batch and a repeat order to scale it. That's the evidence that the controller holds up as the foundation of a product, not just as a demo on a bench.
When a Custom Curtain Controller Is Worth Building
Most curtain-automation needs are met by something you can buy, and an honest hardware partner will say so. This project is a clear case of when buying doesn't work: the requirement wasn't a feature you could find on a spec sheet, it was a combination no single product offered — wired multi-unit reliability and network control, on hardware the client could own and ship in two form factors under their own brand.
Once the requirement is a combination like that, custom stops being a preference and becomes the only path, and the real question turns to whether it can be built at a sensible cost and scale. A twenty-five-unit run across two variants sits in the same awkward middle that a lot of real hardware does: too large to hand-build and call done, too small to justify mass-production tooling. Getting it right means deliberate choices — one shared PCB behind both variants, per-unit serial traceability, batch bench-testing instead of sampled QA — that keep a small run economical without giving up the consistency a product company needs. For an OEM, the payoff is control hardware competitors can't simply buy off the shelf, delivered as working units they can build a product line on.
What This Proves
This is what end-to-end hardware delivery looks like on an embedded automation product: a control problem defined by a client, returned as working units in two variants. PCB design, dual-protocol firmware, small-batch production, and per-unit traceability handled as one continuous job — the client received deployable hardware they can build a product on, not source files or a prototype to finish themselves.
Have a Custom Automation Hardware Idea?
Whether you need a custom controller board, dual-protocol firmware, or a small-batch production run of working units, DigitalMonk can turn your idea into deployable hardware.
