Eliza Brinkmann
Adjustable automation for the homebrewing process
Metropolia University of Applied Sciences Bachelor of Engineering
Information Technology Bachelor’s Thesis 18 August 2021
Abstract
Author: Eliza Brinkmann
Title: Adjustable automation for the homebrewing process Number of Pages: 38 pages + 1 appendix
Date: 15 June 2021
Degree: Bachelor of Engineering
Degree Programme: Information Technology Professional Major: Smart Systems
Supervisors: Kimmo Saurén, Senior Lecturer
In this study an automated home brewing system was created. The system consisted of a brewing setup and a program to automate the brewing. It was made to be
adaptable to different types of setups so it can be used amongst homebrewers. For homebrewers it is more difficult to create custom programs as they might not be familiar with programming.
By using a state machine approach to create an embedded program it is easier to adapt it to different setups [1]. The system was made with a heating element and a brewing pot. In this study an Arduino microcontroller with Wi-Fi was used for the program.
The brewing setup with the adaptable program using the state machine approach was used to successfully brew beer from an existing recipe. The brewing process was automated and created a complete beer without much interference from the user.
Keywords: automation, brewing, finite state machine, Arduino
List of Abbreviations
1 Introduction 1
1.1 Brew process 1
1.1.1 Brew process in detail 1
2 Theoretical Background 3
2.1 Finite State Machines 4
2.1.1 Theory on Finite State Machines 4
2.1.2 Finite State Machines in Software 5
2.2 Modern Embedded Systems 6
2.2.1 Types of Embedded Systems 6
2.2.2 Finite State Machines in Modern Embedded Systems 6
2.3 Summary Theoretical Background 7
3 Project Specifications 7
3.1 Introduction to project 8
3.2 Development Plan 8
3.2.1 First sprint 8
3.2.2 Second sprint 9
3.2.3 Third sprint 9
3.2.4 Testing cycle 9
3.3 Customer wishes and requirements 10
4 Material and Methods 10
4.1 Materials 11
4.1.1 Beer brewing materials 11
4.1.2 Hardware 11
4.1.3 Programming materials 12
4.2 Method 13
4.2.1 Programming 13
5 Project Implementation 14
5.1 The Implemented System 14
5.1.1 Implementing the hardware 14
5.1.2 Defining state machines 18
5.1.3 Implementing the User Communication 24
5.1.4 Testing of the brewing system 28
5.2 Brewing Results 34
6 Conclusion 36
References 37
Appendices
Appendix 1: Beer recipe
List of Abbreviations
App Application any type of computer software program that can be run can be called an application.
FSM Finite State Machine, a system to model behaviour and a mathematical model of computation.
IDE Integrated development environment, application for software development often including build automation and debugging features.
IoT Internet of Things, using internet as a way to connect different devices and sensors.
LCD Liquid Cristal Display, a type of digital display.
PID Proportional-integral-derivative a mathematical calculation to reach a setpoint by modulating a control loop.
1 Introduction
A very apt description about brewing beer is the one from Palmer [2, p239]
”The technology behind malting and brewing is one of the oldest in the history of humankind”.
In this final year project, the aim was to automate part of this tried and tested technology of making beer. This of course has been done in modern large breweries where large quantities of beer is brewed. However, for the home brewer this might be challenging. Beer brewing is a fun hobby but a somewhat complicated process because it takes a lot of time, constant attention, and a lot of attention to hygiene. Since the process of making beer is straightforward it could be automated but this might not be easy on a small scale. Because people have different brewing hardware it affects the process and can make it hard. There could be different types of recipes for which adjustments are needed. Automating the beer brewing process for home brewers to gain consistency over brews enables room for experimenting. Also, less time is wasted on many manual steps and waiting around. In this thesis the aim will be to create a program that makes it possible for home brewers to automate the brewing process
1.1 Brew process
To understand how the brewing process can be automated first the brewing process itself should be clear. This chapter will focus on the brewing process in more detail. Later in this chapter differentiations in the brewing process and recipes are discussed.
1.1.1 Brew process in detail
The aim of the brewing process is to extract the sugars and flavours out of the grains from which beer is created. The beer brewing process starts with grains,
which can be from malt, wheat, rye, corn or other grain sorts. These grains need to be able to release their proteins and starch into the brewing water, to be able to create beer. The moisturizing and drying of the grains to be able to use it for brewing is called malting [2]. After malting the grains are shredded and will be added to water in a brewing vessel and heated. The heating can be done at one specific temperature for an hour to an hour and a half, or in several steps from a lower temperature to a higher temperature. After heating, the proteins and the starch sugar should be out of the grains and into the brew [2,3]. Before continuing to the next step, the grains should be taken out of the brew.
Sometimes this is done by brewing the grains in a bag and removing said bag otherwise it needs to be removed separately. The brew can be filtered by pouring it through the grains. This filtering process is called sparging and consists of making a bed of grains in for instance a colander or sieve and pouring the brew through it. By pouring the brew over this bed of grains the impurities will be filtered out and the brew will turn clear. [2,3]
The next step is to boil the brew for an hour to one and a half hours. The process of boiling ensures that toxic substances are boiled out of the brew.
During this boil hops could be added and boiled along with the brew, this
releases extra flavour. Hops have a specific amount of bitterness, denoted in α, to indicate the bitterness. By boiling them for a specific amount of time (i.e. 60 to 10 minutes) the bitterness will differ. In some recipes, hops should be added after boil. [2,3]
The next part of the brewing process is to let the boiled brew cool down to a temperature suitable for the yeast. Then it needs to go into a fermenting vessel together with the yeast. The yeast will break down the sugar and create alcohol and carbohydrate. When most or all of the sugar has been eaten by the yeast and converted into alcohol, it is ready for the next step. Sometimes this will be changing it into a new brewing vessel to ferment off the last of the sugar in a clean vessel. Sometimes it will be bottled straight away. For the bottling process additional sugar will be added, this can be dissolved into some water first to
then add it to the brew. This additional sugar will carbonate the beer. Another option is to use a keg and add CO2 without fermenting it. [2,3]
1.1.2 Types and how it influences recipes
As explained in the previous part there are different choices to make during the brewing process. Of course, all these choices influence the beer, some aspects will influence the taste, some the smell, some the clarity and so on. Brewing beer has been around for a long time and as such there are different ways to brew beer. These differences can come from differences in beer brewing culture in countries or area and the resources available to the brewers. These
differences in resources are not only found in grains used for the beer but also the yeast strains or the type of hops. With all these differences there are different kinds of beer recipes and due to those differences also differences in the brewing process. [2,3]
Multiple mash stages are often times used and seen as the best way to give to active all enzymes. However, nowadays there is a lot of one step mashing in beer brewing recipes. Chemistry enables that in one step mashing enzymes will still release their starches and sugars when the temperature is kept around a constant temperature. Brewing in a brewing bag instead of having the grains loose is another difference in the brewing process. This saves time with filtering as the brewing bag is simply taken out of the brewing vessel. However, the beer might be less clear because it is not filtered or there might be less sugar
because this stays behind in the grains if not filtered out. These things can be adjusted by adding more sugar to the brew, this is not uncommon to do when a brew has not reached the needed level of sugar during brewing. Also, to have a clearer brew by adding a clarifying agent to the brew is quite common [2,3].
2 Theoretical Background
In this chapter the theoretical background on state machines is discussed. The reason why more focus is put on the state machines is because the principle
will be used for the program made in this thesis. A state machine, as its name suggests, consists of states in which the system can be, the behaviour in each state and the transition between states. The use of a state machine is one of the older and best-known behaviour modelling systems [4,5].
An easy way to illustrate a state machine system is with a pedestrian traffic light. Where the lights are the states: red and green. The behaviour for each colour can be defined as well, it shall wait in red until a transition occurs, in green it shall wait a certain time before transitioning. The transition will happen when someone pushes a button and the light will change to green, in the green state it shall transition back to green after a specific amount of time. As in this example and state machines, in software there is always a certain number of states and thus often the term finite state machine is used [4].
2.1 Finite State Machines
In this chapter the concept of finite state machines will be explained in a general way and later on in the chapter the concept of finite state machines will get linked to its use in software.
2.1.1 Theory on Finite State Machines
A finite state machine (FSM) can be described as such if it has certain key characteristics. Considering that it is finite it must have a finite set of possible states. Also, it has a finite amount of inputs and events to trigger a transition between the states. Each state has its own defined inputs and events. The current state with the inputs and triggers for that state define the behaviour of the system. Lastly, there has to be an initial state from where the system starts.
[4]. With these characteristics it can be seen that with an FSM a system should relatively predictable, all states, triggers and events should be known.
To describe an FSM, a state diagram can be used [5]. While small systems can be explained in words, any system a bit more complex would be hard to
understand. The example of a pedestrian traffic light from the introduction is used for the state diagram in figure 1. Where the initial state is a green light that is off, the states a finite and have their own triggers (button, time) and behave accordingly (switch to next state).
Figure 1. State Diagram of a Pedestrian Traffic Light.
2.1.2 Finite State Machines in Software
The FSM model can be used to model object-oriented software systems. This can be done in the Unified Modelling Language (UML), which is generally used to visualize a software system. These software systems can be small and show a user interface (UI). In a UI, a user will see a view and upon buttons will
transition to a different view. This can be described as a state machine because there are specific states a user can be in and upon clear actions the transition will happen. [4].
In software a state machine can be programmed as a class with state variables which hold the states and directs the program. A client can make a request to a state machine and if the current state allows it, it will execute the command for the state that was requested. If a similar request comes in and the state has already changed, a request might not be executed preventing a program to execute commands when it should not [6]. This is a way of programming a state machine into software.
2.2 Modern Embedded Systems
In this chapter the focus will be on modern embedded systems. At first types of embedded systems will be explained. Later the use and importance of state machines in embedded systems will be discussed.
2.2.1 Types of Embedded Systems
Traditional embedded systems mean software on a small computer that is often embedded within a larger system [7]. Usually the software is built specifically for an embedded system and this embedded system serves a specific purpose. An embedded system generally consists of a microprocessor and memory with if needed peripherals or hardware such as sensors and buttons [8]. The
embedded system will be run from the program on the memory and send signals to the system it is embedded into [8]. One of the challenges when
working with embedded systems is the limited resources and performances [6].
2.2.2 Finite State Machines in Modern Embedded Systems
In modern robotics, state variables are used to maintain an internal
representation of the state a robot is in. With the use of that state variable a robot can decide which actions are possible to take when sensors give
information. For instance, when a robot might search for something, it will have a state for which way it should turn. Once something is detected it should change to the move towards it state and if not go to the right turn state and search there. [5]
In Wang and Shin [1] it is discussed that using a state machine design in embedded engineering software can lead to re-usability and reconfiguration of software. One of the biggest costs in embedded systems is the amount of time it takes to adjust a system to its’ hardware. When a new system is developed it is done by a lot of tuning and testing to fit the program to the embedded system.
Wang and Shin [1] argue that making blocks in a state machine type of wat will
shorten development time and make systems easier to maintain. These blocks would be adaptable to the hardware as need but interchangeable between systems none the less.
2.3 Summary Theoretical Background
In summary the use of state machines within embedded systems poses some difficulties. While designing an embedded system with the use of state machine design will make the system easier to understand and maintain [1]. The
embedded systems are created to work within a specific environment, namely the system it will be embedded into. This means that it has to be adapted and programmed to the system it will be part of [8]. Adding a state machine variable into such a specific environment would seem like extra work.
However, Wang and Shin [1] have shown that it is possible to re-use state machines within similar embedded systems. The benefits this would bring might make it worth the extra time and commitment needed to make an embedded system with state machine variables. In the long run code might be easier to maintain and to re-create on a different system. While each developer has their own preferences with designing and creating a system, it should be kept in mind that while this might work perfectly on one system. The effort in making a great embedded system would be a waste if it is then never used in another system.
3 Project Specifications
The idea for this thesis project was to create a small and easily adaptable automated home brewing system. On one side because people have started to brew from home more avidly. But also, because the consumption of special beers has become more mainstream and home brewers try to make special beers from home. Having an automated beer brewing system will take a lot of manual steps out of the brewing process.
3.1 Introduction to project
The project shall be creating a small automated home brew system. As shown in the introduction chapter of this report creating beer is not necessarily a complicated process. However, it does often have many manual steps during the brew process. Most that need to be done on time and at a specific
temperature. The home brewers lack the equipment of the professional brewers and thus are not able to consistently make the same beer. To be able to
experiment with different flavours consistency is important. Also, home brewing is a time-consuming feat because of all the manual steps and lengthy process.
At all points temperature needs to be maintained and ingredients need to be added. This makes brewing beer at home a time-consuming hobby. For some this might be the appeal but for others automating parts of the process will cut time from the process.
3.2 Development Plan
The development process will follow the agile process in general, although as a one-person development team the aspects of team management are not used.
The development process will consist of several rounds of development
(sprints), where each round of development will focus on different aspects and features. After each round of development, the previous part will be used as a base for the current round of development. After the sprints are done and a whole program has been made a testing cycle is done for the implementation in the brewing process.
3.2.1 First sprint
The subject of this sprint is to connect and implement the measuring hardware into the brewing hardware. This also consists of finding Arduino libraries that match with the chosen hardware.
The goals are:
• Fitting sensors and actuators in/on the hardware
• Reading data from sensors
• Controlling the servos for the hops-dispensers
• Send information to an LCD screen 3.2.2 Second sprint
The state machine approach will be used to define the brew stages in the second sprint. The temperature control will also be added to be used during the brewing stages.
The goals for this sprint are:
• All states for the brewing process are defined, it’s triggers and event are clear. These will be added to the program.
• The temperature control by Proportional Integral Derivative (PID) will be added to the program and used during each stage.
3.2.3 Third sprint
The third sprint will focus on providing feedback to and from the user either through an application or an LCD screen on (setting) the current brewing stage and temperature.
The goals for this sprint are:
• During the brewing stage feedback should be given to the user in some way.
• User can set-up their preferred way of feedback.
• User is able to input the brewing times and temperatures.
3.2.4 Testing cycle
During this testing cycle a complete recipe will be brewed. To make sure every part of the program works the recipe will be made several times. The first time should be with no ingredients, but just water to make sure none are wasted.
Once this initial full-scale test is successful and any problems are solved, testing with ingredients can start. In the end the recipe can be brewed a couple of times
Although during each sprint there will be tests after development of the full program full-scale testing should be done. Technically this testing cycle could be part of the third sprint because testing is part of a sprint. However, during testing in the sprints, the brewing resources will not be used and mostly practiced without anything or with water.
3.3 Customer wishes and requirements
The intention of this project was to create a method that can be used by the writer and a local brew club. Therefore, this project should be usable and adjustable for people with different wishes and hardware. In general, other people might not be able to understand the details or the intricacies of a
program. Again, something similar might be an issue with the hardware, as it is meant to be used for a wide range of people this might vary.
The plan is to make the program modular with a state machine approach so that it is adjustable to the needs of different people. It will also make possible to use different types of recipes with the same program. Another decision is to use an Arduino and its libraries to make sure a wide range of people are able to use and understand what the program does.
4 Material and Methods
In this chapter the materials and methods of this project will be described. Also, reasons for certain choices and their limitations will be discussed.
4.1 Materials
All materials will be chosen after comparing the options keeping the requirements for the project in mind.
4.1.1 Beer brewing equipment
Since the beer brewing process will be automated the decisions on what parts to use are important. These parts will decide what limitations, necessities and possibilities there are to the project.
The first choice is the brewing vessel, in here the beer will be brewed. A pot or pan is preferred over a plastic tub. While it should be possible to brew in PE plastic as it is safe at those temperatures. However, using plastic is not very durable as it does degrade over time and it would be preferable to use a setup for many years. The choice to use a stainless-steel brew pot over a PE plastic fermenting tub is thus a bit of a personal one. This is a brewing material that could be changed without major changes needed to the project.
Furthermore, a heating element was used, a water cooker element for a
Moulinex of 2200 Watts. By using a heating element from a water cooker, it can be assumed it is able to heat water to a boiling temperature.
4.1.2 Hardware
An Arduino nano 33 IoT was used for the programming. To power the whole system and the Arduino a power supply box with solid state relay from an earlier IoT project was used. The power supply box and its components are shown in figure 2. This includes a power supply unit which converts 220 volts mains power into 5 volts to be used by the Arduino. But also, a solid-state relay which the Arduino can use to switch the exit 220 volts mains energy on or off.
Figure 2. Power Box to switch heating element and power Arduino.
The heating element was connected to this power supply box and will be switched on/off by the Arduino. To keep track of the brewing process an LCD screen will be connected to the Arduino. For temperature measurements
DS18B20 [9] temperature sensors are used. To cross-check the readings of the DS18B20 sensors an InkBird Wi-Fi thermometer [10] was used. Since an
InkBird has many temperature sensors and is connected to Wi-Fi it is easy for testing if the measured temperatures by the Arduino are accurate. For hops dispensing a couple of 3D printed tubes with a loose lid. On the side of the tube a servo could be attached so it can open the lid by sliding it to the side.
4.1.3 Programming environment
The programming will be done in the Arduino IDE since it allows the use of the Arduino library. The Arduino IDE is a development environment with C and C++
as its programming languages. Converting the code and sending it to the Arduino boards is integrated in the Arduino IDE, making it relatively easy to run a self-made program on an Arduino board. Using the Arduino IDE allows other people to easily copy or replicate the brewing program. The availability of the
libraries for the Arduino makes creating a program a bit easier since a lot of things are already made.
4.2 Method
The brew system will be put together with the Arduino and step by step developed according to the development plan.
4.2.1 Programming
First the beer brewing program needs to be written at least in a general sense.
It should encompass the brew process and have states for the parts of the process.
Second a round of constructing the hardware that is going to be used. Whatever hardware is used will set the limitations for the project. Specific hardware will need a certain set-up or use some other part to work. Therefore, the first step is to choose the hardware and set-up of the brew process so those parts can be automated.
Third the sensors and testing their connection with a program. To be able to make any kind of brew the temperature sensor is important so this needs to be the second working part. Then a round of testing with the hardware and the sensor in general while not part of the brew process. This to set-up to the peripherals around the process such as connection to Wi-Fi and added parts such as an LCD screen and dispensers. These can be added and changed at later times if needed.
A testing round of the complete setup but making just the brew and boiling it without hops. This should be done to make sure the program works with all the components and the entire process is done. After this test some tweaks can be made to the general set-up and the bugs from the program can be fixed. Next a testing round with making the brew and then the boiling with hops but manually
added. This round of development will make a complete product to be
fermented. Lastly, making the actual brew with the boiling of the hops and small changes in setup if indicated from the last test.
5 Project Implementation
In this chapter the automated brewing system which was made will be
discussed. First how the hardware was put together is explained and after that how the brewing program was created and tested. Lastly, the results of the full tests and how the actual brews turned out are reported.
5.1 The Implemented System
The real made system was developed during the three sprints and a testing cycle. This order of development works well since it starts with the hardware and basic set-up. Before adding more peripherals each round of development.
5.1.1 Implementing the hardware
First the brew vessel was made. The idea was to attach the heating element in the pan, the heating element is shown in figure 3. However, the pan is quite thin, which makes it hard to attach anything on it. For this reason, a stainless- steel ring was welded into the pan. Through this ring the heating element was inserted and with a rubber O-ring it was a waterproof seal.
Figure 3. Heating element with pins.
Since the heating element was meant as a spare part for a water heater it did not come with a plug for the outlet. An electrical wire needed to be soldered onto each of the pins of the heating element. To make sure that any water leak would not lead to dangerous outcomes some shrinking tube was fitted over the connections. As an addition, a self-vulcanizing rubber band was wrapped around the connections so that it was as waterproof as possible. Figure 4 shows the pot with the heating element in the inside and the waterproof ring on the outside.
Figure 4. Pot with welded heating element inside.
In figure 5 the pot was tested to make sure all the seals would hold during boiling. As well as to make sure it was actually possible to heat that amount of water to a boil. In figure 5 it also shows the InkBird Wi-Fi thermometer [10] with sensors which is connected to the InkBird application [11] and will take and collect temperature measurements.
Figure 5. Heating element with steel mesh and InkBrid temperature sensors for testing.
The brewing will be done with a brewing bag, to make sure the grains would not get damaged by the heating element. A steel mesh was used to cover the heating element to prevent anything to come into direct contact with the heating element. In this case the mesh came from a tea strainer that was cut open on one side and then slid over the heating element.
Since the first part of the implantation is more hardware related there is not much to program yet. What should be implemented is the temperature sensor.
For this the matching Arduino library should be installed. The DS18B20 [11]
temperature sensor uses a 1-Wire bus, there is an Arduino library specifically for this communication protocol [12]. The other library that is needed is the Dallas Temperature library [13], this handles the conversion. These libraries have clear documentation which also explains how to implement them. In this case the documentation is followed and the implementation is shown in listing 1.
Only the pin number needs to be changed to match the pin used on the Arduino
for the sensor. A wiring diagram is added in appendix 1 to see how the pins are connected in this project.
#include <OneWire.h>
#include <DallasTemperature.h>
#define ONE_WIRE_BUS 2 //PIN number on Arduino OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
Listing 1. Implementation of One wire and Dallas temperature libraries.
5.1.2 Defining state machines
Using the state machine principle, the stages of the program should be clearly defined to work when triggers and events happen. The stages of the brewing process lend themselves well for clearly defined states. It was specified in such a way that each stage in the brewing process is made into their own state. For each specific state it needs to be brought to temperature and stay there for a specific time before the next state will be triggered.
That makes the main states the ones for the brewing stages and for the boiling with/without hops. These states are triggered by time to move to the next state and timing starts when at a certain temperature is reached. In listing 2 an example of a first brew stage is added.
if( state == MashStageOne ){
brewStageTime = firstStep;
startPID(firstTemp);
state = MashStageTwo;
}
Listing 2. Code example of a brew state
In listing 2 it is shown that using the state machine approach give easy to read code. First in the conditional it finds the right state it should execute. In the state the brewing time for this brewing stage is set and a proportional integration derivative is called with the temperature for the brewing stage. In listing 3 the general variables are shown that are needed for the brew stages.
// States
#define CreateRecipe 0
#define MashStageOne 1
#define MashStageTwo 2
#define MashStageThree 3
#define MashStageFour 4
#define FirstHops 5
#define SecondHops 6
#define ThirdHops 7
#define FourthHops 8
#define Done 9
uint8_t state = MashStageOne; //set to MashStageOne if times programmed in // mash times time in milliseconds, 0 for adding settings in first state unsigned long firstStep = 1800000; // 30 min
unsigned long secondStep = 1800000; // 30 min unsigned long thirdStep = 1320000; // 22 min unsigned long fourthStep = 120000; // 2 min // mash temps
double firstTemp = 0.0;
double secondTemp = 0.0;
double thirdTemp = 0.0;
double fourthTemp = 0.0;
// hops time in milliseconds, 0 for adding settings in first state unsigned long firstHopsTime = 0;
unsigned long secondHopsTime = 0;
unsigned long thirdHopsTime = 0;
unsigned long fourthHopsTime = 0;
double hopsBoil = 97.00;
// temp
double temp = 0.0;
// timing variables
unsigned long temperatureMeasureTime = 0;
unsigned long previousTempTime = 0;
unsigned long startTime = 0;
unsigned long startBrewStage = 0;
unsigned long currentTime = 0;
unsigned long brewStageTime = 0;
unsigned long updateTimer = 0;
unsigned long totalTime = 0;
bool underTemp = true;
bool sentDone = false;
Listing 3. Setup variables used to declare temperatures and time
Listing 3 shows variables that are needed to keep track of time spent in the specific parts of the program. For instance, total brew time and amount of time spent brewing at the right temperature. But also, the temperatures that are needed in each state. For the hops states this is easier since it always is 97°Celsuis, it cannot be 100°Celsius as it will not be reached and measured in an open pot. The next paragraph will go over the proportional integration
derivative in more detail. In figure 6 a flowchart of the program and how it will move over the states is shown,
Figure 6. Flowchart of the brewing program states.
In figure 6 it shows that the brew states are in essence the same but with different values for time and temperature. Each state uses different values but the process is the same. It is possible to skip the user interaction to setup the variables for the brew times and temperatures. These can just be programmed into the Arduino directly.
To control the temperature a Proportional Integration Derivative (PID) was used.
The decision was made to use an Arduino library PID and a well-documented PID [14]. Because this PID library is well documented it helps adjusting the variables of the PID to a setup. This makes this PID more usable for a large group of people. Instead of the library the PID can be programmed personally by using the mathematical calculation for it. In listing 4 the settings for the PID in this implementation are shown.
#include <PID_v1.h>
#define RELAY_PIN 9 //The pin to heater which needs to be toggled //Define input/output variables for PID
double Setpoint, Input; // Temperature (must be in the same units) double Output; //0-WindowSize, Part of PWM window where output is ACTIVE.
//Specify the links and initial tuning parameters
double Kp = 3; //Proportional Constant: Active 10 milliseconds for each degree low
double Ki = 3; //Integral Constant: Increase to prevent offset
double Kd = 8; //Differential Constant: Increase to prevent overshoot // Note: "DIRECT" means Higher Output -> Higher Input.
// "REVERSE" means Higher Output -> Lower Input.
PID myPID(&Input, &Output, &Setpoint, Kp, Ki, Kd, DIRECT);
const float WindowSize = 2500.00;
unsigned long windowStartTime = 0;
Listing 4. Set-up of PID library and variables with comments from library [14].
Trying out the PID variables and tweaking them over time gives a more fine- tuned PID. The heating function with PID is then used in each of the brew stages as shown before in listing 2. The heating function uses the PID and is shown in listing 5 along with the timing for each brew stage. First, all the timings are initialised by setting them to the current time and the wanted temperature which is given by the brew stage. Then there will be a temperature
measurement, if that is lower than the wanted temperature the timing for the brewing stage should not start yet.
void startPID(double temperatureSetPoint) {
windowStartTime = millis(); //Starting time PID currentTime = millis(); //Current time
startBrewStage = millis(); //Start in this brew stage
sensors.requestTemperatures();
temp = sensors.getTempCByIndex(0); //Add offset for heating element Setpoint = temperatureSetPoint; //Desired temperature
//Initial temperature below wanted temperature if(temp < temperatureSetPoint){
underTemp = true;
} else underTemp = false;
int rightTime = ( brewStageTime >= ( currentTime - startBrewStage ));
/* Heating loop */
}
Listing 5. Temperature control through PID.
During each brew stage there are a couple of timings that are kept. A total time in a brew stage, this is to know how much time has been spent in a brew stage.
Then an important time is how long has the temperature been at the wanted temperature. When starting this function first check is whether the temperature is already high enough. It should not start counting the time at temperature if it has not reached the right temperature. If the temperature reaches the wanted temperature it will stop updating the time. In listing 6 the heating loop is shown, in here the PID is used to warm the brew and will keep doing so until it has spent the amount of time needed at that temperature.
//Keep going untill the brewStageTime is smaller or equal to time passed while( rightTime )
{
Blynk.run(); //Start communication in loop
myPID.Compute();
sensors.requestTemperatures();
temp = sensors.getTempCByIndex(0); //Add offset from heating element
//Is the temperature low now && was low, startTime should be updated if(temp < Setpoint && underTemp){
startBrewStage = currentTime;
} else underTemp = false;
//Set temperature to PID Input Input = temp;
currentTime = millis();
//Time steps PID computation, small windowsize many small steps, //Less overshoot but taxing on the relay
if (currentTime - windowStartTime > WindowSize) {
//Time to shift the Relay Window windowStartTime += WindowSize;
}
//"Output" is the number of milliseconds in each //window to keep the output ACTIVE
if (Output < (currentTime - windowStartTime)){
digitalWrite(RELAY_PIN, !HIGH); //ON }
else {
digitalWrite(RELAY_PIN, HIGH); //OFF }
if(( currentTime - previousTempTime ) > 5000 ) { previousTempTime = currentTime;
/* Communication */
}
rightTime = ( brewStageTime >= ( currentTime - startBrewStage ));
}
Listing 6. Heating loop inside the heating function of listing 5.
The heating loop will keep going for as long as the time spent in the loop at the right temperature is lower than the needed time for the brew stage. In the loop the current time will be updated. Then the temperature will be measured and checked if it is already at the desired temperature. Next the temperature is given as input to the PID and calculated. Then a part from the PID library is used, for how long and if the heater should be on. After that it will check if it is time to communicate with the user again. There is no need to update the information to the user every loop. The communication will be discussed in the next part of this chapter.
5.1.3 Implementing the User Communication
There were several types of user communication that were implemented to try out which one worked best in this setup. An LCD screen was used in this implementation which is a common way to communicate to a user. To keep track of what happens with the Arduino and make sure it is able to connect to local Wi-Fi an LCD screen is connected. On the LCD screen the Arduino prints the process of connecting to the local Wi-Fi network and later on also
temperature measurements.
Another way used during the implementation was a phone app called Blynk [15]. Which is an IoT app that allows users to send information from the IoT device to the app. This is done through a wireless connection from the IoT device to the cloud service of Blynk. The Blynk cloud service will then send it to the app on the phone. Listing 7 illustrates how the Wi-Fi and the connection to Blynk app were set up.
#include <SPI.h>
#include <WiFiNINA.h>
#include <BlynkSimpleWiFiNINA.h>
#define BLYNK_PRINT Serial // Wifi / Blynk
char auth[] = ""; // Blynk authentication char ssid[] = ""; // Wifi SSID
char pass[] = ""; // Wifi password int status = WL_IDLE_STATUS;
// Initialize the Wifi client WiFiSSLClient client;
// Blynk terminal is V1 in Blynk app WidgetTerminal terminal(V1);
void setup() {
Serial.begin(9600);
// PID setup
pinMode(RELAY_PIN, OUTPUT);
digitalWrite(RELAY_PIN, LOW);
//tell the PID to range between 0 and the full window size myPID.SetOutputLimits(0, WindowSize);
//turn the PID on
myPID.SetMode(AUTOMATIC);
WifiSetup();
// Blynk setup
Blynk.begin(auth, ssid, pass);
Blynk.virtualWrite(V0, 00.00 );
startTime = millis();
Blynk.run();
}
void WifiSetup() {
// check for the WiFi module:
if (WiFi.status() == WL_NO_MODULE) {
Serial.println("Communication with WiFi module failed!");
// don't continue while (true);
}
connectToAP(); // Connect to Wifi Access Point }
void connectToAP() {
// Try to connect to Wifi network while ( status != WL_CONNECTED) { // Connect to WPA/WPA2 network status = WiFi.begin(ssid, pass);
// wait 1 second for connection:
delay(1000);
if(status != WL_CONNECTED){
Serial.println("Not Connected...");
} else {
Serial.println("Connected...");
} } }
Listing 7. Setup with Wi-Fi and Blynk app setup.
This is the setup part of the brewing program where the Wi-Fi and Blynk setup is done, as well as initializing the PID. For the Wi-Fi the SSID and password of the network are needed. The setup function calls the Wi-Fi setup and connects functions. The Blynk setup is done after the Wi-Fi setup since it will not work without. After this setup the Arduino is connected to the Blynk app and will show up in it.
What makes Blynk very usable is that it is meant for IoT devices such as Arduino’s. In the Blynk application widgets can be added through which data can be shown. Screenshots of the Blynk app used during this implementation is shown in figure 7.
Figure 7. Example of the Blynk application used, on the left in the first brew stage and on the right during boiling.
The communication to the brewing system can be done by a rotary button to insert the temperatures and times. Or the variables for the brew temperatures and times can be directly programmed into the program before compiling it onto the Arduino nano board. In the end it depends on what type of interaction or feedback the user wants. In this implementation the information was directly programmed into the program.
To deal with the user interaction extra states and actions can be added. A state for creating a recipe and starting the brewing process, and a state for
communication with the user can be added. In creating the recipe, the user sets
the time and temperature, these are used for to create a state. There can be as many states added as wanted.
The communication is not necessarily a state on its own but an action within each state instead. During the states of the brewing process there is routinely feedback over Blynk or LCD to the user, figure 8 shows a complete setup with LCD screen. Depending on the frequency of communication, for instance if regular feedback to the user is very important a separate state can be made for the communication. This is especially true for communication over LCD since there is more code and actions needed for it to work well.
Figure 8. Full test set-up.
5.1.4 Testing of the brewing system
During the testing cycles a whole recipe was brewed, this recipe is added as an addendum. This recipe is originally in Dutch and is a strong blonde beer. It is supposed to have about 9% of alcohol, starts with an Original Gravity (OG) of 1.079 and a Final Gravity (FG) of 1.019. The malts used are all from
Dingemans, pilsner malt at 3 EBC, light wheat malt also at 3 EBC and finally Munchener malt at 15 EBC. The recipe is sold as a packet so it is not clear how much of each of the malts is used. The brewing times are 30 minutes at
62°Celsius, 30 minutes at 68°Celsius, 22 minutes at 72°Celsius and lastly 2 minutes at 78°Celsius. For hops Pacific Gem and Saaz is used divided in 4 boil batches. First is all of the pacific gem which will boil for 90 minutes. The Saaz is added in 3 steps, and boil with the Pacific Gem for 15 and 5 minutes, the last batch goes in when the boiling is done and the brew will cool down. The yeast used is 11 grams of Dawnstar Nottingham. By using this recipe, it can be assumed that with successful brewing the beer should be tasty. Also, since it is a recipe made by a local beer club and sold to others as a do-it-yourself packet, if the beer brewing system works for the recipe it should be adjustable for others as well.
As with all beer brewing first the malts are shredded and put into a brewing bag.
Water is added to the pot and the brewing bag is added to the water. All the sensors and hardware are added to the brewing pot as partly seen on figure 9, the Arduino and heater control are outside of the thermal bag. Once everything is set up and the Arduino has connected to Wi-Fi and is reporting to Blynk, the brewing was started. In figure 10 the thermal bag is closed and the wires from the sensors come out of the top.
Figure 9. set-up at start of the brewing process with the malts in a brewing bag and the sensors inserted in different parts of the brewing pot.
Figure 10. Closed brewing bag with the sensor wires on the side.
From this point onwards, there was not much to do except for noting the temperatures and checking the progress in the Blynk application. Using the Blynk application the temperatures used for the PID controller could be noted.
The InkBird recorded more temperatures from different spots inside the brewing pot. This was done to check if there would be different readings at the different spots. The results of the temperature measurements are seen in figure 11.
Figure 11. Graph of the measured temperatures during mash stages.
It seems that the temperature inside the brewing bag is most of the time a bit higher than the others. This might be due to the heat staying in between the grains instead of dispersing throughout the pot. Above the heating element it was a bit warmer than opposite to the heater but this is to be expected. Overall the temperature is steady and the increases from the recipe can be seen in the data. The temperature from the boiling stages from the last test is steady around 100°Celsius as shown in figure 12. There was a bit of a worry that it would not reach the temperature because it was outside in 4°Celsius. However, the heating element had enough wattage to handle these circumstances.
0 10 20 30 40 50 60 70 80 90 100
Brewing Mash Stages
Sensor
Inkbird 1. Opposite Inkbird 2. Above Inkbird 3. Inside bag
Figure 12. Graph of the measured temperatures during boiling
When the heating process has finished the malts are removed. In the one of the first test cycles it seemed like the brewing bag was a bit small. The malts were packed tightly together and it seemed that there was still quite some sugar in between that needed to be rinsed out. Later on, a larger brewing bag was used and this was an improvement as there seemed to be less leftover sugar.
However, since extra water was needed for the boiling stage it was rinsed with water. The next step was the boiling and the adding of hops. At first the hops were manually added without the hops dispensers, as seen in figure 13.
0 20 40 60 80 100 120
Brewing Boiling Stages
Sensor
Inkbird 1. Opposite Inkbird 2. Above Inkbird 3. Middle
Figure 13. Beer brew boiling with control box for the heating element, and temperature sensors on the table.
During the next test cycles the hops dispensers were used, as seen in figure 14.
They worked well but the way they needed to be suspended over the boil was not preferable. It would be an improvement if they could be more to the side and dispense through an open and short ramp. This would make sure that the
fumes from the boil can evaporate away instead of condensation and maybe drip back into the brew.
Figure 14. Beer brew boiling setup with hops dispensers on top.
5.2 Brewing Results
The result of the fermenting is seen in figure 15. It shows that the brew turned into quite clear and light amber beer. After letting it ferment on the bottle for another couple of weeks the colour has darkened a bit as can be seen in figure 16. While it already tasted good the deep flavours were still lacking which made it clear that the beer needed to age for a bit more. After about a month it was tried again, and while the colour had not notably changed in the meantime, the deeper flavour was definitely there.
Figure 15. Result after fermenting.
Figure 16. Result after aging for two weeks.
6 Conclusion
Creating the program meant using many existing Arduino libraries. The trickier part was to make the libraries work together. By using the Arduino IDE and the available libraries proved to be a good idea making it easier to recreate and adjust the program. A big downside is that certain embedded tasks are hard to time and combine.
The state machine approach of the program was helpful during development. It gave clear boundaries and limits to each part of the program. By using the states, it also became clearer at what points in the process an update to the user could be given. One possibility might be to have communication separated and running on a second Arduino/board. This would leave one board to deal with the brewing process and the other one with the communication.
As a result of this study the brewing hardware was improved. A pot of a better standard and thicker sides could be fitted. The heating element which is intended for a water boiler and difficult to attach to a pan was problematic because it had to be soldered. It turned out not to be waterproof and safe when using it regularly or for long term use.
The beer that was made did exceed the expectations, it had the depth and a consistent flavour of a well-made beer. Of course, a good recipe makes a great base for good beer but the low amount of effort it took to make the beer with the set-up created in this project was significant. The next step would be to start sharing the program with more people and see how it can be adapted to fit different needs and set-ups.
.
References
1 Wang S, Shin KG. An architecture for embedded software integration using reusable components [PDF]. In: Proceedings of the 2000
international conference on Compilers, architecture, and synthesis for embedded systems 2000 Nov 1 (pp. 110-118).
2 Palmer JJ. How to Brew: Everything you need to know to brew beer right the first time. Brewers Publications; 2006 May 17.
3 Otten A. Verander water in bier. Brouwland bvba, 2018 February.
4 Wright, David R. (2005). Finite State Machines [PDF]. CSC215 Class Notes.
David R. Wright website, N. Carolina State Univ.
URL: https://web.archive.org/web/20140327131120/
http://www4.ncsu.edu/~drwrigh3/docs/courses/csc216/fsm-notes.pdf.
Retrieved October 1, 2020.
5 Ben-Ari M, Mondada F. Elements of robotics [PDF]. Springer Nature;
2017.
6 Schneider FB. Implementing fault-tolerant services using the state machine approach: A tutorial. ACM Computing Surveys (CSUR) [PDF].
1990 Dec 1;22(4):299-319.
7 Lee EA, Seshia SA. Introduction to embedded systems: A cyber-physical systems approach [PDF]. MIT Press; 2016 Dec 30
8 Fan X. Real-time embedded systems: design principles and engineering practices [e-book]. Newnes; 2015 Feb 25.
9 Maxim Integrated. DS18B20 Programmable Resolution 1-Wire Digital Thermometer [Datasheet]. Aug 2019
10 InkBird. Rechargeable WiFi Grill Thermometer IBBQ-4T. Accessed on May 2, 2021 from https://inkbird.com/collections/wifi-bbq-
thermometer/products/ibbq-4t
11 Inkbird Tech. C.L. InkBird Pro Application. Accessed on May 2, 2021 from https://play.google.com/store/apps/details?id=com.inkbird.smartpro
12 Stoffregen P. One Wire Library. Accessed on May 3, 2021 at https://www.pjrc.com/teensy/td_libs_OneWire.html
13 Burton M. Dallas temperature control library. Accessed on May 3, 2021 at https://www.milesburton.com/Dallas_Temperature_Control_Library
14 Beauregard B. Improving the Beginner’s PID. April 2011, accessed at http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid- introduction/
15 Blynk IoT application. Accessed on May 2, 2021 from http://docs.blynk.cc/
