Coffee machine v2

Automatic Slow Coffee Machine | home information device | music player

Similar projects worth following
Primary design goal:
- Making the best 'slow coffee' in the world (by slow coffee I mean, this bla bla special filter bags special coffee pot bla bla design stuff) - automatically! And in the mean time developing AutoBaristaScript(TM) extensible scripting language.

Secondary design goals:
- Coffee statistics!
- ISP programming of an Atmel microcontroller "without hands" by the Raspberry Pi
- Increasing the amount of coffee powder put /in/ the filter bag from 85% (v1) to >98% (v2)
- "Ah, crap, [today | yesterday] was time for [paper | kitchen waste | plastic] to put outside, now we have to wait another three weeks!"
- "Can I wait for the [train | bus] for a few minutes because it has some delay?"
- "I really like to [listen to music | watch tv] while [cooking | doing the dishes]."
- Hacking a 2016 alternative to HTCPCP which is fundamentally flawed (ever wondered how much coffee an HTCPCP-request brews?)

This coffee machine is by now up and running for about 1.5 years. I started documenting and open sourcing everything offline; this month's Hackaday Prize was the motive to speed things up a bit and put it online. Project logs will follow...

In the project logs, the following is discussed:

1. RonaldBoard; ISP programming and I2C combined
2. Hardware design / Salvaged hardware (+Saeco vs Senseo / service manual) + Initial design
3. Software part 1 - UX Extensions
4. Software part 2 - Core coffee software + AutoBaristaScripting(TM)
5. Telegram-interface


Example source for RonaldBoard (GPLv2)

gzip - 6.11 kB - 07/14/2016 at 14:01


View file

  • 1 × Raspberry Pi Model B, IIRC :)
  • 1 × Atmega8 Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × Water tank + sensor, boiler + sensor Parts of a Senseo
  • 1 × High power board, coffee grinder Parts of a Saeco Talea / Odeo
  • 1 × Vintage UI elements from Prague thrift store
  • 1 × Bus rear light from my grandfather
  • 1 × The amplifier-part cut off of a 1980's car radio
  • 1 × Portable DVD player (for the LCD)

  • A 2016 alternative to HTCPCP [updated video]

    Ronald08/15/2016 at 18:44 0 comments

    As said before, HTCPCP is fundamentally flawed. In two ways: (1) there is no way the amount of coffee can be controlled, (2) it assumes a teapot cannot brew cofee.

    It's time for a new HTPCP-like protocol that solves both of these problems. Things that need to be supported:

    1. Brewing coffee
    2. Small talk while deciding if one wants coffee
    3. Making sure nobody ever believes tea pots cannot make coffee
    4. At least some control over who is allowed to brew coffee.

    As data carrier, pigeons were considered. However, no quality trained pigeons were available, so Telegram was picked. Telegram has a nice bot api. Further, some nice people wrote a Python library for communicating. This solves requirement 4, and eases the development of code for 1-3.

    The core telegram bot communication code can be found in and may be a useful example to others. The code for implementing requirements 2-3 is also in this file.

    The has been updated to react to telegram, and to be a little more verbose over telegram, too.


    As for the protocol, current computers and even the Raspberry Pi have enough processing power to do some amount of written language recognition. Supported commands:

    • 'hi' or 'hello': start smalltalk
    • some sentence containing 'tea': tell that shamefully we cannot provide tea
    • some sentence containing 'one cup of coffee': brew 1 cup
    • some sentence containing 'two cups of coffee': brew 2 cups
    • shortcut: if it's really early in the morning and coffee is urgently required with lack of proper verbalisation skills, the word 'coffee' provides for 1 cup of coffee

    Brewing more than 3 cups over telegram is not allowed (yet) since no phyisical checks are being made before brewing starts. Read: it can get a big mess, and for <=2 cups this is considered an acceptable risk.

    Video is updated, as well as the source on Github.

  • Software part 2 - the coffee parts

    Ronald08/11/2016 at 14:46 0 comments

    Video is online! Click here to see the machine in it's full glory.

    Arguably the most important feature of a coffee machine is its ability to brew coffee. Thankfully, this machine is actually capable of brewing coffee. Earlier I described the used hardware, in this part I will describe the software.

    An advantage of a microcontroller-controlled coffee machine, is that a lot of finetuning of the brewing process is possible. An advantage of an internet-connected coffee machine, is that a lot of statistics can be tracked. For that most exciting part, check http://koffie.ronaldteune.nlAutoBaristaScript (TM)

    The brewing code is in the module (excuse my Dutch - I tried to at least make it readable with comments). For every number on the quantity dial (1-5), a script is defined:

    ['Z8','M135','Z16','S60','Z120'] for 1 cup of coffee. This means:

    • Give water (Z) for 8/4 = 2 seconds. Due to the control logic, this water is cold. For filter coffee, it's best to first wet the filter. This way, we can spare us the huge effort of doing it by hand.
    • Grind (M) 135 half rotations of the grinder.
    • Give hot water (Z) for 16/4 = 4 seconds.
    • Sleep for 60/4 = 15 seconds. I forgot the fancy 'slow coffee' name for this, but this waiting time after a small bit of water significantly improves the taste of the coffee compared to instantly letting more water pass through the filter.
    • Give the bulk of hot water.

    The amounts of coffee and water is finetuned for this machine and the beans we currently use. Should we choose to switch beans often, new scripts can easily be created and loaded into the machine.

    The temperature measurement comes from the HAL in a scale close to degrees celcius. Measurement is done by an NTC / constant R voltage divider connected to an ADC input of the Atmega daughterboard. I did not calibrate it exactly, but it's close enough. Some trial & error helped in getting the good coffee output temperature.

    The script may be extended with a temperature control setting, e.g. to give perfect water for black tea, green tea and coffee. Currently however, a teakettle is still doing a wonderful job for this.

    Grinding & brewing process

    Both the grinder and the flow meter have two little magnets and a hall sensor. A call back function in the HAL registers the amount of half rotations; the brewing routine waits for the grinding to complete.

    The flow meter has recently been installed, but currently the amount of water is still time-based. The clock ticks at 4 Hz (=4 FPS).

    More cups of coffee don't mean a linear increase of coffee powder; the amount of powder per cup slightly decreases.

    One thing that needs improving is that the Senseo has a three-way-valve that 'spits' hot water back into the water tank when not pumping. This makes both the time-based and the flow-meter-based measurement inaccurate, so the exact amount of coffee is always a surprise. I think I can remove the three-way-valve since my output setup is totally different from the pad-based machine, but I need to investigate it more.

    The temperature control is a simple hysteresis based control, with the addition that it tries to leave the boiler at less than 'totally hot' at the end, so the last 2 seconds the water may be colder than in the rest of the cycle. The advantage of this is that the first 2 seconds that are used for wetting the filter can be done by cold water (which means: don't wait for heating up).

    The heater starts after grinding the coffee. The advantage is that while grinding, the water tank can be filled without the three-way-valve spitting hot water over the kitchen floor.

  • Software part 1 - the non-coffee bit

    Ronald08/11/2016 at 11:26 0 comments

    The source code of both the software (python) and firmware (atmega, c) can be found on github. It autodetects architecture and can be run on a desktop computer. To make full use of it; an MPD client has to be installed (music), an NS-API token has to be available (train info), and a Dutch postal code + house number combination has to be set (waste collection info). Of course all of this is only neccesary for the home information part, not for making coffee...

    The UI will work well enough without all of this. The code has been written to make sure the UI continues to work at most times, catching and mostly ignoring exceptions - because otherwise it's hard to turn the coffee machine off without SSH.

    Main, to which koffieui is a symlink, holds everything together. It loads the different modules:

    • System menu (SysD)
    • Train time table display (NSDisplay)
    • Music player control panel (MPDisplay)
    • Last but not least... the coffee maker interface (Koffiezetter)

    In this log I will explain the first three of these.

    Read more »

  • Hardware

    Ronald07/28/2016 at 19:29 0 comments

    Block diagram

    Numbers are Raspberry Pi GPIO numbers.

    Read more »

  • RonaldBoard: ISP programming + I2C communication

    Ronald07/14/2016 at 14:00 0 comments

    At the time when I started this project, there was no single project I could find, that combined ISP and I2C communication. So I decided to do it myself. Since everything needs to be enboxed and I still want to be able to upgrade firmware from SSH, ISP needs to be possible "without hands".

    warning - warning - warning - warning - warning - warning - warning - warning - warning - warning

    This can kill your Rasbperry Pi, be especially careful with 5V-lines

    For the coffee machine this board will handle PWM and ADC, things an ATMega8 is better capable of than a Raspberry Pi.

    Since Gert named his expansion board GertBoard, I decided to name mine RonaldBoard (as a fellow Dutchman? At least Gert's name sounds Dutch...).

    All that's needed is: a Raspberry Pi, At*, and wires. For the Pi I chose the ATMega8 rather than ATTiny45 because of having some more cheap I/O.

    The design is as follows:

    Note! While the pin numbering is okay, the GPIO numbering is wrong! Check [1] for correct info

    • The /RESET pin is connected to pin 22 of the GPIO-headerPB0 doubles as SDA (I2C communication) and MOSI (ISP) pin
    • PB1 is connected to MOSI, and can be used with care to drive something else when not in programming mode (an LED in this example)
    • PB2 doubles as SCL (I2C communication) and SCK (ISP) pin
    • PB3 is connected to an LED

    Note that because PB1 is used by the Pi when programming the ATTiny, it probably shouldn't be used to e.g. drive a Servo using PWM.

    For Pi <=> Atmega8 communication I chose for I2C, because at the time, I couldn't get (non-bit-banging) SPI working. For the Tiny45 the pins are the same; for my ATmega8 this cost me two additional pins...

    Set up

    If you want to use this in your own project, be sure you have the following:

    • Raspberry Pi connected to the RonaldBoard
    • The pigpio library installed
    • avrdude (patched version)
    • Example source (check project files for I2c.tar.gz)
    • /etc/avrdude.conf configured with the pgio programmer on the correct pins:
      id    = "gpio2";
      desc  = "Use sysfs interface to bitbang GPIO lines";
      type  = gpio;
      reset = 25;
      sck = 3;
      mosi = 2;
      miso  = 9;


    Before the first run after boot, be sure pigpiod is running and you have the i2c module loaded. I made the following script:

    sudo ./modprobes

    After all is set up, flash the RonaldBoard:
    sudo make fuse
    sudo make flash

    The Makefile makes sure the GPIO's for I2C communication are set to read again, using pigs-commands.

    Then test it:


    You should see something like this in your terminal window:

         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    20: -- -- -- -- -- -- 26 -- -- -- -- -- -- -- -- -- 
    30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- 
    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    70: -- -- -- -- -- -- -- --                         
    test in getting the value of register 0x42:
    testing ADC read:
    testing PWM.

    Furthermore, the LED should turn off and then shine brighter and brighter.

    Used work

    Eagle libs for the ATTiny & Pi (both modified afterwards in Inkscape, but very useful for the basic symbol):


View all 5 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates