B/S/H/ is one of the world's largest manufacturers of home appliances (according to this source, 10,000 dishwashers are produced every day at their factory in Dillingen alone). Some of their well-known brands are Bosch, Siemens, Gaggenau, Neff, Constructa and Balay. They have a well-maintained wiki where you can find all kinds of information about the company's history and the factories.
Despite this popularity, little is publicly known about the inner workings of the appliances. This project shows some of the things that have been discovered through reverse engineering. This project is in no way affilliated with B/S/H/. No intelectual property of B/S/H/ was used at any time.
Please do me a favor: 👍 If you use any information or code you find here, please link back to this page. ⭐ Also, please consider to star this project. I really like to keep track of who is using this to do creative things, especially if you are from other parts of the world. 😃 You are welcome to open an issue to report on your personal success project and share it with others.
Household appliances work with high voltages and currents. They generate heat and steam, they shake, vibrate and have rotating parts. You should have a good knowledge of electrics and take appropriate safety measures before opening or modifying such an appliance. Parts can get wet or hot, move or fall off.
Even if the marketing materials suggest otherwise, the technology of household appliances is relatively straightforward. A number of motors, heaters, valves and sensors are connected to a control unit and made available to the user via the fanciest possible user interface. It also seems to be the case that a manufacturer's devices, regardless of their external appearance and brand logo, differ only marginally on the inside.
✋ The following findings are probably only applicable to a certain generation of B/S/H/ home appliances, namely those with "EP" circuit boards. The washing machine boards are labeled "EPW", which probably stands for "Elektronik Platine Waschmaschine" (electronic circuit board washing machine). The dryer boards are labeled "EPT", with "T" for "Trockner" (dryer) and the dishwasher boards are using "EPG", with "G" for "Geschirrspüler". However, there is currently no known way of deducing the board version used internally from the external appearance or the model name. You have to open the machine and look inside.
The washing machine WM14S750 was sold from around 2010, when it was the test winner of the german magazine Stiftung Warentest. It was likely produced at the Nauen factory.
The control board (PCB front, PCB back) is based on an Freescale (now NXP) Semiconductor MC9S12Q128C-PBE16 MCU (52-pin LQFP package).
It also supplies power to all connected electronics.
The sticker suggests it was produced by melecs.
It has 11 RAST connectors for I/O (numbering according to PCB front):
01 ?
02 Switch (not front door?)
03 ?
04 ?
05 ?
06 ?
07 ?
08 Pressure sensor and likely D-Bus on one half of the connector, not tested
09 D-Bus
10 D-Bus
11 D-Bus
The control panel (Front view, back view) lets the user select 15 different washing programs, 8 temperatures, 7 spin speeds and and other options. The (mechanical) rotary switch is not only used to select the program, but also to switch the mains power on and off. The control panel is connected to the control board via D-Bus.
This sensors detects unbalanced loads (PCB front, PCB back, Enclosure).
It uses an PIC18F24J10 MCU (28 pin QFN package)
and an A007MPL DREMAS IC, which according to the manufacturer is a specialized 3D hall sensor
(the corresponding magnet is attached to the washing drum).
The device is connected to the control board via D-Bus.
There are 5 contact points on the back of the board that form a contact for in-circuit serial programming (ICSP) (top to bottom):
(+ sign), VDD, PGC, PGD, MCLR, VSS/GND. The chip can be interfaced with a PICkit programmer
and the MPLAB IPE.
The code can not easily be downloaded because the device has the Code Protection Bit set.
The module is used to connect home appliances to the Home Connect cloud (it was bought separately, according to the B/S/H/ website, it is not compatible with the washing machine WM14S750).
The model COM1 3/21 with FCC ID 2AHES-COMGEN1 uses an ST STM32F415 MCU.
There is a 30-pin connector on the board (looks like a Hirose DF12 board-to-board/BTB), which is used to connect to the antenna PCB. The antenna PCB seems to have an 6-pin connector presumably used for programming or debugging the MCU. Unfortunately the antenna PCB is missing on my side.
According to the B/S/H/ patent documents, this and this forum post, the electronics inside the device are interconnected via a proprietary serial bus called D-Bus or D-Bus-2. Since there are no public technical specifications, it is unclear what the possible difference between version 1 and 2 might be.
The bus found on the "EP" circuit boards consists of three wires: GND, VCC and DATA. VCC is 9V and DATA is TTL (5V). Connections are established using 3 pin 2.5 pitch RAST connectors. The connectors have coding lugs to ensure that they cannot be plugged into the wrong socket: The plugs with the two coding lugs in the middle are D-Bus plugs. They are commercially available from Lumberg, Stocko and probably many more suppliers. B/S/H/ sells somewhat pricy pre-assembled cables as well, e.g. the spare part 00631780.
It looks as if B/S/H/ has gradually introduced the D-Bus more and more into home appliances over the years:
- pre-2006 washing machines use the D-Bus only to control the display (in a rather simplistic way),
- 2006-2010 washing machines only use the D-Bus for the unbalance sensor and the control panel,
- post-2010 appliances also control the motor (and presumably other components) via the D-Bus.
All dates are only rough estimates, as the various models were produced and sold over longer periods of time.
Data is transferred on the D-Bus in a 8N2 configuration (2 stop bits). However, for reading the bus the more common 8N1 configuration will work as well.
The washing machine uses 9600 baud transfer rate.
The COM1 internet connection module cyclically tries out transfer rates from 9600 up to 38400 baud during startup, so newer devices probably use one of the higer rates.
The D-Bus is a (1-wire, the DATA wire) bus and not a straight serial cable (2-wire, RX and TX). All participants are reading (and possibly writing) the bus simultaneously. It is not yet clear whether the control panel acts as a master for the coordination or whether it is a multi-master bus (where something simliar to CMSA/CR or CSMA/CD is used).
This is by no means a complete description of the D-Bus protocol, but rather a layman's approach. If you look at the comparable specification for the CAN bus or LIN bus, you will see that there may be many more bits and tricks.
Data on the bus is transmitted in frames.
These frames consist of a length byte, a control byte, some data bytes and a two-byte (CRC16-XMODEM, thanks reveng) checksum.
For example, the frame 05 14 10 05 00 FF 00 DE 62 can be decoded as follows:
05 14 10 05 00 FF 00 DE 62
LL DS MM MM MM MM MM RR RR
LL = length, 5 message data bytes follow, total frame length is 9 = 1+1+5+2
DS = destination node and subsystem
MM = message data with length LL
RR = checksum (CRC16-XMODEM)
The destination node ("D" of DS-byte) designates the (unique) logical receiver of the frame and not necessarily a piece of hardware.
The subsystem nibble ("S" of DS-byte) specifies the subsystem within the destination node or classifies different types of frames. It is suspected to be of little importance, as an example the unbalance sensor works regardless of what value the “S” nibble has.
Some further considerations suggest that the first and second message byte have a special meaning:
05 14 10 05 00 FF 00 DE 62
LL DS M1 M2 MM MM MM RR RR => LL DS.CC-CC MM MM MM RR RR
All frames with identical DS-M1-M2 bytes have the same length. M1-M2 is therefore relabeled CC-CC (command), which then also determines the length and format of the following message bytes. The notation DS.CC-CC is introduced here as a distinct declaration for a command frame.
The DS.CC-CC tuples used depend heavily on the machine type (washing machine, dryer, etc.), the respective model and the components and commands used. It seems that there is no overarching defined set of commands.
It is very possible that there are also other 'non CC-CC' types of frames (e.g. a "stream mode" for uploading binary firmware). However, these have not yet been observed in normal operation.
After sending a frame, the sender leaves a gap of at least one byte (with 9600 baud data rate and 8N2 coding an idle time of 1.145 ms = 11 x 104.167 µs) before before possibly sending the next frame. The receiver responsible for processing the frame inserts an acknowledgement byte precisely into this gap. The sender can read this byte and knows that the frame has been delivered successfully.
The lower bits of the acknowledgement byte are always set to 0xA (can it be that it is "A" for "Acknowledgement", really?)
and the upper bits correspond to those of the receiving target: ACK = 0x0A | (DS & 0xF0).
This needs further investigation: on certain models or software versions, the acknowledgement byte
contains the identifier of the control unit (ACK = 0x1A) if DS was a network broadcast (DS=0x0F).
A typical boot sequence just for the control board and control panel starts like this:
LL DS CC CC MM MM MM MM RR RR ACK
0.412s 04 | 0f.e7-00 | 01 02 | a5 ec (crc=ok) | 0a (ack=ok)
0.412s 03 | 0f.e0-00 | 00 | 9a 0d (crc=ok) | 0a (ack=ok)
0.412s 04 | 1f.e8-00 | 01 02 | 75 58 (crc=ok) | 1a (ack=ok)
0.412s 04 | 1f.e0-01 | 01 02 | c7 ab (crc=ok) | 1a (ack=ok)
0.581s 04 | 0f.e7-00 | 02 02 | f0 bf (crc=ok) | 0a (ack=ok)
0.581s 04 | 1f.e8-00 | 02 02 | 20 0b (crc=ok) | 1a (ack=ok)
0.617s 02 | 0f.ef-ff | | df 25 (crc=ok) | 0a (ack=ok)
0.617s 03 | 13.15-00 | 00 | c6 3a (crc=ok) | 1a (ack=ok)
0.768s 04 | 0f.e7-00 | 32 03 | e5 0b (crc=ok) | 0a (ack=ok)
0.849s 04 | 26.17-01 | 25 25 | 33 fe (crc=ok) | 2a (ack=ok)
0.849s 03 | 22.13-01 | 0a | bc bc (crc=ok) | 2a (ack=ok)
0.849s 12 | 12.13-00 | 04 00 01 01 00 00 00 00 01 04 00 00 01 00 01 5a | e8 05 (crc=ok) | 1a (ack=ok)
1.028s 05 | 14.10-05 | 00 ff 01 | ce 43 (crc=ok) | 1a (ack=ok)
1.028s 03 | 14.10-04 | 04 | f0 a7 (crc=ok) | 1a (ack=ok)
1.028s 03 | 14.10-06 | 89 | d6 e0 (crc=ok) | 1a (ack=ok)
1.062s 03 | 14.10-08 | 00 | f5 4e (crc=ok) | 1a (ack=ok)
1.062s 05 | 14.10-07 | 40 00 01 | 3d 79 (crc=ok) | 1a (ack=ok)
1.100s 04 | 14.10-09 | 00 00 | 0e cb (crc=ok) | 1a (ack=ok)
1.634s 04 | 0f.e7-00 | 32 03 | e5 0b (crc=ok) | 0a (ack=ok)
1.832s 04 | 0f.e7-00 | 32 03 | e5 0b (crc=ok) | 0a (ack=ok)
1.912s 06 | 26.12-00 | 02 02 00 00 | 5d d4 (crc=ok) | 2a (ack=ok)
In the test setup, the motor controller was not connected, so you can see that
the control unit tries to communicate with it several times
in vain (request 0f.e7-00 32 03 with no matching 1f.e8-00 response).
A closer look at the frame data for the washing machine reveals the following meaning:
Washing machine WM14S750
DS CC CC MM MM MM
14.10-04 xx Temperature: xx = 0=>20°, 1=>30°, 2=>40°, 3=>50°, 4=>60°, 5=>70°, 6=>80°, 7=>90°
14.10-05 xx ff yy Washing program: yy_dec = 1 .. 15 (xx = ?)
14.10-06 xx Spinning speed, multiply xx by 10 to get rpm: xx_dec = 0, 40, 60, 80, 100, 120, 137
14.10-07 xx yy zz xx = FEATUREBITS1, yy = FEATUREBITS2, zz = 0 .. 2 VarioPerfect program number
14.10-08 00 ?
14.10-09 00 00 ?
15.11-00 01 Start button pressed on user control panel
26.10-20 xx Wash program module xx
26.11-01 xx yy Wash programm status: xx = 0=>Stopped, 1=>Running/end 2=>Running
26.12-00 xx yy zz Front door status: xx = 0=>Closed+Unlocked, 1=>Closed+Locked, 2=>Open
26.17-01 00 ff Wash program started by the washing control unit
2a.16-00 xx Remaining time xx in minutes
47.40-02 xx yy zz Request the unbalance sensor to send data for zz seconds (xx = node to which the response is to be sent, usually xx=17)
17.40-10 00 xh xl yh yl zh zl Response of the 3D unbalance sensor: x/y/z readings (3x signed int16)
FEATUREBITS1 = Logical OR of
0x02 = Water Plus / Wasser Plus
0x20 = Stains / Flecken
0x40 = ?
0x80 = Prewash / Vorwäsche
FEATUREBITS2 = Logical OR of
0x80 = Anti-crease protection / Knitterschutz
DESTINATION ("D" of DS-byte)
0x0 Network management / Broadcast
0x1 Washing control unit
0x2 User control panel
0x3 Motor controller
0x4 Unbalance sensor
SUBSYSTEM ("S" of DS-byte)
0x4 Set parameters
0x5 Start or stop processes
0x6 User info I
0xa User info II
0x7 Unbalance sensor communication
0xf Network management / Broadcast
Pure guesswork:
DS CC CC
0f.e7-00 xx yy Request dest yy to change operating state to xx
1f.e8-00 xx yy Response of dest yy that operating state has been changed to xx
0f.e0-00 xx Request dests to ping back if their operating state is >= xx
1f.e0-01 xx yy Response of dest yy that operating state is xx
0f.ef-ff End of initialization, changes operating states of all dests to 0x5
22.13-01 0a Read hardware/state/something info from user control panel request
12.13-00 Read hardware/state/something response
13.15-00 00 ?
With just an ESP8266, a piggyback 9V-to-5V-DC-DC converter and a few cables one easily can interface the D-Bus (lab setup only, not recommended to be installed in a real home appliance, see notes below).
❓ The ESP8266 GPIOs are 5V-tolerant, but unsure whether this is the best way to connect to the D-Bus or whether pull-up resistors or similar are missing. Please help if you have expertise in this area.
❓ Additionally, the ESP8266 is drawing too much power from the 9V VCC pin.
During the WiFi connection phase, current spikes of up to 430mA occur, which seems to exceed the maximum available current of the machine's power supply.
Adding a 470uF capacitor between the GND and VCC pin of the D1 and limiting the WiFi output power (output_power: 10.5dB) seems to be a dirty workaround, though not a reliable solution everyone should use.
Please help if you have expertise in this area.
bsh-dbus-logger.ino aims to fully interpret bus traffic including acknowledgements. It's work in progress, though.
bsh-dbus-wm14s750.yaml is a ESPHome config file to integrate the washing machine in Home Assistant:
It uses an external component called bshdbus. There is no documentation (yet) but you'll quickly get the idea on how to add your own sensors.
The old proof-of-concept code bsh-dbus-wm14s750-poc.yaml is preserved for debugging and archiving purposes.
Fortunately, people have started to create configuration files for devices they own. You can find them in the contrib directory. You are very welcome to add more devices, just open a pull request.
B/S/H/ type plates consist of a variety of different information. Of particular interest are the "E", "FD" and "Z" numbers as well as the serial number, which contain various (redundant) information.
"E", "FD" and "Z" are usually grouped in one block and look like this: E-Nr.: WAY32541FG/37 FD: 9504 Z-Nr. 200221.
Sometimes the letters and punctuation seem to be omitted, as here E-Nr.: WAY32541FG/37 9504 200221.
Serial numbers contain just digits and look like this: 485040275653002210.
With the above example, the numbers have the following meaning:
E-Nr. WAY32541FG/37
MMMMMMMMMM/RR Model M=WAY32541FG with hardware revision R=37
If you buy spare parts, you need to know the revision, as these may differ.
"E" stands for "Erzeugnis-Nummer" (produce number)
FD-Nr. 9504
YYMM Year = (YY + 20)%100, Month = MM, e.g. (95+20)%100=15, the device has been produced in April 2015
"FD" stands for "Fertigungs-Datum" (manufacturing date)
Z-Nr. 200221
LNNNNN
This number identifies the production line L=2 within the factory and
the sequence number N=221 of the device assembled on this line.
The serial number contains partially redundant information:
485040275653002210
FFYMMPPPPPPPNNNNNC
FF = Code for the factory where the device was assembled
Y = Manufacturing year (without decade)
MM = Manufacturing month
PPPPPPP = Manufacturer internal code, which contains information about the suppliers
NNNNN = Sequence number "N" of the device assembled (without production line "L" info)
C = Check digit for all preceding digits
The check digit "C" is calculated using the GTIN algorithm.
The information in this paragraph was compiled from various forum posts, there is no known primary source.
-
B/S/H/ has received several patents that mention the D-Bus:
- DE102009046706A1 describes a USB to CAN or D-Bus gateway.
- DE102009026752A1 describes a way to interact with the home appliance for remote customer service.
- DE102013205754A1 describes how to add a cryptography layer to the D-Bus (a kind of DRM to protect e.g. cooking recipes).
-
The eBUS (“energy bus” used by numerous heating systems) has similarities to the D-Bus. The eBUSd project is very mature, they even have designed a clever hardware adapter. The specification is well worth reading and helps a lot to understand the D-Bus, although the protocol differs in some aspects.
-
I don't own a WM14S750 washing machine, but only, let's call it, a lab setup.
-
If you think this is all weird stuff, you haven't seen the Zabex washing machine project.