1. 11

  2. 1

    So if I understand it correctly, the machines run on Linux and use Flash – or rather, Gnash – as the UI for the older version? A rather unusual tech combination 😅 Why was this chosen in the first place? Did it run Windows before?

    1. 2

      Yes, you’re in the correct corner. Reason is legacy. Machines have an average lifespan of one to two decades and a few years of development time before that. Also support for as long as they are made, both software and hardware improvements.

      Not windows, but back around 2006/2009 it seems that was the best option for a mature ui toolkit with touchscreen support as well as rapid development.

      These machines are around since the 1950’s, evolved from a simple time based drum switch that turns on and off valves and motors for a set time, to a microcontroller with nucleus RTOS, to Linux nowadays. Same code base, but ported over.

      Same goes for the ui. First only simple mechanical buttons (coffee/hot water) Then more buttons for different products. Then leds for those buttons. Then a simple one line character display. A full color 10” touch screen, revolutionary back then. Now a full HD screen running QT.

      All with the same evolving code base. One binary runs on all machines, compiled for the correct architecture, armv7, the microcontrollers, “desktop” (x86/64) Linux and if I wanted I think I could compile for windows.

      I wasn’t around when flash / gnash was chosen but back then as far as I can read back in our docs archive gtk and qt were not mature enough on touch screens.

      Gnash uses an xml-rpc api to communicate back to the coffee application, for the qt and touchless interface we have a JSON http api, no actual logic is in the ui. Here is a machine near me, touchless: https://touchless.coffee/order/8C7i6bfmWFrp9

      Normally you scan a qr code on the screen or enter a number code displayed, but the ui and customization should be available with just the link.

      That part uses mqtt, we did that in a month, super cool project to work on software wise. Got a limit of 5 to max 7 MB of data per month, way optimized. Very popular in the USA since we released it in July/August, a customer even made videos about it, which is quite flattering. We found it randomly on YouTube, not involved in any way with it. (https://youtu.be/7biZoM253sM That guy is so calm and peaceful, I like the video)

    2. 1

      That coffee machine UI looks familiar, I think an old customer had one!

      It gives shortcut numbers for beverage configurations, as a convenience feature, right?

      I remember asking them if you can reverse engineer it; slap in a number and get a blueberry-juice-espresso combo, and they told me they’d tried to break the bitmap but apparently it wasn’t a bitmap at all ;)

      Nice write-up and iirc nice coffee! ;)

      1. 6

        Yes, number choice is a feature of the machines we produce. Not sure if we’re the only one but if you also remember the UI, that should be correct.

        Blueberry-espresso juice should be impossible via number choice, unless that is what is configured in the config file. All machines have a config file (used to be on a smartcard 20 years ago, nowdays filesystem, binary xml based format, quite neat for the time), in which the recipes are defined. They contain instructions for the components, like how long to grind beans, grammage of product, how much water, what pressure, time for a mixer, etc. All of the water outlets should also be seperate, no coffee-water in your chocolate or hot-water.

        Each recipe has a number and a few options, like strength (stronger often means grind a bit more beans, weak, grind less), milk / sugar / fresh milk choices or different beans (some customers have 2 types of beans).

        The number choice lets you choose such a recipe including the choices, but it does not let you execute arbitrary commands so to say. If you have the config program, you could in theory program a recipe that combines espresso and blueberry juice (mixer / powder I guess), but I think that would not taste well.

        The format of the number choice is the following, binary:



          AAaaaaa  7 bits  = recipe number (0-127)
          Bb       2 bits  = add on product 1, incl stength (like milk/sugar)
          				B b
          				0 0 = no add on product
          				1 0 = weak
          				0 1 = normal
          				1 1 = strong
          Cc       2 bits  = add on product 2,  incl strength
          				C c
          				0 0 = no add on product
          				1 0 = weak
          				0 1 = normal
          				1 1 = strong
          ddd      3 bits  = strength of main choice (like coffee/espresso), stronger 
          				000 = normal
          				001 = strong
          				010 = weak     
          				011 = extra strong
          				100 = extra weak
          				101 = reserved
          				110 = reserved
          				111 = reserved
          e        1 bit   = add on product 3
          				0 = no
          				1 = yes

        The number is constructed in such a way that is becomes larger / longer when more is changed from the consumption. Often a number choice is just the recipe number, we try to keep configs consistent, so often 1 is coffee beans, 4 is espresso, 10 is hot water. When you change something, like add milk or strength, the number should become not more than 3 digits.

        Cupsizes are different recipe numbers (because the dosage / amount of water / other product preparation steps things) can be different, so they give you a different number choice.

        You could use a tool like bc to calculate the number choice:

        ~$ bc

        Compare bitmap:


        The recipe number part is 1100011 binairy, what is that in decimal:

        ~$ bc
        1. 1

          Whoah, thank you very much for this reply!

          Super interesting to see behind the scenes, and of course it kinda makes sense you can’t “abuse” it, though geeks gotta try ;)