Koji-Fermenter selbst bauen: Präzise Temperatur- und Feuchtesteuerung mit ESP32 und Raspberry Pi

Fermentation braucht bei einfachen Produkten wenig Technik – ein Glas Sauerkraut reguliert sich praktisch von selbst. Anspruchsvollere Fermente wie Koji für die Herstellung von Miso, Sojasauce oder Tempeh stellen dagegen konkrete Anforderungen: über mehrere Tage konstante, gezielt einstellbare Temperatur und Luftfeuchte. Genau das leistet ein selbst gebauter Fermentationsschrank mit einem ESP32 als Steuerung und einem Raspberry Pi als Dashboard.

Dieser Beitrag zeigt den kompletten Aufbau: welche Bauteile nötig sind, wie Heizung, Lüftung und Sensorik zusammenspielen, welche typischen Fallstricke beim Selbstbau auftreten – und vor allem, wie eine Regelung aussieht, die das Ferment sauber auf Temperatur hält, ohne über das Ziel hinauszuschießen. Am Ende läuft der Fermenter ein hinterlegtes Temperaturprofil autonom ab, auch bei Strom- oder Netzwerkausfall. Der Fokus liegt auf nachvollziehbaren Entscheidungen – jede Bauteilwahl und jede Zeile Regelungslogik hat einen Grund.

Warum Fermentation eine präzise Steuerung braucht

Koji: Wie das Temperaturprofil die Enzyme steuert

Das Paradebeispiel für kontrollierte Fermentation ist Koji – mit dem Edelschimmel Aspergillus oryzae bewachsener Reis oder Gerste. Koji ist die Grundlage für Miso, Sojasauce, Sake, Amazake und viele weitere Produkte. Für den technisch interessierten Hobbyisten ist Koji deshalb spannend, weil sich über das Temperaturprofil steuern lässt, welche Enzyme der Pilz bevorzugt bildet:

• Kühler geführt (rund 30 °C) entsteht eher proteasereicher Koji – gut für herzhafte, eiweißspaltende Anwendungen wie Sojasauce.
• Wärmer geführt überwiegen die Amylasen, die Stärke zu Zucker abbauen und für Süße sorgen – erwünscht etwa bei Amazake.

Ein definiertes Temperaturprofil, welches die konkreten Wachstumsphasen des Pilzes berücksichtigt, ist also kein Selbstzweck, sondern beeinflusst das Ergebnis direkt.

Warum der Backofen als Fermenter an Grenzen stößt

Im Hobbybereich behilft man sich oft mit dem Backofen und eingeschalteter Backofenlampe. Das funktioniert grundsätzlich, hat aber klare Nachteile: Die Temperatur schwankt stark, lässt sich nicht gezielt einstellen, und ein reproduzierbares Profil über 48 Stunden zu fahren wird zur Handarbeit mit Thermometer und Notizzettel. Zudem fehlt jede Luftfeuchte-Kontrolle und jeder definierte Luftaustausch – beides ist für Koji relevant. Eine falsch eingestellte Luftfeuchte und Temperatur kann eine Fehlkontamination mit Bakterien verursachen, den Pilz durch Sporulation bitter werden lassen oder die Enzymausbeute erheblich verringern, weshalb Hobbyprojekte häufig scheitern. Eine dedizierte Steuerung löst genau diese drei Punkte: konstante Temperatur, definierte Feuchte, kontrollierte Belüftung.

Was du für den Nachbau brauchst

Die folgende Übersicht listet die zentralen Bauteile. Vieles ist bewusst einfach und günstig gehalten.

Steuerung und Sensorik

• ESP32 – Mikrocontroller mit WLAN, steuert den gesamten Fermenter.
• BME280 – misst Temperatur und Luftfeuchte der Kammerluft (I²C).
• DS18B20 – wasserfeste Temperatursonde für die Kerntemperatur im Ferment (1-Wire).
• 1602-LCD mit I²C-Backpack – lokale Anzeige und Menü.
• Drehencoder mit Taster – Bedienung des Menüs.

💡 Hinweis zur ESP32-Variante: Der Beispielcode nutzt die Pin-Belegung des klassischen ESP32. Andere Varianten mit WLAN – etwa der ESP32-C6 – laufen ebenfalls, haben aber eine abweichende GPIO-Nummerierung. Die Pin-Zuordnung ist dann in der Konfiguration einmalig anzupassen.

Heizung, Lüftung, Aktorik

• IP67-Heizmatte aus der Pflanzenanzucht – wasserfest, niedrige Wattzahl.
• Olimex PWR-Switch – über 3–5 V schaltbares Relais als Zwischenstecker für die Heizmatte.
• Zwei PWM-Lüfter (60 mm) – Zu- und Abluft. 4-polige Modelle empfohlen, etwa der Noctua NF-A6x25 5V PWM.
• Optional: N-MOSFET für zweipolige Lüfter, plus 100-nF-Kondensatoren und 10-kΩ-Widerstände (siehe „Elektronik-Fallstricke”).

Stromversorgung

• Universal-Steckernetzteil 3–12 V – versorgt ESP32 und Lüfter.
• Offizielles Raspberry-Pi-USB-C-Netzteil – falls du das Dashboard nutzt.

Gehäuse und Dashboard

• Styroporbox – die Isolierung und Kammer.
• Raspberry Pi – hostet das Web-Dashboard (optional, aber komfortabel).
• Optional: DS3231 RTC – Echtzeituhr für den vollständig WLAN-freien Betrieb (dazu mehr im letzten Abschnitt).

💡 Tipp: Wer keinen Wert auf ein Dashboard legt, kommt komplett ohne Raspberry Pi und ohne WLAN aus – der ESP32 regelt eigenständig. Der Raspberry Pi ist eine additive Komfort-Ebene, kein Muss.

Der Aufbau: Box, Heizung und Luftführung

Die Isolierbox

Herzstück ist eine simple Styroporbox. Sie isoliert hervorragend, lässt sich leicht reinigen und ist günstig – energiesparend und hygienisch zugleich. Für den kontrollierten Luftaustausch sorgen zwei Lüfter: einer für Zuluft, einer für Abluft.

Heizung: IP67-Heizmatte und ein schaltbares Relais

Geheizt wird mit einer IP67-Heizmatte aus der Pflanzenanzucht. Diese Wahl hat mehrere Vorteile: Die Matten sind wasserfest – wichtig in feuchter Umgebung – und ihre niedrige Wattzahl macht eine Überhitzung praktisch unmöglich. Sie könnten gefahrlos im Dauerbetrieb laufen. Nach oben sind sie bis etwa 60 °C nutzbar, womit der Fermenter auch für wärmere Anwendungen wie Garum taugt.

Ein unscheinbares, aber wichtiges Detail ist die Ansteuerung. In Deutschland ist als fertiger, schaltbarer Zwischenstecker vor allem der Olimex PWR-Switch verfügbar – ein über 3–5 V schaltbares Relais. Entscheidend: Es ist ein mechanisches Relais, kein Solid-State-Relais (SSR). Das klingt nach einem Detail, prägt aber später das gesamte Regelungsprinzip – ein mechanisches Relais darf nicht im Sekundentakt schalten, da das seine Lebensdauer erheblich einschränkt.

Die Lüfter – und warum zweipolige Lüfter tückisch sind

Die Lüfter laufen in der vorliegenden Version über einen N-MOSFET mit PWM. Wer nachbaut, sollte allerdings direkt PWM-fähige (4-polige) Lüfter kaufen: Sie nehmen das Steuersignal unmittelbar entgegen, der MOSFET entfällt, die Platine wird einfacher, und sie liefern zusätzlich ein Tacho-Signal – das in der vorliegenden Version allerdings nicht ausgelesen wird.

Der Grund ist eine Tücke, die man leicht übersieht: Klassische zweipolige Lüfter lassen sich eigentlich nicht sauber per PWM steuern. Zerhackt man ihre Versorgungsspannung mit der üblichen hohen PWM-Frequenz (oft 25 kHz), kommt die interne Kommutierungs-Elektronik des bürstenlosen Motors durcheinander – der Lüfter läuft dann nicht sauber oder nur auf Vollgas.

Der Trick ist eine bewusst sehr langsame PWM (hier rund 100 Hz): Bei dieser niedrigen Frequenz sieht der Lüfter ein schnelles Ein-und-Aus, dessen Mittelwert seine eigene Massenträgheit zu einer fließenden Drehzahl glättet. So lässt sich auch ein einfacher Lüfter über einen erstaunlich weiten Bereich regeln. Echte vierpolige Lüfter haben dieses Problem nicht, weil sie für die Drehzahl einen separaten Steuereingang mitbringen. Wer auf einen zweipoligen Lüfter setzt, sollte zu Beginn prüfen, welcher Mindestwert für das PWM-Signal nötig ist, damit der Lüfter überhaupt anläuft (typischerweise 10–20 %).

💡 Wichtig beim Umstieg auf 4-polige Lüfter: Die 100 Hz sind ausdrücklich der Workaround für zweipolige Lüfter. Ein echter PWM-Lüfter bekommt konstante Versorgungsspannung, das Steuersignal geht direkt an seinen PWM-Eingang (Pin 4) – und die Frequenz gehört dann auf die üblichen ~25 kHz gesetzt (im Code FAN_PWM_FREQ). Der MOSFET entfällt. Den Tacho-Pin (Pin 3) kann man unbeschaltet lassen: Er ist nur ein Drehzahl-Ausgang, der Lüfter läuft auch ohne ihn völlig normal – man verzichtet lediglich auf die Drehzahl-Rückmeldung.

Sensorik: Warum zwei Temperatursensoren?

Die Sensorik ist bewusst doppelt ausgelegt, weil zwei verschiedene Größen gemessen werden müssen:

• Der BME280 misst Temperatur und Luftfeuchte der Kammerluft. Er ist die schnelle, aber „äußere” Größe.
• Der DS18B20 sitzt als wasserfeste Sonde direkt im Ferment und liefert die Kerntemperatur – die Größe, auf die es beim Ergebnis wirklich ankommt.

Diese Trennung ist zentral für die Regelung: Die Kammerluft reagiert schnell auf die Heizung, das Ferment folgt träge nach. Wer nur die Luft misst, regelt am eigentlichen Ziel vorbei.

Bedienung über LCD und Drehencoder

Bedient wird alles lokal über ein 1602-LCD und einen Drehencoder mit Taster. Das Menü ist vollständig über Drehen und Drücken navigierbar – Heiz- und Kühlparameter, Feuchte-Grenzen, Lüfterleistung und die Betriebsart lassen sich direkt am Gerät einstellen, ohne dass ein Netzwerk nötig ist.

Elektronik-Fallstricke beim Selbstbau

Auf dem Steckbrett funktionierte vieles, auf der selbst gelöteten Platine fängt es dann gerne an zu zicken – ein Klassiker. Zwei Effekte sind typisch und lohnen die Erwähnung, weil sie Nachbauern Stunden sparen.

Übersprechen (Crosstalk) auf der DIY-Platine

Auf selbst gerouteten Platinen ist das Übersprechen zwischen Leitungen deutlich wahrscheinlicher als auf einer sauber gerouteten Industrieplatine. Die schnellen Schaltflanken von PWM und Relais koppeln kapazitiv in benachbarte Signalleitungen ein und lösten hier zum Beispiel am Drehencoder Phantom-Signale aus.

Die Lösung sind 100-nF-Kondensatoren von den empfindlichen Signalleitungen (Encoder, Sensor) gegen Masse. Zusammen mit dem Pull-up bilden sie einen kleinen Tiefpassfilter, der hochfrequente Störspitzen wegglättet, die echten – langsamen – Signale aber ungehindert durchlässt.

Floatende MOSFET-Gates beim Boot

Ein zweites Detail betrifft die MOSFET-Gates der Lüfter. Theoretisch hat der ESP32 interne Pull-down-Widerstände, praktisch taugen sie hier wenig: Mit rund 50 kΩ sind sie für ein MOSFET-Gate recht hochohmig und werden erst aktiv, wenn der Pin im Code konfiguriert ist. Während des Bootvorgangs „floatet” der Pin – und der Lüfter zuckt unkontrolliert. Externe Pull-down-Widerstände (z. B. 10 kΩ) halten das Gate zuverlässig auf Masse. Analog wird im Code als Allererstes der Relais-Pin auf seinen sicheren Aus-Pegel gesetzt, damit die Heizung während des Boots garantiert aus bleibt.

Die Software: MicroPython auf dem ESP32

Programmiert ist der Fermenter in MicroPython – zu großen Teilen iterativ mit KI-Unterstützung entwickelt und am realen Aufbau debuggt. MicroPython hat gegenüber C/C++ eine spürbar geringere Performance und wird deshalb von manchen kritisch gesehen. Für diesen Anwendungsfall ist der ESP32 aber mehr als ausreichend: Die Regelschleife tickt im 50-Millisekunden-Takt, der Chip ist dabei kaum ausgelastet. Im Gegenzug ist MicroPython angenehm zugänglich und lässt sich später nahezu unverändert auf einen Raspberry Pi portieren, der ebenfalls Python spricht – praktisch, weil das Dashboard auf genau dieser Sprache aufbaut.

Genutzt werden bewährte Bibliotheken: ein etablierter BME280-Treiber, eine verbreitete I²C-LCD-Bibliothek (für den PCF8574-Backpack) sowie die in MicroPython enthaltenen Module onewire und ds18x20 für den Temperaturfühler.

Typische Sensor-Fehler – und wie man sie abfängt

Sensoren liefern in der Praxis nicht nur saubere Werte. Zwei Fehlermodi waren besonders lehrreich, weil beide die CRC-Prüfung bestehen und damit als „gültig” durchgehen:

• DS18B20 liefert exakt 0,0 °C: Ein Read aus lauter Null-Bytes ist CRC-korrekt, aber physikalisch unsinnig. Für eine Heizungssteuerung ist das der gefährlichste Fehlermodus, denn 0 °C heißt „eiskalt, voll heizen”. Die Lösung war zweistufig: hardwareseitig ein 100-nF-Entkopplungskondensator direkt am Sensor, zwischen VDD und GND (die Stromspitze während der Messung brach kurz die Versorgung ein), softwareseitig ein Plausibilitäts-Check, der Werte nahe 0 °C verwirft und im Zweifel den letzten guten Wert hält oder die Heizung fail-safe abschaltet.
• BME280 liefert sprunghafte Ausreißer: Der Feuchte-/Temperatursensor lieferte gelegentlich für ein bis zwei Messungen feste Fehlwerte (etwa eine unrealistisch hohe Kammertemperatur und 100 % Feuchte), danach wieder korrekte Werte. Unbehandelt löst so ein Ausreißer eine unnötige Not-Belüftung aus. Abhilfe schafft ein Ratenfilter pro Messgröße: Springt ein Wert stärker als physikalisch möglich, wird er verworfen und der letzte gute Wert gehalten – ein echter, langsamer Anstieg passiert dagegen ungehindert.

Solche Filter sind kein Beiwerk, sondern Teil der Betriebssicherheit: Sie verhindern, dass eine einzelne Fehlmessung Heizung oder Lüfter falsch schalten lässt.

Das Regelungsprinzip: von der Hysterese zur Zieltemperatur-Regelung

Hier liegt der eigentliche Kern des Projekts – und der Teil, der am meisten Iteration gekostet hat.

Warum Hysterese statt punktgenauer Regelung

Geregelt wird nach dem Hysterese-Prinzip: Die Heizung schaltet beim Unterschreiten einer unteren Grenze ein und erst beim Überschreiten einer oberen Grenze wieder aus – nicht punktgenau auf einen einzelnen Sollwert. Dafür gibt es handfeste Gründe:

• Das Relais ist mechanisch (kein SSR). Punktgenaues Regeln würde es im Sekundentakt klackern lassen und binnen Wochen verschleißen. Eine Hysterese mit Mindest-Schaltpause schont es.
• Die Heizmatte ist extrem träge. Feinfühliges Nachregeln bringt wenig, wenn die Wärme ohnehin minutenlang nachläuft.
• Die Luftfeuchtemessung ist träge und nicht besonders präzise – eine breite Hysterese ist hier ehrlicher als Scheingenauigkeit.

Das Überschwing-Problem

Eine einfache Hysterese auf die Kerntemperatur hat allerdings eine Schwäche, die im Praxisbetrieb deutlich sichtbar wird: starkes Überschwingen beim Wechsel des Sollwerts.

Der Mechanismus dahinter ist eine Totzeit: Die Kammerluft heizt schnell auf, das Ferment folgt stark verzögert – gemessen lagen zwischen Kammer und Kern rund zehn Minuten, bei dickerer Substratschicht mehr. Bei einer reinen Bang-Bang-Regelung läuft die Heizung volle Leistung, bis der Kern das Ziel erreicht. Bis dahin ist die Kammer aber längst weit über das Ziel hinausgeschossen, und die gespeicherte Wärme drückt den Kern anschließend mehrere Grad zu hoch. In der Praxis lief die Kammer so weit weg, dass sie sogar die Übertemperatur-Abschaltung auslöste – mit unruhigem Pendeln als Folge.

Die Lösung: Zieltemperatur + drei Deltas + Kammer-Bremse

Statt absoluter Ein-/Aus-Schwellen wird die Heizung um eine Zieltemperatur und drei Deltas herum geregelt – alle auf messbaren Größen, ganz ohne aufwendiges Tuning:

• Ziel-T – die gewünschte Kerntemperatur (DS18B20).
• Delta „Kern” (klein, z. B. 0,5 °C) – die Heizung geht an, wenn der Kern um mehr als dieses Delta unter dem Ziel liegt, und bei Erreichen des Ziels wieder aus. Ein schmales Band bedeutet wenig Überschwingen.
• Delta „Boden” (z. B. 2 °C) – ein Fallback auf die Kammerluft: Fällt die Kammer zu weit unter das Ziel (etwa nach kräftiger Kühlung), wird nachgeheizt. Das fängt ein Unterschwingen ab.
• Delta „Deckel” (z. B. 2 °C) – die entscheidende Neuerung, eine rastende Kammer-Überschwing-Bremse: Steigt die Kammer über Ziel + Deckel, wird die Heizung gesperrt und erst wieder freigegeben, wenn die Kammer zurück auf Ziel-Niveau ist.

Die Idee dahinter ist eine Form der Begrenzungsregelung: Man deckelt die schnelle, gut messbare Größe (Kammerluft), um die langsame Zielgröße (Kern) zu begrenzen. Weil die Kammer nie mehr als das Deckel-Delta über das Ziel darf, bleibt auch der Kern-Überschwinger auf etwa dieses Delta begrenzt – und zwar unabhängig davon, wie träge das Ferment ist. Ein zusätzliches Sicherheits-Gate schaltet die Heizung ohnehin ab, sobald der Kern sein Ziel erreicht.

Warum kein PID?

Naheliegend wäre ein klassischer PID-Regler. Für dieses System ist er aber unpraktisch: Die Totzeit zwischen Kammer und Kern hängt stark von der Substratdicke ab, und ein PID müsste für jede Beladung neu abgestimmt werden. Falsch getunt neigt er selbst zum Schwingen. Ein relais-schonender PID über Zeitproportionalität wäre technisch möglich, aber deutlich aufwendiger. Die Kammer-Bremse erreicht das eigentliche Ziel – begrenztes Überschwingen – ohne jedes Tuning und robust über alle Beladungen hinweg. Sie lebt zudem direkt auf dem ESP32 und wirkt damit in jedem Betriebsmodus, auch ohne Dashboard.

Totzone zwischen Heizen und Kühlen

Heizung und Kühlung (über die Lüfter) dürfen sich nicht gegenseitig blockieren. Würde der Lüfter bei „etwas zu warm” schon kühlen, während die Heizung noch nachheizt, hätte man ein teures Patt. Deshalb liegt zwischen Heiz- und Kühlschwelle bewusst eine Totzone: Erst wird nicht mehr geheizt, dann passiert eine Weile nichts, und erst bei echter Übertemperatur springt der Lüfter an.

Idle-Belüftung für den Sauerstoff

Dazu kommt eine Idle-Belüftung: Lief längere Zeit kein Lüfter, schaltet er trotzdem kurz ein. Der Grund ist Sauerstoff – der Schimmel atmet, verbraucht O₂ und produziert CO₂. Ein gelegentlicher Luftwechsel verhindert, dass das Ferment in seiner eigenen Atmosphäre erstickt.

Luftfeuchte: Warum ein feuchtes Tuch dem Vernebler überlegen ist

Naheliegend wäre, die Luftfeuchte aktiv per Ultraschall-Vernebler zu regeln. In der Praxis ist ein feuchtes Tuch die bessere Wahl – aus gleich mehreren Gründen:

• Vernebler erzeugen relativ große Tröpfchen und damit viel Kondensation; Überschwinger sind fast garantiert.
• Schlägt sich Kondensat auf dem BME280 nieder, hängt der Sensor bei 100 % relativer Feuchte fest – die Regelung wird blind.
• Gut geführter Koji produziert selbst reichlich Feuchtigkeit; oft reicht das passive Puffern über ein Tuch völlig aus.
• Vernebler sind in einer warm-feuchten Umgebung ein ernstes Kontaminationsrisiko – gerade hier will man keine ungebetenen Mikroben heranziehen.

Die Lüfter übernehmen die Feuchte-Regelung also passiv: Steigt die Feuchte über die obere Grenze, wird belüftet, bis sie wieder unter die untere Grenze fällt – dieselbe Hysterese-Logik wie bei der Temperatur.

Das Dashboard: Fernsteuerung per WLAN und Raspberry Pi

Lokale Bedienung am LCD ist für Einstellungen praktisch, für Langzeitläufe aber unkomfortabel. Deshalb bekommt der Fermenter ein Web-Dashboard, gehostet auf einem Raspberry Pi.

Architektur: ESP32 als Client, Raspberry Pi als Server

Die Aufteilung ist bewusst konservativ gewählt: Der ESP32 bleibt die Steuerung, der Raspberry Pi ist nur additiv. Konkret ruft der ESP32 alle paar Sekunden beim Pi ab (HTTP-Polling), sendet dabei seine Messwerte und erhält die aktuellen Sollwerte zurück. Alle Sicherheitsfunktionen – Übertemperatur-Abschaltung, Sensor-Ausfall-Erkennung, die Kammer-Bremse – laufen weiterhin lokal auf dem ESP32. Fällt der Pi aus, ändert das an der eigentlichen Regelung nichts.

Diese Trennung ist eine bewusste Design-Entscheidung: Ein Dashboard darf komfortabel sein, aber es darf nie zur Sollbruchstelle der Regelung werden.

Was das Dashboard kann

• Live-Kurven von Kern- und Kammertemperatur sowie Luftfeuchte, mit Aktivitätsbalken für Heizung und die einzelnen Lüfter-Gründe.
• Ein Profil-Editor, in dem sich mehrstufige Temperaturprofile zeichnen lassen – etwa „nach 24 Stunden die Zieltemperatur anheben”.
• Eine Profil-Bibliothek zum Speichern und Wiederverwenden benannter Profile.
• CSV-Export der Messdaten (im deutschen Excel-Format) und ein Kalender-Export der Profilschritte.
• Steuerung von Logging, Plot-Reset und ein sauberes Herunterfahren des Pi.

Autonom auch ohne Dauerverbindung

Ein Dashboard ist nur dann eine gute Ergänzung, wenn es keinen neuen Single Point of Failure einführt. Deshalb kann der Fermenter ein Profil komplett autonom abfahren.

Beim Start eines Profils überträgt der Raspberry Pi die Kurve samt absolutem Startzeitpunkt in den Flash-Speicher des ESP32. Solange der Pi erreichbar ist, gibt er den Takt vor. Fällt er aus – oder wird bewusst abgeschaltet – rechnet der ESP32 die aktuellen Sollwerte selbst aus seiner gespeicherten Kurve. Kommt der Pi zurück, übernimmt wieder er; ein Versionsabgleich sorgt dafür, dass Änderungen am Profil automatisch nachgezogen werden.

Zeit ohne Cloud: NTP vom Router – oder eine RTC für den WLAN-freien Betrieb

Damit der ESP32 ein zeitbasiertes Profil auch ohne Pi korrekt fortsetzen kann, braucht er eine verlässliche Uhrzeit. Standardmäßig holt er sie sich per NTP: Der eigene Router beantwortet NTP-Anfragen in aller Regel selbst, ganz ohne Internet und ohne Cloud-Dienst. Ist der Router nicht erreichbar, dient ein öffentlicher Zeitserver als Rückfall.

Wer den Fermenter ganz ohne WLAN betreiben möchte, ergänzt eine DS3231 RTC – eine batteriegepufferte Echtzeituhr. Sie liefert die Uhrzeit lokal, sodass der ESP32 Profile auch ohne jede Netzwerkanbindung zeitrichtig abfahren kann. (Ein Hinweis aus der Praxis: Für den 3,3-V-I²C-Bus des ESP32 sollte man zur DS3231 greifen und nicht zur älteren DS1307, die 5 V erwartet.)

Fazit

Ein präziser Fermenter ist kein Hexenwerk – aber die interessanten Entscheidungen stecken im Detail. Die Bauteile sind bewusst günstig und robust: Styroporbox, IP67-Heizmatte, ein schaltbarer Zwischenstecker, zwei Lüfter, zwei Sensoren und ein ESP32. Der eigentliche Gewinn liegt in der Software: eine Regelung, die die Trägheit des Systems respektiert, das Überschwingen über eine Kammer-Bremse konsequent begrenzt, einzelne Fehlmessungen sauber abfängt – und ein Profil auch bei Strom- oder Netzwerkausfall autonom zu Ende fährt. Das Dashboard auf dem Raspberry Pi macht das Ganze komfortabel, bleibt aber bewusst optional.

Der komplette Quellcode ist unter MIT-Lizenz auf GitHub verfügbar – Firmware, Dashboard und Dokumentation:
github.com/hobblefuzz/FermentiMcFermentiFace

Häufige Fragen (FAQ)

Welcher Mikrocontroller eignet sich für einen Fermenter?
Ein ESP32 ist ideal: Er bringt WLAN mit, hat genug Rechenleistung für die Regelschleife und lässt sich bequem in MicroPython programmieren.

Kann der Fermenter ohne WLAN und ohne Cloud laufen?
Ja. Die komplette Regelung läuft lokal auf dem ESP32. Für zeitbasierte Profile ohne WLAN ergänzt man eine DS3231 RTC als lokale Uhr; das Dashboard und der Raspberry Pi sind optional.

Wozu zwei Temperatursensoren?
Der BME280 misst die schnelle Kammerluft (und die Feuchte), der DS18B20 die träge Kerntemperatur im Ferment. Die Regelung braucht beide: den Kern als Ziel, die Kammer für die Überschwing-Bremse.

Warum eine Heizmatte statt Glühbirne oder Heizdraht?
Eine IP67-Heizmatte ist wasserfest, niederohmig und träge – dadurch praktisch überhitzungssicher und ideal für Dauerbetrieb in feuchter Umgebung.

Welche Temperatur braucht Koji?
Grob um 30 °C. Kühler geführt entsteht eher proteasereicher Koji, wärmer geführt überwiegen die stärkeabbauenden Amylasen. Das genaue Profil bestimmt den Charakter des Ferments.

Wie verhindert man das Überschwingen der Temperatur?
Über eine Kammer-Überschwing-Bremse: Die schnelle Kammerluft wird auf „Ziel + Delta” gedeckelt, wodurch der träge Kern nur um dieses Delta übersteuern kann – unabhängig von der Beladung und ohne PID-Tuning.

Braucht man einen Luftbefeuchter?
In der Regel nicht. Ein feuchtes Tuch puffert die Feuchte passiv, vermeidet Kondensation am Sensor und senkt das Kontaminationsrisiko. Gut geführter Koji bringt zudem selbst viel Feuchtigkeit mit.

Was passiert bei einem Stromausfall?
Der ESP32 speichert die Profilkurve samt Startzeit im Flash. Nach einem Neustart holt er sich die Uhrzeit und setzt das Profil an der korrekten Stelle fort. Auch der Raspberry Pi nimmt einen laufenden Lauf nach einem Neustart wieder auf.

Ist MicroPython schnell genug?
Für diesen Anwendungsfall problemlos. Die Regelschleife läuft im 50-Millisekunden-Takt, der ESP32 ist dabei kaum ausgelastet. Der Zugewinn an Entwicklungs-Komfort überwiegt den Performance-Nachteil deutlich.