FaderBuddy puts 60mm motorized faders behind two I2C pins

Why a board at all for a motorized fader

A 60mm motorized linear potentiometer, the kind used in Behringer mixing consoles, is a self-contained part with three things going on. It moves on its own, it reports where it is, and it has a capacitive touch surface. Each of those is a problem for a microcontroller hobbyist, and the reason FaderBuddy exists is that the parts are sold as spares rather than as a controlled interface.

The README describes the board as a modular control board for 60mm motorized linear potentiometers, and the pitch is that adding one, or many, to a project takes just two pins for I2C plus power.

What the board does is read the fader position, move the fader to a specified position, and provide haptic feedback and virtual detents, the last of which the README compares to the author's SmartKnob project. All of it is controlled over an I2C bus from a host controller such as an ESP32.

The design decision that makes this cheap to adopt is the split of responsibility. The onboard ATtiny1616 microcontroller handles all the real-time logic, that is the closed-loop motor control and the capacitive touch handling, and it presents a simple I2C bus interface. The README is explicit about the payoff: there is no need to wire a motor driver or H-bridge, and no need to implement a PID control loop for each motor fader yourself.

That is a real saving. A fader with a small motor, a potentiometer and a capacitive touch slider is three separate problems, and each one is a weekend of work if you do it yourself and a few hours if the board does it.

The board chains, so the bus stays at two pins

The scalability comes from the bus rather than from the board. Multiple FaderBuddy boards can be wired together and share just two I2C pins, and with right-angle pin headers you can plug adjacent boards into each other without any wires, for an expandable system that supports 18mm or 19mm spacing between faders.

That spacing detail is what makes the board usable in a mixer. A control surface has a grid of faders at a fixed pitch, and the board is designed so that a row of them is a row of headers plugged into each other, with the motor power and the bus carried along the chain.

The connectors on the other side are STEMMA QT and QWIIC compatible, which is the Adafruit and SparkFun convention for small plug-in connectors, and the README says they make it easy to hook the boards into the rest of a design.

The wiring itself has one rule that is worth reading twice, and it is in the pin table.

| Vmot | Motor power - 5v recommended |
| Vio | Microcontroller IO power - 3.3v or 5v. This must match the voltage for the SDA/SCL I2C bus! |
| GND | Ground reference |
| SDA | I2C data. FaderBuddy includes a pull-up resistor |
| SCL | I2C clock. FaderBuddy includes a pull-up resistor |

The motor runs on its own supply, and the logic rail is separate. The warning on the IO rail is the one to take seriously, because the I2C pull-up resistors are on the board and they set the bus voltage, so a host that drives the bus at 3.3v must power the IO rail at 3.3v as well. Mixing those is how you get a bus that works on one board and not on another.

The README documents three wiring arrangements, and the difference between them is mostly about how the extra 5v reaches the motor. A 3.3v microcontroller wired directly uses five wires, since 5v powers the motor and 3.3v powers the logic. A 3.3v microcontroller with a STEMMA QT connector needs an additional 5v wire for the motor, although further faders can still be chained directly through the pin headers with no extra wires. And a 5v STEMMA QT host needs an additional 5v wire between each board in the chain.

The ESPHome component and the Home Assistant view of a fader

The integration is the part that makes the board interesting beyond a bench project. The README says an ESPHome component allows FaderBuddy assemblies to be integrated into Home Assistant with just a few lines of YAML, and the example is short.

external_components:
  - source: github://scottbez1/FaderBuddy

fader_buddy:
  - id: my_fader
    on_manual_move:
      then:
        - lambda: |-
            ESP_LOGD("fader", "Fader moved to %d on layer %d", x, layer);

The component is loaded as an external component straight from the repository, so there is no separate package to install.

The list of what the component provides is what makes the difference between a fader that reports a number and a fader that is a Home Assistant entity. There is bidirectional position sync, so moving the fader updates the entity and setting the entity moves the fader. There are layer-aware automation triggers, with manual_move, touch_change and double_tap listed, which is the language of a control surface where one physical fader can mean different things depending on the active layer. There is per-layer haptic configuration. There is support for multiple faders on a single ESP32 over I2C. And there is one-click firmware updates of FaderBuddy boards from Home Assistant.

That last item is the one that changes the maintenance story. Without it, updating the firmware on a board means taking it apart or attaching a programmer, and with a chain of boards behind a panel that is a serious chore. Over the bus, from the Home Assistant interface, it is a maintenance task rather than a hardware task.

The movement side is equally short, from a lambda.

id(my_fader).remote_move_to(position, layer);

// optionally cap the speed - 0-255, where 255 is full speed
id(my_fader).remote_move_to(position, layer, 128);

Moving a fader takes a position and a layer, and the optional third argument caps the speed on a scale where 255 is full speed.

Layers, detents and haptics are first class

The layer concept appears throughout the documentation, and it is worth understanding because it shapes what the board is for.

A control surface with one fader per function does not scale. A mixer with twenty channels needs more than twenty faders to be useful, so the usual answer is layers, where a bank of faders changes meaning depending on the mode, and the host tells the hardware which layer is active. The board's API carries the layer in every movement call and in the position event, and the README lists a dedicated document, `ABOUT_LAYERS.md`, alongside the others.

The virtual detents are the other feature that comes from the same lineage as the author's SmartKnob. A detent is a physical notch in a fader's travel, the bump you feel when a channel reaches a defined position. A real motorized fader has no such notch, so the board synthesises one with the motor, and the haptic feedback does the same job for a touch that is not a movement.

The result is a control surface that can feel like a hardware console even though the faders are moving in a straight line, and that is the point of the haptic support rather than an extra.

The touch side is handled by the capacitive sensor in the fader, and the onboard microcontroller processes it, which is why the host does not need to poll it. The README lists touch_change and double_tap among the automation triggers, and the touch surface is separate from the position, so a gesture on a fader that has not moved is still an event.

The `ABOUT_MF60T_LOW_PROFILE_MOD.md` document in the repository suggests another dimension to the project, a modification for a low profile variant of the fader, and the `ABOUT_I2C_BOOTLOADER.md` document covers the bootloader that makes the over-the-bus firmware update possible.

What building one involves, including the flashing step

The README lists three things you need, and the middle one is the one with a catch.

The fader itself is a 60mm motorized fader, and the README names Behringer MF60T faders sold in packs of five as replacement parts from music and AV retailers, and notes that they appear to be manufactured by Soundwell. The pack format is worth knowing, because a control surface wants a row of them and a single fader is not a purchasable unit.

The board is the second item. It is available pre-assembled from Bezek Labs, which the README notes is US only and says that purchasing there directly supports the project, or you can use the design files to fabricate and assemble your own PCBs through JLCPCB.

The host is any ESPHome compatible ESP32 board with two free GPIO pins for I2C.

The catch is in the note. If you fabricate your own boards through JLCPCB, you also need to flash the firmware before use, and the README points at `ABOUT_UPDATING_FIRMWARE.md` for the instructions. The pre-assembled boards arrive with the firmware already on them, so the note only applies to the self-fabricated route, and the fabrication guide itself lives in `ABOUT_PCB_FABRICATION.md`.

That is the honest shape of this project. It is a hardware design that anyone can build, with an order-of-magnitude difference in effort between buying the assembled board and making your own, and the DIY route adds a programming step to a first build.

The repository also makes the hardware files available, with an `electronics/` directory for the board design, a `firmware/` directory for the ATtiny code, an `esphome/` directory for the component, and a `reference/` directory, plus a `platformio.ini` for the firmware build and `ci/` for the continuous integration.

Two release lines, an Apache licence and a sponsorship ask

The release history shows the project shipping two things in parallel, and the tag names make that explicit.

The recent releases are a firmware tag, `releases/firmware/v1.5` on 2026-10-03, and two ESPHome component tags, `releases/esphome/v0.4.0` on 2026-09-26 and `releases/esphome/v0.5.0` on 2026-10-03. The naming pattern is different from the usual project style, and it reflects a real property of the system: the microcontroller code and the Home Assistant component have separate version lines and separate upgrade paths, because the board firmware is updated over the bus independently of the ESPHome firmware on the host.

The last push was on 2026-10-16, so the project is actively worked on, and the repository is not archived.

The licence is Apache-2.0, with the text in `LICENSE.txt`, and the README addresses commercial use directly. It says that using the project in a commercial setting or for paid client work is fine, that it is open source and you should follow the terms of the Apache License including attribution, and then it asks that you consider sponsoring the project. The reasoning it gives is a good one for a hardware project: every iteration has real hardware costs, and sponsorships pay for prototypes and development tools.

The physical product is also sold, as an assembled board through the Bezek Labs Etsy store, and the README is clear that the store listing is US only.

For an adopter, the practical split is this. The design files, the firmware and the ESPHome component are open, and you can build your own if you have the time and the tools. The assembled board is a purchase, and the sponsorship is how the project says that the two are related.

Editorial conclusion

FaderBuddy fits a maker building a mixer, a control surface or a Home Assistant panel out of 60mm motorized faders and who does not want to write a motor control loop for each one. Skip it if your faders are not the 60mm motorized type, or if you cannot supply 5v for the motor separately from the logic rail. Verify first that the fader you have is the same model the board was designed around, that your host board can provide 5v for the motor and a logic rail matching the I2C bus, and that the firmware on a self-fabricated board is flashed before you plug it in.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. scottbez1/FaderBuddy on GitHub