Cloudwash is our take on what a connected washing machine should do. But we knew that, to understand and design for this type of device, we needed to have a working technical prototype in-front of us, so we could experiment and experience.
So before creating the Design Prototype, we set out to make a Technical Prototype of adding connectivity to a washing machine. When we started we didn’t know exactly what intervention we would make in the real machine. We thought there might be three approaches:
- To modify and control the main sensor/actuator board in a washing machine, by removing the microcontroller on the board for example and interfacing directly to the rest of the circuitry – the relays, TRIACs, sensors etc.
- To use a machine that used a main board with a connection for external communications (either for a separate controls/display board or for remote diagnostics). If we could work out the communication protocol being used, we could then control the machine through this protocol with a microcontroller.
- To ‘hack’ the buttons, dials and LEDs on the board behind the physical interface of a machine, by using a microcontroller to control relays to fake button pushes and to sense whether voltage was on or off at the LEDs to detect state changes, for example.
Approach 1. seemed quite high risk and the most complicated, albeit with the potential to offer the greatest control of the machine. Approach 3. seemed limited and too ‘hacky’. Approach 2. seemed the cleanest solution, involving only a minor physical intervention, and offered the potential for a good degree of control of the machine. It also meant the majority of the work would be in code (which is easier to iterate over) and that no physical modifications would be needed to the electronics of the machine (meaning we were less likely to damage the mechanics or electronics of the machine or make it unreliable or hazardous in any way).
Approach 2. also felt like the most likely place a manufacturer would make a change to the electronic design within a washing machine if connectivity was added – they would be less likely to change the main board but rather the controls/display board and just extend the protocol between the two boards to include messages relating to the new functionality brought by connectivity. The most that might be needed at the main board would be a firmware upgrade. Most manufacturers already use this approach when creating a range of different washing machines – the main board is the same in each machine and only the controls/display board is adapted to offer a number of board variants for different machines with different user interfaces. For example, some have more buttons and dials to adjust more features on the machine or they might have a display to show wash times.
Having tentatively chosen Approach 2. we selected a suitable machine. One that was low to mid range, had a separate main board and controls/display board, and that also had a fairly basic physical user interface, and thus potentially a simpler or less extensive communication protocol to work out.
We then searched the web and found whatever user and service manuals, external and internal photos and video clips we could for the chosen machine, to gather as much technical detail as possible. General arrangement of components, system descriptions, wash programme data, circuit diagrams etc.
Next we pieced together a rough idea of how the overall electronic system worked within the machine. There was a main board – with sensors and actuators to control the electromechanical parts of the machine such as valves, pump, motor, heating element, pressure switches, temperature thermistor, tachometer and door interlock – and a controls/display board – with a physical user interface made up of controls such as a dial, buttons and LEDs. Each board had a microcontroller, and these talked to each other via serial communication.
Feeling confident we understood our chosen machine fairly well, and with a preferred approach for controlling it, we went out and bought a couple of machines – always good to have spare parts! Once they had arrived we disassembled the upper part of one of the machines to expose the boards and confirm the layout of the components and the general electronic system used.
The next task was to identify the wiring arrangement between the main board and the controls/display board. We used a multimeter to find the grounds on the edge connector of each board. Then using these grounds as a physical reference point we compared against the circuit diagram in the service manual to figure out the connector pin-outs and thus the wiring arrangement between the boards. The relevant wiring was a group of three wires – 5V, Ground and a shared TX/RX (serial transmit and receive).
Now we had the wiring worked out we needed to find the hardware layer of the communication protocol between the two boards. To find this we used a logic analyser to ‘sniff’ the communications being transmitted between the boards, by clipping probes to the connector pins on one of the boards. The logic analyser allowed us to view and record the signals being transmitted between the boards in real-time as we operated the machine. The software for our logic analyser is able to interpret the signals into data – for example, as decimal numbers such as 66, 69, 82, 71 or as ASCII characters such as ‘B’, ’E’, ’R’, ’G’. To do this it must know the type and properties of the hardware protocol you want it to try to match against – CAN, I2C, Asynchronous Serial, SPI etc. By experimenting with different software settings we were able to find the correct protocol – when we started to see intelligible data, we knew we’d found the right one! We discovered the protocol was Asynchronous Serial at 9600 bits-per-second (baudrate), 8 bits per transfer, 1 stop bit, even parity, LSB (least significant bit first) and inverted.
At this point we were doing pretty well and were feeling confident that our approach might actually work out (although we still had to understand enough about the messaging protocol to be able to read and control the machine).
So we moved on to trying to understand this protocol, or at least enough of it to start playing around with the machine. To do this we needed to start recording the data being sent between the two boards and look for patterns in the communication. We had to move beyond the logic analyser that had got us this far and on to a method for capturing the data and logging it back to a computer. The best job for this was a microcontroller. We chose the Arduino platform as it is a microcontroller board we know and love and also works great with our Devshield (which would be needed once we start to add connectivity). We used an Arduino Mega as it has four hardware UARTs for serial communication – we used one for serial-USB communication to a computer for logging and two more to communicate with the two boards inside the washing machine. We needed a few additional components and connectors to interface the Arduino to the washing machine boards, so to make the electronics more robust we moved off of a breadboard and made a small PCB that plugged onto the end of the Arduino.
We now had a way for the Arduino to listen to the communication from both of the washing machine boards and relay everything it heard from one board out to the opposite board. This kept the boards happily talking away (as far as the boards knew they were talking directly to each other over the wires), allowing us to continue to operate the machine fully. But as well as relay the communication from and to the boards the Arduino could also send everything it heard out of its serial-USB port to a computer. The blocks of data were sent as comma separated values so we could save the serial monitor output on the computer as CSV files and open them directly into something like Excel to pore over.
After studying the log files for a while we saw that messages from the main board always started with 201, 42, 33 and that messages from the controls/display board started with 201, 33, 42. These first bytes were then followed by three bytes that described the message type, which in turn were followed by a variable number of bytes that described data for that message – for example it might list the temperature, spin speed, delay and so on if the message was about the wash programme dial changing. Each message ended in a single byte that was the exclusive or (XOR) of all the preceding bytes. This is an example of a simple checksum for detecting errors that may have been introduced during the transmission or storage of the message.
We didn’t understand all of the codes for the different message types, but all we really needed was to identify those that were sent when actions happened that we were interested in – such as the programme dial being changed, the start button being pressed or the wash programme ending. So we singled out the messages that related to a set of actions we wanted to know about and stored the relevant bytes that identified each message type in the memory of the Arduino (EEPROM). The Arduino could then use this block of memory as a lookup table each time a message was received from one of the boards or when a command from the Berg service arrived, to either respond to an action or make the machine do something.
At this point we were able to read and control a reasonable amount of the machine’s operation, to the same kind of degree as the machine’s own physical interface. So we moved on to adding connectivity to the Internet! This is where the Berg cloud services and prototyping hardware accelerated things massively. Using the Devshield and Arduino client library, in a short time we were able to start sending events up to the cloud in response to actions happening on the machine, or receive commands down from the cloud to make the machine do things.
We made a simple web service to capture and store the events coming from the washing machine, and to send commands down to it. This web service was built with Node, Sails (a simple MVC framework), and a MySQL database. The database held a virtual representation of the machine’s state, which was updated every time an action happened on the machine and consequently a Berg event was received by the web service. The virtual state of the machine could in turn be retrieved from the web service at any time by some other application (a web app, desktop app, iOS app).
In our case, this was an iOS app that displayed various properties of the washing machine, such as it’s current programme setting, the wash temperature and spin speed, whether various washing options like ‘spin reduction’, ‘rinse hold’ and ‘extra rinse’ were on or off, and the number of hours it would delay before the wash. The app also showed the stage a wash programme had reached (delaying, washing, finished etc.) and a start time, estimated end time and a progress bar. All of this updated almost immediately each time something happened on the real washing machine. The app also had a button to start and pause/unpause the wash. The web service and database also managed multiple machines and registered iOS devices that had installed the app so that they could receive push notifications, for example when a wash had finished.
To complete the physical modification to the washing machine we made a clear plastic box to contain the Arduino, Devshield and our custom PCB, and mounted this within the top panel of the machine.
I’ll wrap up with something that happened just after we hooked up the washing machine to Berg. It only took an hour or two. We made it so we’d get an iPhone push notification when a wash finished.
And the wash finished. And the push notification came through. And at that moment, it was clear: This is a feature I want!
Let’s recap what made that possible. The main board in the washing machine sent out a message to say that the wash was done. Our Arduino was listening and heard that message. It passed it on to the controls/display board. But it also sent an event up to the Berg service. Berg sent that on to the Node web service which updated the virtual state of the machine in the database and at the same time posted a message to the Apple Push Notification Service (APNs) which in turn sent a push notification to the iPhone.
To do the push notification, we didn’t need to know all the details of how Apple’s servers worked. They just got the notification to where we wanted it. And like the APNs, the Berg service made a whole chunk of the Technical Prototype just work!