FreeMDU: open hardware for Miele appliance diagnostics

The interface hidden behind the indicator light

FreeMDU provides open hardware and software tools for communicating with Miele appliances via their optical diagnostic interface, and it exists as a free and open alternative to the proprietary Miele Diagnostic Utility software, which is only available to registered service technicians.

The interface itself is the interesting piece of engineering. Most Miele devices manufactured after 1996 include an optical infrared-based diagnostic interface, hidden behind one of the indicator lights on the front panel. On older appliances, that interface is marked by a Program Correction label.

The hiding is deliberate on the manufacturer's part, and it is what made the interface inaccessible. Until now, communicating with it required an expensive infrared adapter sold exclusively by Miele, along with their closed-source software. The goal of FreeMDU is to make the interface accessible to everyone, for diagnostic and home automation purposes.

That framing explains the shape of the project, which is a hardware adapter plus a set of Rust crates rather than an application. The appliance is a black box that emits infrared codes through a light that was not meant to be a port, so you need something to emit and receive those codes, and you need software that knows the protocol spoken over them.

The project is licensed under either the Apache License, Version 2.0 or the MIT licence, at your option, with both licence files in the repository root. The last push was on 2026-05-03 and the repository is not archived.

Three crates: protocol, TUI, adapter

The project is split into three components, and the split follows the three things you might want to do.

Protocol is the core protocol library and the device implementations. It is the crate you use if you are writing your own software, and it holds the knowledge of how to talk to the appliance.

TUI is the terminal-based device diagnostic and testing tool. It is the component for a person at a workbench who wants to read a fault, poke a register and see what happens, and it is the one that has a demo animation in the repository.

Home is the communication adapter firmware with MQTT integration for Home Assistant. This is the piece that turns the appliance into something a home automation system can talk to, and it has two operating modes that the getting started section depends on.

The reverse engineering behind all of this is written up separately in a blog post linked from the README, which covers the proprietary diagnostic interface and the process of working it out. That link matters for anyone assessing the project, because a protocol reverse engineered from observed behaviour is by definition a best guess at the vendor's intent, and the write-up is where the evidence for those guesses lives.

The repository root is correspondingly small, with the three component directories, a demo animation, the two licence files and the README, plus a .github/ directory for the build workflow whose badge is at the top of the page.

The warning comes before the instructions

Immediately after the introduction, the README carries a caution block, and it is the most important paragraph in the document.

This project is highly experimental and can cause permanent damage to your Miele devices if not used responsibly. Proceed at your own risk.

That is not boilerplate. Think about what the tool does: it sends diagnostic commands to a washing machine or a dryer, and the commands a technician uses to test a heating element or a pump are the same commands that a badly timed one can destroy. The optical interface is the vendor's own service port, so the project inherits both its power and its hazards.

The combination of the warning and the licence position is worth stating plainly. The project is released under a permissive dual licence, and the disclaimer says it is an independent, open-source project that is not affiliated with, endorsed by or sponsored by Miele & Cie. KG or its affiliates, with product names and trademarks remaining the property of their owners and references to Miele appliances being for descriptive purposes only.

So the trade is explicit: a permissive licence, an open protocol and open hardware, in exchange for the fact that nobody vouches for the hardware and the protocol is reconstructed rather than specified.

Software IDs, and why there is no model list

When a connection is established through the diagnostic interface, the appliance responds with its software ID, a 16-bit number that uniquely identifies the firmware version running on the device's microcontroller.

The problem is stated immediately, and it is a good one. The ID does not directly correspond to a specific model or board type, so it is impossible to provide a comprehensive list of supported models. The project therefore publishes a table of the software IDs and device and board combinations that have been confirmed to work.

Ten combinations are listed as fully supported, and the variety is instructive. There is the W 985 and the W 980 on the EDPW 213 board with a Mitsubishi M37451MC microcontroller, a bare board on EDPW 223-A with an M38078MC-065FP, another bare board on EDPW 206 with an M37451MC-804FP, the W 487 S on EDPW 228-A, the G 7804 on EGPL 061 with an M38079EFFP, the G 651 I PLUS-3 on EGPL 542-C with an M38027M8, the W 2446 on EDPL 126-B, the W 3241 on EDPL 162-B, and the W 3164 on EDPL 151-B. The software IDs range from 218 to 2895, and the optical interface sits behind different indicators depending on the model, such as the Check inlet (PC) indicator, the (PC) DOS indicator and the Salt (PC) indicator.

The guidance for anything not on the list is that if your appliance has a model number similar to one of those above, it might already be compatible, and in all other cases determining the software ID is the first step toward adding support for new devices. The details for adding support will be provided soon, which tells you the onboarding path for a new model is still being written up.

Build an adapter, then pick bridge or standalone

The getting started section assumes you are willing to build hardware, because there is no way around it. You need the Rust toolchain installed, and you need to build a communication adapter as described in the home README, then attach it to the device.

Once the adapter exists, the README offers three use cases, and the difference between them is the firmware mode you flash.

For device diagnostics and testing, you flash the home firmware in bridge mode onto the adapter, attach it to the device, and run the TUI application on your desktop computer. The desktop tool drives the adapter, and the adapter drives the appliance.

For integration into home automation systems, and specifically for Home Assistant or another home automation system, you flash the same firmware in standalone mode and attach it to the device. Standalone means the adapter does the talking by itself, publishing over MQTT, and there is no desktop in the loop. That is the mode where the appliance becomes a smart device.

For building custom tools, you again flash in bridge mode, and then you use the protocol crate to implement your own software.

So the firmware mode is the fork in the road, and it is decided by whether your software is on the same machine as the appliance. Bridge mode for anything with a screen in front of it, standalone mode for anything that has to keep working when the laptop is closed.

Licence, contributions and the release lines

The licensing is the permissive dual option, and the README is explicit that you choose. Licensed under either of the Apache License, Version 2.0, with the LICENSE-APACHE file, or the MIT licence, with the LICENSE-MIT file, at your option.

The contribution clause matches. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work, as defined in the Apache-2.0 licence, shall be dual licensed as above, without any additional terms or conditions. That is a clean contributor agreement, and it is the standard way to keep a dual-licensed project dual licensed when contributions arrive under one of the two.

The releases are named per component rather than per repository, which tells you the three pieces are versioned independently. Protocol 0.1.0, TUI 0.1.0 and Home 0.1.0 were all published on 2025-11-15, within seconds of each other, so the three components are released together in practice while carrying separate version numbers.

They are all still at 0.1.0, and the last push to the repository was on 2026-05-03. The repository is not archived, so the project is not dead, but the version numbers tell you this is early software. The protocol is a reconstruction of a vendor's private protocol, the hardware is a device you solder, and the warning about permanent damage is in the README because the project does not think otherwise.

Editorial conclusion

Adopt FreeMDU if you repair Miele appliances, want to automate them through Home Assistant, or simply want the diagnostic interface to be open rather than a vendor accessory you can only buy with a service account. Do not adopt it as a casual home automation project, because the project states it is highly experimental and can cause permanent damage to the appliance, and do not expect a complete device list, since only ten confirmed combinations are documented. Before you start, identify the indicator light that hides the optical interface on your model, determine the software ID, and only then decide whether the device belongs on the fully supported list or the experimental one.

Frequently asked questions

Official sources

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