P11 Smart Brewery

Team Members:
S18 Adam Sninčák
Role: programmer, tester
S20 Martin Stratiot
Role: architect, programmer

Purpose
SmartBrew will contain multiple sensors, actuators and other electronic units in order to not only provide visualization and control for the brewer, but also implement a mechanism for automation of the brewing process based on configurable recipe. Architecture of the system will consist of multiple layers, specifically:
A layer providing interface between the system core and other hardware components (sensors and actuators). This layer (from now on referred to as the edge layer) will consist of multiple modules, based on ESP32 development kits. Each module will be used to communicate with a specific model of device (e.g. specific sensor) and will be connected wirelessly to the system core using MQTT protocol. Each module can serve multiple devices of the same model. If needed, any module will be connected to required converters and expansion boards. Module firmware updates will be possible to distribute over-the-air (OTA updates).
A layer providing core functionality - system core, which will consist of a database server and automation engine. Configuration of connected hardware, modules and recipes will be stored in the database, as well as all readings and measurements from connected modules.
Final layer will represent a graphical user interface. It will be implemented as a web front-end application and will be used for SCADA-like control, visualization and recipe configuration, as well as timeseries chart visualization of the brewing process indicators (e.g. temperature trends).
Individual Visions During this class, we will work on developing the first part of automated smart beer brewer (SmartBrew).

Team Vision
During this class, we will work on developing the first part of automated smart beer brewer (SmartBrew). A layer providing interface between the system core and other hardware components (sensors and actuators).
Team Mission
Craft Beer.
Strategy
SmartBrew will contain multiple sensors, actuators and other electronic units in order to not only provide visualization and control for the brewer, but also implement a mechanism for automation of the brewing process based on configurable recipe. Architecture of the system will consist of multiple layers.
End Customer
Home breweries.
Goals and Expectations
This project will focus on implementing the edge layer modules. It will be necessary to design the module firmwares, MQTT APIs and hardware connections, and consider all the necessary converters and other miscellaneous electronics used, as well as program each module separately (although core of the firmware will be the same for every module). Therefore the estimated time needed for this project is 10 hours a week (by each one of us). Output of this project should be fully working and tested firmware for every module. For each developed module a prototype deployed and connected to real hardware will be provided.
Solution Description
functional requirements:
• temperature measurement
• motor control
• heater control

non-functional requirement:
• modularity
• scalability
• reliability

Components:
• ESP32
• Raspberry pi
• H300
• DS18B20
• HW655

Project Roadmaps
September: Architecture
October: Sensors
November: Implementation
December: Implementation and testing
January: Prototype

Expected Effort
5 hours a week (by each one of us)

 

Architektúra systému

 

Architektúra systému Smartbrew sa skladá z troch hlavných vrstiev: frontend, backend a vrstva komunikačných modulov (ďalej len IoT vrstva). Jednotlivé vrstvy sú oddeliteľné a sú navrhnuté pre prevádzku na rôznych fyzických zariadeniach súčasne. V rámci tohto projektu sa venujeme IoT vrstve.

Vrstvy backend a frontend spolu komunikujú prostredníctvom webových protokolov HTTP a Websocket za použitia webovej architektúry typu REST. Komunikácia medzi IoT vrstvou a vrstvou backend je realizovaná prostredníctvom broker systému založenom na protokole MQTT. IoT vrstva nemôže priamo komunikovať s vrstvou frontend, ich komunikácia musí byť sprostredkovaná cez vrstvu backend.

 

Vrstva komunikačných modulov (IoT vrstva)

Komunikačný modul je fyzické zariadenie navrhnuté pre obsluhu konkrétneho modelu fyzického zariadenia (senzora alebo aktuátora) použitého pre účely varenia piva. Jeden komunikačný modul môže vo väčšine prípadov obsluhovať viacero zariadení naraz, pričom tieto zariadenia musia byť rovnakého typu (napríklad môže modul obsluhovať zbernicu viacerých rovnakých senzorov teploty).

Komunikačný modul komunikuje s backend vrstvou obojsmerne prostredníctvom MQTT protokolu. Backend vrstva modul ovláda - nastavuje jeho konfiguráciu a prostredníctvom neho ovláda pripojené zariadenia, pričom modul posiela na backend vrstvu dáta prečítané z týchto zariadení. Moduly možno do systému pridávať dynamicky a flexibilne, prípadne je možné dynamicky pridávať zariadenia na modul - nutná je iba zmena konfigurácie na strane backend vrstvy.

Backend vrstva

Backend vrstva predstavuje jadro systému. Nachádza sa tu server pre webovú komunikáciu s frontend vrstvou, MQTT broker pre komunikáciu s IoT vrstvou a databáza pre perzistentné uloženie konfigurácie systému a nameraných údajov. Rovnako tak sa tu nachádza server pre uchovávanie binárnej formy firmvéru pre komunikačné moduly.

Backend vrstva zabezpečuje automatizáciu procesu varenia piva. Táto automatizácia je dosiahnutá jednorazovým nahraním “receptu” - algoritmu ovládania (nastavenia výstupov) jednotlivých pripojených zariadení (komponentov pivovaru), ako napríklad beh motora, zapnutie ohrevu alebo pridania suroviny zo zásobníka otočením servo motora.

Frontend vrstva

Frontend vrstva slúži pre vizualizáciu aktuálneho stavu pivovaru a jeho jednotlivých komponentov (na spôsob SCADA systémov) ako aj pre vytváranie receptu pre automatické varenie piva a konfigurácie systému - zoznamu pripojených zariadení.

 

 

Návrh HW prepojenia

 

Entitno-relačný model SQL databázy

• MODULE
  • tabuľka modulov pripojených do systému
  • každý modul má unikátnu MAC adresu, ktorou sa identifikuje voči BE. Táto adresa je rovnako použitá pre adresáciu modulu.
  • stĺpec MAC má UNIQUE constraint
• MODULE_DEVICE_TYPE
  • tabuľka podporovaných modelov zariadení
  • polia manufacturer (napr. Forin) a model (napr. H300-OD75S2G) sú informačné
  • položka code (napr. VFD_H300) predstavuje unikátny kód typu modulu, teda podporovaného modelu zariadenia
  • každý model zariadenia komunikuje nejakým spôsobom (položka FK_PROTOCOL)
  • kombinácia manufacturer a model má UNIQUE constraint
  • stĺpec code má UNIQUE constraint
• DEVICE_TYPE_DATAPOINT
  • tabuľka dátových bodov každého podporovaného zariadenia
  • každý dátový bod má názov, napr. názov meranej veličiny (napr. temperature)
  • niektoré dátové body majú jednotky, napr. % (niektoré veličiny sú bezrozmerné, napr. stavový kód zariadenia)
  • položka legend predstavuje písomný opis dátového bodu (napr. na čo slúži - čo predstavuje, prípadne aké hodnoty môže nadubúdať)
  • položka code predstavuje unikátny (v rámci jedného modelu zariadenia) kód dátového bodu zariadenia (napr. SPEED)
  • položka writable určuje, či je možné hodnotu dátového bodu prepísať (či jej prepísanie spustí nejakú akciu). Napr. nameranú hodnotu teploty nemá zmysel prepísať, ale natočenie servo motora áno.
  • kombinácia FK_MODULE_DEVICE_TYPE a name má UNIQUE constraint
  • kombinácia FK_MODULE_DEVICE_TYPE a code má UNIQUE constraint
  • položka writable má default hodnotu FALSE
• DEVICE
  • záznamy v tejto tabuľke reprezentujú konkrétne fyzické zariadenia v systéme
  • každé zariadenie je pripojené prostredníctvom určitého modulu
  • položka UUID predstavuje unikátny globálny identifikátor zariadenia v rámci celého systému
  • položka address predstavuje adresu zariadenia (napr. adresa na zbernici, GPIO pin, MAC adresa, atd.)
  • položka poll_rate predstavuje časový interval v sekundách pre pravidelné získavanie hodnôt zo zariadenia. Pri zariadeniach, ktoré komunikujú asynchrónne je táto položka nevyužitá (má hodnotu NULL).
  • stĺpec UUID má UNIQUE constraint
• PROTOCOL
  • tabuľka (číselník) všetkých komunikačných protokolov podporovaných v systéme
  • položka name predstavuje názov protokolu (napr. Modbus-RTU)
  • zariadenia komunikujúce prostredníctvom analógového alebo binárneho výstupu majú uvedený protokol GPIO
  • stĺpec name má UNIQUE constraint
  • položka address_datatype predstavuje dátový typ adresy pre daný protokol (napr. pre Modbus-RTU je dátový typ adresy uint8). Je to cudzí klúč do číselníka DATATYPE.
• DATATYPE
  • číselník možných dátových typov
  • číselník sa môže využívať na FE pre výber formuláru pre používateľský vstup, alebo pri posielaní konfigurácie na modul

Komunikácia

MQTT API

API smerom k BE

Nadpis určuje topic MQTT správy.

MODULE_ID

{  "module_mac": "[MODULE_MAC]",  "module_type": "[MODULE_TYPE_CODE]"}

Táto správa sa posiela automaticky pri spustení modulu, alebo ako odpoveď na požiadavku “module_discovery“. Taktýmto spôsobom sa zabezpečí, že BE aplikácia bude mať vždy aktuálny zoznam pripojených modulov, pričom moduly bude možné pridávať za behu a bez potreby konfigurácie na strane BE (okrem konfiguračného súboru nahratého používateľom, ktorý je ale spoločný pre všetky moduly).

MODULE_DISCONNECT

{  "module_mac": "[MODULE_MAC]"}

Táto správa predstavuje MQTT závet. Odošle sa v prípade násilnej straty spojenia medzi modulom a MQTT brokerom.

MODULE_CONFIG_UPDATE

{  "module_mac": "[MODULE_MAC]",  "config_hash": "[MD5_HASH]"}

Táto správa sa odosiela ako odpoveď na správu typu [MODULE_MAC]/SET_CONFIG. Správa obsahuje MD5 hash konfigurácie príslušného modulu pre overenie správnosti prijatej konfigurácie.

VALUE_UPDATE

{  "module_mac": "[MODULE_MAC]",  "values": {    [DEVICE_UUID]": {        "[DATAPIONT_CODE]": 25.5,        "[DATAPIONT_CODE]": "value",        "[DATAPIONT_CODE]": true,        ...    },    ...  }}

Táto správa sa odosiela asynchrónne, pri každej zmene hodnoty dátového bodu zariadenia. Správa môže obsahovať viacero hodnôt dátových bodov naraz (napríklad v prípade, že sa zo zariadenia číta hodnota viacerých dátových bodov naraz) a viacero zariadení (napríklad v prípade, že sa naraz čítajú hodnoty z viacerých zariadení), aby sa predišlo zbytočnému oneskoreniu a zhusťovaniu premávky.

REQUEST_RESULT

{  "module_mac": "[MODULE_MAC]",  "sequence_number": [REQUEST_SEQUENCE_NUMBER],  "result": "[OK/ERROR]",  "details": "[ERROR_MESSAGE]"}

Táto správa predstavuje odpoveď na vybrané požiadavky zo strany BE. Položka “sequence_number” obsahuje kópiu hodnoty tejto položky v požiadavke. Položka “result” obsahuje informáciu o výsledku operácie: ak pri spracocvaní požiadavky došlo k chybe je hodnota tejto položky “ERROR” a správa môže obsahovať položku “details” obsahujúcu stručný textový popis chyby. V opačnom prípade (ak spracovanie požiadavky prebehlo v poriadku) má položka “result” hodnotu OK a správa neobsahuje položku “details”. Odpoveď na requesty od BE [MAC]/UPDATE_FW, [MAC]/SET_VALUE a [MAC]/REQUEST

API smerom k modulom

Nadpis určuje topic MQTT správy. Vybrané typy požiadaviek obsahujú položku “sequence_number” predstavujúcu identifikátor komunikačnej sekvencie požiadavka na modul / odpoveď z modulu. Každá odpoveď modulu na tieto požiadavky bude obsahovať rovnaký identifikátor.

ALL_MODULES

Správy typu ALL_MODULES obsahujú požiadavky, ktoré sa majú vykonať na všetkých pripojených moduloch súcasne.

{  "request": "module_discovery"}{  "request": "stop",  "sequence_number": [UINT16_NUMBER]}

Správa typu “stop” prepne modul do režimu, kedy naďalej prijíma a reaguje na MQTT komunikáciu, ale nevykonáva žiadnu akciu ani merania a teda neposiela ani telemetriu. Rovnako tak nastaví všetky výstupy do predvolených stavov.

{  "request": "start",  "sequence_number": [UINT16_NUMBER]}

Požiadavka pre prechod stavu konkrétneho modulu zo stavu “stop” do aktívneho stavu podľa jeho poslednej konfigurácie.

[MODULE_MAC]/SET_CONFIG

{  "[DEVICE_UUID]": {    "address": [ADDRESS], // e.g. for 1-Wire and Modbus address is unit id, for servo address is pin number etc.    "poll_rate": [POLL_RATE] // poll rate in seconds  },  ...}

Táto správa obsahuje konfiguráciu pre daný modul vo forme mapovania adries a identifikátorov zariadení v databáze na BE. Okrem toho obsahuje údaj pre nastavenie intervalu čítania hodnôt z pripojených zariadení. Tento interval je samostatný pre každé zariadenie.

[MODULE_MAC]/SET_VALUE

{  "device_uuid": "[DEVICE_UUID]",  "datapoint": "[DATAPOINT_CODE]",  "value": 0.5,  "sequence_number": [UINT16_NUMBER]}

Správa predstavujúca požiadavku pre nastavenie hodnoty dátového bodu zariadenia (napríklad natočenie servo motora).

[MODULE_MAC]/UPDATE_FW

{  "version": "0.2.3",  "sequence_number": [UINT16_NUMBER]}

Správa predstavujúca požiadavku pre stiahnutie a inštaláciu konkrétnej verzie aktualizácie firmvéru modulu. Po obdržaní tejto správy modul stiahne z BE binárny súbor firmvéru a spustí aktualizáciu.

[MODULE_MAC]/REQUEST

Správy tohto typu obsahujú jednoduchú požiadavku pre konkrétny modul. Ich význam je rovnaký ako pri topicu ALL_MODULES.

{  "request": "start",  "sequence_number": [UINT16_NUMBER]}{  "request": "stop",  "sequence_number": [UINT16_NUMBER]}

Moduly

Modul pre frekvenčný menič H300

Popis:

Modul je určený pre komunikáciu s frekvenčným meničom pre ovládanie motora miešadla. Komunikácia modulu s frekvenčným meničom je zabezpečená pomocou prevodníka logiky TTL na RS485. S týmto prevodníkom je možné komunikovať prostredníctvom rozhrania UART, avšak je nutná obojsmerná konverzia logických úrovní medzi 3.3 V a 5 V. Okrem samotného rozhrania UART sú použité dva riadiace signály: DE a RE. Protokol pre komunikáciu s frekvenčným meničom je Modbus-RTU, pričom modul má na zbernici rolu master a frekvenčný menič má rolu slave.

Výrobca: Forin.sk
Model: H300-OD75S2G
Module type (code): VFD_H300
Napájanie shieldu: 5V
Komunikácia s TTL / RS485 prevodníkom: UART 5V + DE a RE riadiace signály
Komunikácia s frekcenčným meničom: Modbus-RTU

Dátové body (datapoints):

Datapoint name	Datapoint code	Units	Writable	Description
Speed	SPEED	% * 100	true	Used to set frequency in percentage (two decimals precision) of maximum allowed frequency. Sign dependent on rotation direction. Possible values: <-10000,10000> for -100,00% - 100.00%.
Motion setting	SET_MOTION		true	Write-only datapoint used to control motor motion. Possible values: 1 - forward, 2 - reverse, 3 - forward jogging, 4 - reverse jogging, 5 - break-free stop, 6 - stop using breaks, 7 - error reset.
Motion state	GET_MOTION		false	Used to get motion state. Possible values: 1 - running forward, 2 - running reverse, 3 - stop
Statecode	STATE		false	Used to determine error state of VFD. Possible values: 0000: ok 0001: reserved 0002: overcurrent during acceleration 0003: overcurrent during deceleration 0004: overcurrent during constant speed 0005: overvoltage during acceleration 0006: overvoltage during deceleration 0007: overvoltage during constant speed 0008: control voltage dropout 0009: undervoltage 000A: VFD overdrive 000B: motor overdrive 000C: input phase dropout 000D: output phase dropout 000E: power module overheating 000F: external error 0010: communication error 0011: contactor error 0012: current detection error 0013: Autotunning error 0014: encoder or PG card error 0015: VFD EEPROM error 0016: VFD hardware error 0017: motor ground shortcut 0018: reserved 0019: reserved 001A: accumulative run time reached 001B: user input error 1 001C: user input error 2 001D: accumulative input voltage connection time reached 001E: zero load 001F: PID regulator feedback lost 0028: pulse control current limit violated 0029: runtime motor switch error 002A: speed error toleration violated 002B: motor speed limit violated 002D: motor overheating 005A: encoder setting error 005B: encoder disconnected 005C: init position error 005E: speed feedback error.
Main frequency	MAIN_FREQUENCY	Hz * 100	false	Used to read actual main frequency. Possible values: <0,+/- MAXIMAL_ALLOWED_MAIN_FREQENCY> (dependent on rotation direction).
Auxiliary frequency	AUX_FREQUENCY	Hz * 100	false	Used to read actual aux frequency. Possible values: <0,+/- MAXIMAL_ALLOWED_AUX_FREQENCY> (dependent on rotation direction).

Schéma zapojenia:

Fotodokumentácia zapojenia:

Na veľkej prototypovacej doske sa nachádza jadro modulu - vývojový kit ESP32. a prevodník logiky TTL / RS485, vpravo je frekvenčný menič.

 

Modul pre teplomer ds18b20

Popis:

Modul pre meranie teploty z teplomerov typu ds18b20. Modul podporuje viacero zapojených teplomerov na jednu 1-Wire zbernicu. Komunikácia backendu s modulom je prostredníctvom MQTT správ. Komunikácia modulu s teplomermi je po 1-wire zbernici.

Výrobca: Maxim Integrated
Model: ds18b20
Module type (code): DS18B20
Napájanie ds18b20: 3,3V
Komunikácia s ds18b20: 1-Wire

Datapoint:

temperature (datapoint code - TEMP): teplota v stupňoch celzia

Formát adresy:

• string 8 bajtov oddelených medzerou
• príklad: 28 84 54 79 97 04 03 12
• každý senzor ds18b20 má výrobcom nastavenú 1-wire adresu

Schéma zapojenia:

• použiť 4.7kΩ rezistor
• 1-wire zbernicu zapojiť na ESP32 pin D4 (GPIO4)
• schéma zapojenia zobrazuje 2 ds18b20 teplomery

MQTT správa pre nastavenie konfigurácie:

SET_CONFIG:
-nastavenie konfigurácie modulu na 2 teplomery s danými adresami a poll_rate

{
"Dev1": {
"address": "28 84 54 79 97 04 03 12",
"poll_rate": 20
},
"Dev2": {
"address": "28 B7 97 79 97 15 03 E2",
"poll_rate": 10
}
}

Foto modulu a 2 pripojených teplomerov:

 

Modul pre relé hw-655

Popis:
Modul je určený pre ovládanie relé, ktoré zapína a vypína ohrev, prípadne iné komponenty. Komunikácia backendu s modulom je zabezpečená MQTTsprávami, komunikácia modulu so shieldami pre jednotlivé relé je zabezpečená rozhraniami UART. Modul podporuje 1-3 relé, ktoré sú pri zapnutí modulu defaultne vypnuté.

Výrobca: HONG WEI
Model: hw-655
Module type (code): HW-655
Napájanie relé shieldu: 5V
Komunikácia s relé shieldom: UART

Datapoint:

status (datapoint code - STATUS): nadobúda hodnoty true - zopne obvod (zapnutie výhrevu), false - rozpojí obvod.

Formát adresy:
Adresa určuje číslo UART rozhrania na module esp32.

• povolené hodnoty sú: 0, 1, 2
• 0 - Serial 0 (piny TX0 - GPIO1, RX0 - GPIO3)
• 1 - Serial 1 (piny TX1 - GPIO18, RX1 - GPIO5)
• 2 - Serial 2 (piny TX2 - GPIO17, RX2 - GPIO16)

Schéma zapojenia:

Spínaný obvod treba zapojiť do portov NO a COM na shielde hw-655. To zabezpečí, že spínaný obvod je defaultne rozpojený.
Schéma zobrazuje príkladné zpojenie 2 relé na modul.

 

MQTT správy pre nastavenie konfigurácie a zopnutie/rozopnutie relé:

SET_CONFIG:
-nastavenie 2 relé s UUID Dev1 a Dev2, uart rozhraniami 1 a 2 a poll_rate 2 a 4.

{
"Dev1":{
"address": 1,
"poll_rate": 2
},
"Dev2": {
"address": 2,
"poll_rate": 4
}
}

SET_VALUE:

-zopnutie obvodu (zapnutie výhrevu) pre relé Dev1

{
"device_uuid":"Dev1",
"datapoint": "STATUS",
"value": true,
"sequence_number": 65
}

Foto modulu a 1 pripojeného relé:

Na ľavej strane prototypovacej dosky sa nachádza 5V zdroj pre napájanie relé. Na pravej je modul - esp32. Namiesto zeleného a šedého káblu vychádzajúcich z relé sa pripojí obvod ktorý chceme spínať.

 

Modul pre servo motor S05NF_STD

Popis

Modul pre servo motor je na ovládanie jedného alebo viacerých servo motorov, pre manipuláciu so zásobníkmi pre suroviny. Počet možných pripojených motrov je závislí od dostupných dátových pinov na ESP32 module. Komunikácia o systémov (dataflow) resp. backendom je prostredníctvom MQTT protokolu.

Výrobca: Sparkfun
Model: S05NF STD
Module type (code): ROB-10333

Datapoint:

Názov datapointu	kód datapointu	jednotka	zapisovateľné	popis
uhlová pozícia	ANGLE	stupne	true	Nastaví pozíciu servo na daný uhol. Nadobúda hodnoty <0, 180>

Formát adresy:
Adresa určuje číslo dátového pinu na module ESP32.

Schéma zapojenia

Servo motor treba zapojiť do ESP32 napájacích pinov VIN a GND spolu s ľubovolným dátovým pinom D13 napríklad. Schéma zobrazuje príkladné zapojenie 1 servo motora na modul.

 

MQTT správy pre nastavenie konfigurácie a otočenie servo motora

SET_CONFIG

Nastavenie 1 servo motora s UUID “servo-dev-uuid”, dátovým pinom 13 a poll_rate 2.

{
"servo-dev-uuid":{
"address": 13,
"poll_rate": 2
},
}

SET_VALUE

Nastavenie uhlu otočenia servo motora “servo-dev-uuid“ na 89 stupňov.

{
"device_uuid":"servo-dev-uuid",
"datapoint": "ANGLE",
"value": 89,
"sequence_number": 12345
}

Fotografia modulu a 1 pripojeného servo motora:

Servo motor S05NF_STD je zapojené k modulu ESP32 do rovakých pinov ako je znázornené v schéme zapojenia i.e. VIN, GND a D13.