Make That Special Cup Of Coffee By Completely Tweaking The Coffee Machine

An interesting part of working on the Building Management and Control (BMaC) project – as previously covered on this site – was the reverse-engineering and ultimately the gaining of full control over the coffee machines at the office. Not the boring filter coffee machines, mind you, but the fully automatic espresso machine type that grinds beans, makes coffee, adds milk, and much more. Depending on one’s budget, naturally.

These little marvels of engineering contain meters of tubing, dozens of sensors, valves, ceramic grinders, and heating elements. The complexity of this machinery made us think that maybe there was more that we could do with these machines beyond what their existing programming and predefined products would allow. Naturally, there was.

Meet the TOP-tronic Hardware

The espresso machines at the office are all from Jura, a Swiss company. Specifically we had the Impressa XS90 and an older version of it, along with an X3 and XJ9. Initially we were just interested in reading out the counters in its EEPROM that gave us this overview of our colleagues’ coffee use:

Believe it or not, these counters could be read out over TTL-level serial port on the back of these machines, a serial port on which the internal microcontroller speaks a simple binary protocol. A similar project, covered by Hackaday a few years ago, featured similar functionality in terms of reading out these coffee usage counters.

The protocol is essentially plain ASCII commands and responses, with each byte turned into four bytes. Only bits 2 and 5 of carry data from the original byte, and the rest of the carrier bytes are 1s except for bit 0. This encoding and matching decode routine were implemented in the BMaC project’s ‘Jura‘ and ‘JuraTerm‘ firmware modules.

Inside these machines, you’ll find a controller board made by TOP-tronics. Most of them feature what we have come to call the ‘generation 5’ type of boards, since the triple-digit model number starts with a ‘5’ for those boards. They all feature a simple processor and have their programming inside a section of masked ROM, meaning that they do not support firmware updates, but only allow for small configuration changes in an EEPROM on the same PCB. Product counters are also stored in this EEPROM.

All of these boards communicate via their serial ports, presumably using the same padded serial protocol to receive instructions from the small LED or LCD-based front-panel interface PCB. The XS9, XS90, and XJ9 all have similar generation-5 hardware inside, but the XJ9 is the only one which has the color TFT LCD and much larger product selection out of these three. The X3 and its siblings (X3c, W3), on the other hand, feature ‘generation 7’ hardware. And instead of the masked ROM and simple microprocessor, they have an ARM MCU (STM32F103ZE) and no longer use the EEPROM (93LC86) to record counters. Attempts to use the simple ‘TOP-tronics’ protocol to read the EEPROM results in the machine returning rows of zeroes. These machines also feature a Bluetooth dongle which plugs into the user-accessible third UART (‘extension port’) so that it can be used with the Jura app on smartphone or tablet.

With our X3 machine mostly unresponsive to the usual protocol and commands, we decided to sniff the UART lines between this dongle and the machine while operating the app on a tablet, electing to use the first UART (‘service port’) because it has a chunky DE-9 (RS-232C-style) D-subminiature connector and creating an adapter was much easier. Functionally both UARTs are identical as far as we could determine.

Unfortunately the first sniffing attempts already showed why we were having such a hard time communicating with the machine: instead of sticking with the plain-text protocol, the dongle and machine performed what appeared to be a handshake using the old protocol before switching over to an encrypted connection.

Similarly, the Bluetooth connection between the dongle and tablet-based app seems to be fully encrypted as well. Initial attempts at reverse-engineering, decrypting, or even simple replay attacks proved to be fruitless and we had to give up on this machine for the time being. We didn’t want to break thousands of Euros worth of machinery and a crucial part of the office’s (coffee) infrastructure, so we were kind of stuck when it came to these newer machines.

Making the Machine Dance for Us

That left three machines that we could communicate with. When my employer organized a hackathon event, that was the perfect time to see what we could do with them. We started off connecting them to the local WiFi network. These little black boxes contain an ESP8266 and a level shifter, running the BMaC firmware containing the two Jura modules which I referred to earlier in this article.

While looking through the list of possible commands, it became clear that with it one can address every single part of the machinery that is involved in making the final product, from the grinders to the valves to the entire brewing groups. Instead of using the ‘make product X’ commands that read the product presets from the ROM, we could instead send our own string of commands to the machine to make our own, custom product.

The machine is essentially a series of pre-heaters (d), heaters (e), pumps (c), flow sensors (b), valves (f, i), all serving the brewing unit (g), which is the core of the machine. This is where the grinder (not pictured) after grinding a certain amount of coffee beans drops the powder into, which is then flooded with the hot water from the valves and heating elements. Depending on the type of product one can also use steam during the brewing, and add milk from an external unit if so desired to the final product. The fun question was in which order one was supposed to use them, and for how long. Figuring this out was the goal of this one day long hackathon.

The Struggle, and Kilograms of Beans

With no real guidance beyond a vague idea of how all of these parts of an automatic coffee machine were supposed to work together, we started off with the assumption that we’d need to grind some beans for a few seconds or so, then add hot water and wait for the fresh coffee to appear in the mug we had put underneath the output side in anticipation. Unfortunately that just got us some hot water in the mug and dry coffee grounds in the waste water container. Clearly something had gone terribly wrong. Going back to the drawing board, we began to carefully attempt various approaches and series of commands.

By the end of that day, we had worked our way through two kilogram bags of fresh beans, managing to produce something that appeared to be at least at first whiff to be coffee, so we first had those in the team who drank coffee try it until they started rebelling and we had to get people from the other teams to try our creations when they popped by to see what in the world was happening in this one room that smelled very strongly of coffee for some odd reason.

In the end we figured out that the right sequence of events for the XS90 was:

  1. Grind coffee (1 second).
  2. Move the brewing unit into the brewing position.
  3. Heat water (2 seconds).
  4. Pump hot water into the brewing unit (>10 seconds).
  5. Drain the coffee.
  6. Flush the brewing unit with fresh water.
  7. Discard the used coffee grounds.
  8. Move the brewing group back into the grinding position.
  9. Close the drain valve.

This sequence allowed us to produce something that reasonably approximated what someone might call ‘decent coffee’, according to my colleagues who do drink coffee. There were still many details we had to figure out to perfect things, but we felt that we had come tantalizingly close to doing so. Not surprisingly, our team won that hackathon.

The Aftermath

Frustratingly, the list of TOP-tronic commands we had started with turned out to be incomplete. At some point, one of my colleagues figured that they should try unlisted commands that were in sequence, just to see what the machine would do. We had the whole machine screwed open, so we could get a good view of its internals.

Here one can see the serial cable plugged into the logic board of the machine with most of the tubing, pump, and some of the valves visible. This usually worked fine, allowing us to deduce what worked and what didn’t, barring one incident involving a command that apparently set the multi-valve into a wrong state, so that the coffee would come out on the right output instead of the left one.

Since the hackathon, we haven’t had time to convert this proof of concept into a full-blown product that would allow us to command the coffee machines to produce the exact coffee or espresso we desire, much less calibrate the amount of fluid added to the nearest millilitre. This is definitely something that should be done, though.

A somewhat unpleasant note here is that apparently Jura and TOP-tronic have decided to move away from an easily used protocol as that found on the generation 5 boards. At some point I even toyed with the thought of replacing the TOP-tronic board in the X3 and other machines with generation 7 hardware, using a custom ARM-based board that would simply drive the components according to the input obtained via a WiFi or Ethernet link.

Unfortunately, that would mean decisively voiding the warranty, which is the last thing which one would wish to do with a coffee machine that costs more than a used car. Still, the hacking potential with these automatic coffee machines seems to be almost infinite. If you can get your hands on a (used) XS90 or XS9, it could make for a whole lot of fun, and possibly even the best coffee in your life.

29 thoughts on “Make That Special Cup Of Coffee By Completely Tweaking The Coffee Machine

  1. Interesting. I have an Impressa C5 at home. It has worked great for the last 5 years or so. I think that it might be time to do some sniffing and reverse engineering. I just can’t break it or the wife would be pissed.

  2. “””Unfortunately the first sniffing attempts already showed why we were having such a hard time communicating with the machine: instead of sticking with the plain-text protocol, the dongle and machine performed what appeared to be a handshake using the old protocol before switching over to an encrypted connection.”””

    Sadly thanks to all the “cyber security” efforts caused by people “hacking” the most mundane of IoT devices, this is the future for the tinkerer. Being locked out of everything unless you have their app. Which wil be cloud based and turned off after a couple of years so your hardware will be worthless.

    1. And when all that bricked hardware becomes available, you’ll be able to pick it up for a song and dance.

      Or maybe even create a secondary market with a solution that makes it usable again.

  3. The encryption might be breakable by disassembling/decompiling the smartphone app (my goodness, an app for a coffee machine…). If it has not been obfuscated you will get quite readable Java-code. With a lot of luck you will find the static key in the code. Please consult a laywer for legal nonsense before doing anything…

    1. I did disassemble the app, yes. Unfortunately it had been heavily obfuscated, with all original variable and function names gone. Getting into the Java keystore section of the app also proved to be rather hard.

      Maybe another day, though :)

      I’m also pretty sure that the BT dongle decrypts and encrypts commands, as there are some commands for this dongle that it has to deal with. It uses the Bluefrog IC, which I sadly couldn’t find much information on, but it’s supposed to have a USB interface hidden in there somewhere :)

  4. Full transparency: I used to work as a repair tech for DeLonghi, so I may be a LITTLE biased.
    Still, I worked on a heck of a lot of their machines, and the number one problem with all bean-to-cup automatics was “It just doesn’t make good coffee!”
    Eventually, you learn that say, Italians (the manufacturers) have a very different idea about what “Good coffee” is than Australians.
    Australians thinking coffee isn’t good coffee if it’s not on the verge of vaporizing should it even get a fraction of a degree hotter.
    With this in mind, a lot of my job was “Training” machines to make desirable coffees, good or not.
    It was a necessity that I started drinking coffee myself, and understood implicitly just by talking to the customer what they actually meant when they said “Good coffee”
    In the end, I decided to shop around for machines for my own use, and ended up settling on a DeLonghi. (The XJ9 was tempting, but Jura’s aren’t exactly that service friendly).
    Anyway, over time I tried tuning the machine further and further to make better coffee, but in the end you’re limited both by the firmware on the board (which is mostly self correcting, and doing a good enough job for 80% of people while never totally pleasing anyone. It’s not BAD coffee, it’s just not great), but aside from the firmware, the hardware itself is somewhat limited in precision.
    I ended up creating a small dummy board that more or less just had MOSFETs switching the components like in the original, but hooked up to an AVR to allow for manual control. I then had this plugged into an orange Pi Zero, simply because it was nice and embeddable + had wifi (back before I’d given in entirely to the gods of ESP), and used software on there to chat to the AVR on serial through very basic commands. Just “do (this), do (this), do (this) until (this) tick (30) times, then stop, do (this)” etc and I was able to get a much finer tuned coffee, not only because I was entering parameters myself but because the hardware I was using was vastly more accurate than what you get in even $5k+ commercial machines. Eventually I was swapping out the pump, flow meters, adding extra sensors and all that fun stuff until it was able to make a coffee as good as me walking up to a La Marzocco and doing it myself.
    Soon after I left the job, moved states, but my coffee machine has been sitting in storage ever since.
    Funny thing is, I don’t really like coffee.

      1. Sadly everything I did was machine specific, at least close enough. While all delonghi’s work the same way, certain parameters need to be entered, yada yada, and if they’re wrong you end up burning your house down. Not exactly something I’d like to leave up to the customer.
        I could sell them on a per-model basis, preprogrammed to that machine’s config, but I’d much rather just charge $1k to do it myself, then I can actaly cover the liabilities.
        If it was my passion, sure, but for the better part this was just a job to me.
        (I’ll tell you what, though: They’re a hell of a lot simpler to hack than this article makes it seem if you’re happy to just rip out all the control electronics and do it from scratch. Just make sure you run the machine and watch it first, so you know what it’s doing before you start trying to hack it. Saves a hell of a lot of reverse engineering)

        1. Even though I have never messed up with a coffee machine, I can’t agree more with your last part., re-building electronics is almost always easier than reverse-engineering it. I’ve “resurrected” two dead washing machines last year: the logic board was dead so I simply threw them away and used Arduino + Relay modules instead, both are still working wonderfully well!

    1. Oh, it got WiFi? Did you implement the RFC 7168 (The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)) to make coffee? It got support from emacs CoffeeMode. :-)

  5. it’s quite a bit more complicated inside the Jura than my Mr Coffee. Should I upgrade? I dunno. seems like if I put enough medium grind in the thing the right kind of inky black caffeine-juice comes out of it.

    But seriously, very cool tear down and reverse engineering of the thing. It’s amazing how much like an assembly line control platform these fancy machines are.

  6. Ah, so the data is encrypted, bummer..
    We have a D60 at work which really is an annoying one-button-does-all hipster machine and it does the same encryption step which I didn’t get around to try and make any sense of it (I spent €50,- on a shitty BT dongle with its only special feature is initiating a handshake).

    Have you checked whether there is a packet of semi-readable bytes that might be something of a key exchange?
    I can’t imagine that it would have a heavy encryption; maybe even something simple like XOR.

    To be honest, I stopped modding it after I simulate the buttons (press, rotate) over serial with some arbitrary timing and hooking a RC522 card reader to an arduino (complete with fragile dupont cables and a cheesy plastic case pulled out of the bin and decorated with a sticky note) so everyone can use his work badge to get their desired strengt and volume of coffee (I hate turning the knob at the machine’s request for every step of the brew process.

    1. Unfortunately I didn’t have a lot of time with the X3 machine, and haven’t had access to it or a machine like it for the past years. I’d love the challenge of trying to crack the encryption, however. I don’t think that it’ll be something as simple as XOR. They seemed to use actual certificates and the like. Maybe they still took a few shortcuts that could be abused, however :)

  7. On my Saeco the sequence is the following:
    – check sensors, start heating
    – move brewing group to load position
    – grind beans
    – move brewing group to coffee position
    – open valve and engage pump ~1s, stop pump 1-2s, engage again for x seconds
    – move brewing group to dump (resting) position

    The interesting bit is the preloading of the steam (or how would you call it). I think it’s meant to ensure a smooth bubble-free flow or avoid some kind of pressure kickback. I don’t have the terminology to explain it.

    There is a lot of sensor reading in-between phases: whether any access door is opened, whether waste water is full, whether there is enough fresh water, whether the pump has flow (including while under pressure), temperature, whether the grinding motor spins too fast, whether the BG is in the right position, etc.

    I wish the Saeco protocol would be available, I have not been able to interface with it in any way.

    1. The delay in the pump time at the start of the brew cycle is to allow the dry coffeee grind to absorb the water and start to transfer the goodness. Yes if it’s shortened you can get pops and splurges of coffee but it’s primarily a means to extract more from the beans.

    1. So in an office Environment the coffee orders for a meeting can be taken in the App, and then when the person getting the coffee can get the coffee’s from the machine by pressing the orders in the list.

      yeah you can take a note but this makes it easier for people that want a stronger coffee.

      Just put a cup under the machine press the order on the phone and coffee

      The bluetooth dongle is like 50 Euro’s for a machine that’s 6k It’s a cheap option

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.