B/S/H/ Home Appliances
Preamble
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 affiliated with B/S/H/.
No intellectual property of B/S/H/ was used at any time.
There has been a talk about the findings of this project at the 39C3.
A recording of the talk is available here.
Please do me a favor: :thumbsup: If you use any information or code you find here, please link back to this page.
:star: 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.
:smiley: You are welcome to open a discussion to report on your successful project and share it with others.
Warning
Household appliances work with high voltages and currents.
They generate heat and steam, they shake, vibrate and have rotating parts.
Parts can get wet or hot, move or fall off.
You should have an expert knowledge of electrics and take appropriate safety measures before opening or modifying such an appliance.
[!WARNING]
Even if parts of the appliances operate at low voltages, depending on your specific model they may or may not be isolated from earth.
This is a good chance of death or serious injury.
Under no circumstances should you connect external devices, such as your computer, directly to the appliance’s electronics.
[!WARNING]
I’m not responsible if you kill your cat, your spouse, your favourite pet fish, or yourself, whichever of these is the worst for you.
Everything in this project is distributed in the hope that it will be useful, but without any warranty or fitness for a particular purpose.
If you damage your appliance, or if your house is flooded or burns down, you do so entirely at your own risk.
You have been warned.
Hardware
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 control electronics of all home appliances are developed by BSH PED in Regensburg.
The site has worked for the automotive industry in the past, which explains why some components and approaches share similarities.
Washing machine Siemens WM14S750
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.
B/S/H/ has released a very nice video series in which many details from the production in Nauen can be seen.
Power module EPW66018
The power module (PCB front, PCB back) is based on a 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
User interface panel EPW66027
The user interface panel (Front view, back view) lets the user select 15 different washing programs, 8 temperatures, 7 spin speeds 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 user interface panel is connected to the power module via D-Bus.
Unbalance sensor SEUFFER 9000444823
This sensor detects unbalanced loads (PCB front, PCB back, Enclosure).
It uses a PIC18F24J10 MCU (28 pin QFN package)
and an A007MPL DREMAS IC (MPL likely refers to a custom-made Mask Programmable Logic),
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 power module 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.
D-Bus
According to the B/S/H/ patent documents, the electronics inside the appliance are
interconnected via a proprietary serial bus called D-Bus or D-Bus-2.
Since there are no public technical specifications available,
one can only speculate about what exactly D-Bus and D-Bus-2 are, and what the differences between the two might be.
The bus found on the “EP” circuit boards is a D-Bus-2 and consists of three wires: GND, VBUS and DATA.
VBUS is 9V for washing machines, 13.5V for dishwashers and 5V for extractor hoods. 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.
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.
The assignment of the connector depends on the end point: on the power module the connector is configured as GND-DATA-VBUS and then the cable is crossed and on the other side (e.g. for sensors) the wiring is VBUS-DATA-GND:
External access
At least in dishwashers, the D-Bus is accessible via PCB traces well hidden inside the power connector.
The power plug has special recesses that accommodate spring contacts
in a different cable configuration intended for service personnel,
allowing easy external access to the bus.
For certain refrigerators, an external communication module
was offered, which likely contains just a COM1 PCB.
History
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 user interface panel (in a rather simplistic way),
- 2006-2010 washing machines only use the D-Bus for the unbalance sensor and the user interface 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.
D-Bus adapter
To interface your own projects with the D-Bus, you need an MCU, for example an ESP32,
an open-drain level shifter, and a DC-DC voltage converter for the supply voltage.
Thankfully, several users have contributed their ideas
and are sharing their PCBs:
[!WARNING]
Please double check that you have read and followed the safety notes before connecting anything to a live device.
I repeat: It is not guaranteed that the D-Bus is isolated from earth.
Never connect the adapter to both the appliance and your computer at the same time.
If you have your own adapter design, I’ll be happy to link it in the list above, provided it meets
the minimum requirements.
Other home appliance types
The hardware of other home appliance types has been examined:
Protocol
D-Bus-2
Data is transmitted on D-Bus-2 using UART framing with an 8N1 configuration at a baud rate of 9600.
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 higher rates.
The D-Bus-2 is a (1-wire, the DATA wire) bus, not a conventional 2-wire serial link with separate RX and TX signals.
It operates as a multi-master bus in which all participants
are reading (and possibly writing) the bus simultaneously.
Bus arbitration appears to follow a non-persistent CSMA scheme.
This is by no means a complete description of the D-Bus-2 protocol, but rather a layman’s approach.
If you look at the comparable specification for other serial buses like 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.
For lower complexity nodes it is of little importance (e.g. the unbalance sensor ignores the value of the “S” nibble),
for higher complexity nodes (e.g. the power module) it separates logical sections within the program code.
Command frames
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.
For the DS.CC-CC tuples, there is only a very small, overarching defined set of commands (subsystem S=0).
All other commands and communication concepts depend heavily on the machine type (washing machine, dryer, etc.),
the respective model and the components used.
Other frame types
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.
Acknowledgement byte
When the destination node receives a unicast frame, it answers with an
acknowledgement byte right after the CRC, usually within less than 1 ms.
The high nibble is that of the destination (DS & 0xF0), the low nibble the status:
0xA for OK (can it be that it is “A” for “Acknowledgement”, really?), 0x7 for a CRC error and 0x3 for a frame that is too long or a full receive buffer
(only some firmware variants).
In practice almost every acknowledgement ends in 0xA: some firmware variants
never send 0x3, and some can switch negative acknowledgements off entirely.
Broadcast frames (DS & 0xF0 = 0x00) are not acknowledged by the receivers;
the sender acknowledges its own frame. Depending on the firmware variant, the
high nibble is the sender’s node id (e.g. 1a) or 0x0 (e.g. 0a in the
boot log below).
On a collision, a missing or a negative acknowledgement, the sender retransmits
the frame after a new random back-off. How often depends on the firmware
variant and the kind of error (typically 2 to 5 retransmissions, more on collisions).
Timing
Timing depends on the firmware variant. Typical values at 9600 baud
(one bit time is 104 µs, one byte with 8N1 framing 1.04 ms); variants that
support other baud rates scale them with the bit time:
- A gap of more than about 19 bit times (~2 ms) inside a frame discards it;
the next byte is taken as the length byte of a new frame.
- Before sending, a node waits until the bus has been idle for 10 bit times
plus a random 0 to 7 bit times (1.0 to 1.8 ms). Some variants widen the
random part after each collision (up to 127 bit times).
- The acknowledgement follows the CRC within about 0.9 ms; the sender waits
about 2 ms for it.
Because nodes may start sending before the 2 ms gap has passed, frames are
delimited by the length byte and the acknowledgement, not by gaps alone.
Implementations that lack access to exact timing information (such as the
ESPHome component) can therefore only approximate the
protocol. However, in practice, these approximations generally function quite reliably.
Boot log
A typical boot sequence just for the power module and user interface panel starts like this:
LL DS CC CC MM MM MM MM RR RR ACK
0.000s 04 | 0f.e7-00 | 01 02 | a5 ec (crc=ok) | 0a (ack=ok)
0.000s 03 | 0f.e0-00 | 00 | 9a 0d (crc=ok) | 0a (ack=ok)
0.000s 04 | 1f.e8-00 | 01 02 | 75 58 (crc=ok) | 1a (ack=ok)
0.000s 04 | 1f.e0-01 | 01 02 | c7 ab (crc=ok) | 1a (ack=ok)
0.169s 04 | 0f.e7-00 | 02 02 | f0 bf (crc=ok) | 0a (ack=ok)
0.169s 04 | 1f.e8-00 | 02 02 | 20 0b (crc=ok) | 1a (ack=ok)
0.205s 02 | 0f.ef-ff | | df 25 (crc=ok) | 0a (ack=ok)
0.205s 03 | 13.15-00 | 00 | c6 3a (crc=ok) | 1a (ack=ok)
0.356s 04 | 0f.e7-00 | 32 03 | e5 0b (crc=ok) | 0a (ack=ok)
0.437s 04 | 26.17-01 | 25 25 | 33 fe (crc=ok) | 2a (ack=ok)
0.437s 03 | 22.13-01 | 0a | bc bc (crc=ok) | 2a (ack=ok)
0.437s 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)
0.616s 05 | 14.10-05 | 00 ff 01 | ce 43 (crc=ok) | 1a (ack=ok)
0.616s 03 | 14.10-04 | 04 | f0 a7 (crc=ok) | 1a (ack=ok)
0.616s 03 | 14.10-06 | 89 | d6 e0 (crc=ok) | 1a (ack=ok)
0.650s 03 | 14.10-08 | 00 | f5 4e (crc=ok) | 1a (ack=ok)
0.650s 05 | 14.10-07 | 40 00 01 | 3d 79 (crc=ok) | 1a (ack=ok)
0.688s 04 | 14.10-09 | 00 00 | 0e cb (crc=ok) | 1a (ack=ok)
1.222s 04 | 0f.e7-00 | 32 03 | e5 0b (crc=ok) | 0a (ack=ok)
1.420s 04 | 0f.e7-00 | 32 03 | e5 0b (crc=ok) | 0a (ack=ok)
1.500s 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 power module tries to communicate with it several times
in vain (request 0f.e7-00 32 03 with no matching 1f.e8-00 response).
Interpreting frame data (WM14S750)
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 interface panel
26.10-20 xx Wash program module xx
26.11-01 xx yy Wash program 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) (physical location in brackets)
0x0 Broadcast
0x1 Washing control unit (power module)
0x2 User interface panel
0x3 Motor controller
0x4 Unbalance sensor
0xa Internet communication end point (power module)
0xb Internet WiFi connection module
SUBSYSTEM ("S" of DS-byte)
0x4 Set parameters
0x5 Start or stop processes
0x6 User info I
0x7 Unbalance sensor communication
0xa User info II
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 interface panel request
12.13-00 Read hardware/state/something response
13.15-00 00 ?
Software
Using a D-Bus adapter, you can connect to the bus and interface it with your own software.
Arduino
Open-DBus2 is an initial approach for a D-Bus-2 stack implementation.
It parses D-Bus traffic, acknowledges frames for locally registered nodes and
routes commands to corresponding handler functions.
bsh-dbus-logger.ino is an earlier approach for interpreting bus traffic.
It includes a rather messy “fire-and-forget” method for writing to the D-Bus,
which is sometimes all you need for a quick test.
Linux
bsh-dbus-logger.pl is an older approach to interpret D-Bus traffic.
Web
The bsh-dbus-analyzer.html is a convenient tool designed for quick
D-Bus hex dump analysis. It is a client-side application that runs fully in the browser and
can be accessed directly through this link.
Home Assistant / ESPHome
bsh-dbus-wm14s750.yaml is an 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.
Other home appliance models
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.
Firmware analysis
Basics
Some components are shipped without readout protection and with debug interface exposed,
making them well suited for static and dynamic firmware analysis.
With your favourite RE tool one can find arrays of structs defining
the subsystems compiled into the specific version of the device firmware.
For example, these structures can be identified for the dishwasher firmware:
struct dbus_subsystem {
byte subsystemid; /* S */
struct dbus_cmdin * p_s_cmdin; /* array of incoming cmds */
struct dbus_cmdout * p_s_cmdout; /* array of outgoing cmds */
byte * p_b_numcmdout; /* size of cmdout array */
pointer p_sramunknown; /* likely state byte */
};
The subsystem definition refers to more detailed arrays of incoming and outgoing
commands defined for this subsystem:
struct dbus_cmdin {
byte eolist; /* byte & 0x80 != 0 => end of list */
byte unknown;
word cccc;
pointer p_f_cmdin_handle; /* int f_cmdin_handle(int len, byte* buf) */
};
struct dbus_cmdout {
byte unknown;
byte ds;
word cccc;
byte len;
pointer p_f_fillbuf; /* int f_fillbuf(int len, byte* buf) */
pointer p_f_unknown; /* mostly no-op */
};
The best way to initially locate these structures is to search the firmware binary
for known cmdout DS.CC-CC byte sequences (little endian).
By iterating through the arrays, one can list all subsystems
with all corresponding incoming and outgoing CC-CC commands.
The intended action of the respective commands can be determined by analyzing the linked functions.
Some arrays are located in SRAM, as the firmware dynamically patches
the definitions according to its specific runtime requirements.
Subsystem S=0
The subsystem S=0 appears to be the same for all devices and allows, among other things,
the memory content to be read out, which is a convenient way of
dumping the firmware (flash) and RAM content via D-Bus:
DS.CC-CC
_0.f0-00 xx yy zz zz Request dest to dump yy bytes of memory starting at address zz (16 bit)
_0.f0-01 xx yy zz zz zz zz Request dest to dump yy bytes of memory starting at address zz (32 bit)
(xx = node to which the response is to be sent)
_0.f1-00 xx yy zz[] Response of node xx with yy bytes of memory data zz (16 bit)
_0.f1-01 xx yy zz[] Response of node xx with yy bytes of memory data zz (32 bit)
The subsystem offers some more commands which have not been analyzed yet.
Serial numbers
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.
Misc
评论