01 · Eigene Module
- ESP32-Module sprechen direkt miteinander — kein Router, kein WLAN-Passwort
- Sensoren frei gewählt: Präsenz, Temperatur, Feuchte, Rauch, Wetter
- Firmware selbst geschrieben, geflasht und geändert
// Gesellenstück D-001 — Konzept & Aufbau
Modulares
Smart Home
Eine eigene Zentrale auf dem Raspberry Pi 4, eigene Sensormodule über ESP-NOW, fremde Geräte über MQTT — eine Oberfläche, eine Datenbank, keine Hersteller-App. Diese Seite ist die Projektpräsentation: was festgelegt ist, wie es aufgebaut wird und wann es fertig sein muss.
ESP-NOW
MQTT
Python · FastAPI
SQLite
Raspberry Pi 4
SMD-WROOM · ESP32
in Entwicklung — gebaut wird noch nichts
03
eigene Module (A/B/C)
1200–1550 h
Zeitbudget
30.04.2027
Feature-Freeze
06/2027
Abgabe
// 01 — Überblick
Warum ein eigenes System
Fertige Smart-Home-Pakete funktionieren — bis man einen Sensor braucht, den es dort nicht gibt, oder bis das Herstellerkonto wegfällt. Dieses Projekt dreht den Weg um: zuerst die Zentrale und die Daten, dann die Geräte. Eigene Module liefern genau das, was gebraucht wird, fremde Geräte werden eingebunden statt nachgebaut.
02 · Fremde Geräte
- Shelly & WLED liefern MQTT ab Werk — die werden eingebunden, nicht ersetzt
- Ein Gateway übersetzt zwischen Funkwelt und Zentrale
- Alles landet in derselben Datenbank
03 · Eine Oberfläche
- Geräte beschreiben ihre Fähigkeiten — daraus entstehen die Widgets
- Web-UI auf Pi, Tablet-Kiosk und Modul C
- Keine zweite App, kein Cloud-Zwang (Home Assistant wurde bewusst verworfen, D-002)
| Bereich | Festlegung | Begründung |
|---|---|---|
| Zentrale | Raspberry Pi 4 | eine eigene Zentrale im Haus, alles bleibt lokal (D-001) |
| Eigene Module | ESP-NOW | Modul zu Modul ohne Router, kleine Datenpakete |
| Strecke Gateway → Pi | UART, JSON-Zeilen | seriell und lesbar, leicht zu debuggen |
| Fremde Geräte | MQTT | Shelly und WLED sprechen es ab Werk (D-013) |
| Software der Zentrale | Python · FastAPI · SQLite | API, Datenbank und Funk in einem Stack (D-014) |
| Oberfläche | Web-UI im Browser | läuft auf Pi, Tablet und Modul C (D-003) |
| Automatik | eigene Regel-Engine | Regeln liegen in der Datenbank, nicht im Code (D-004) |
| Hardware | ESP32-SMD-WROOM-Module | klein und direkt auf die eigene Platine (D-015) |
| Zugang | einfacher Login | keine Nutzerverwaltung, die niemand braucht (D-012) |
| Stand | Konzept & Entscheidungen | Hardware und Code folgen ab Herbst 2026 |
// 02 — System
Wie alles zusammenhängt
Vier Ebenen, ein Weg: Sensoren melden, das Gateway sammelt, die Zentrale speichert und entscheidet, die Oberfläche zeigt. Fremde Geräte stehen im gleichen Bild wie die eigenen Module — nur über einen anderen Transportweg.
Ebene 4Bedienung
UI-01Web-DashboardBrowser am Rechner
UI-02Kiosk-AnsichtTablet oder Display am Pi
UI-03Modul Cmobiles Touch-Terminal
Ebene 3Zentrale · Raspberry Pi 4
CORE-01FastAPI-BackendREST-Schnittstelle, WebSocket
CORE-02SQLiteGeräte, Räume, Messwerte
CORE-03Regel-EngineAutomationen aus der Datenbank
CORE-04MQTT-Anbindungfremde Geräte einbinden
Ebene 2Transport
TR-01ESP-NOWFunk zwischen Gateway und Modulen
TR-02UART 115200Gateway am Pi, JSON-Zeilen
TR-03MQTTBroker im eigenen Netz
Ebene 1Feld
GW-01GatewayESP32, sammelt alle Module
MOD-APräsenz & KlimaDecke, mit Rauchmelder (D-017)
MOD-BWetter außenTemperatur, Licht, Wind
MOD-CTerminalmobil, mit Akku
EXT-01Shelly & WLEDfremde Geräte über MQTT
Datensatz statt Spezialfall
- Jedes Gerät meldet seine Fähigkeiten: Messwert, Schalter, Batterie
- Die Oberfläche baut die Widgets aus diesen Fähigkeiten
- Ein neues Modul braucht deshalb keinen neuen Code
ESP-NOW für eigene Module
- direkte Verbindung — kein Router, kein WLAN-Passwort
- kurze Pakete reichen für Messwerte und Befehle
- das Gateway sitzt zentral, die Module sind nah dran
MQTT für fremde Geräte
- Shelly und WLED sprechen es ab Werk — kein Umbau
- der Broker läuft im eigenen Netz, nichts geht nach draußen
- weitere Geräte sind später schnell ergänzt
// 03 — Module
Drei eigene Module, ein Gateway
Die eigenen Module sind auf Aufgaben zugeschnitten statt auf Stückzahlen: eines für den Raum, eines fürs Wetter draußen, eines zum Bedienen. Das Gateway ist das Bindeglied zwischen Funkwelt und Zentrale. Gebaut ist noch keines davon — hier stehen die geplanten Fähigkeiten.
MOD-A · D-017
geplant
Raum & Sicherheit
Deckenmodul für den Raum: erkennt Präsenz, misst Temperatur und Luftfeuchte und wacht über einen Rauchmelder. Oben an der Decke stört es niemanden und sieht den ganzen Raum.
Sensorik: Präsenz · Temperatur · Feuchte · Rauch
Funk: ESP-NOW zum Gateway
MOD-B
geplant
Wetter außen
Außenmodul für die Daten, die drinnen fehlen: Temperatur, Helligkeit, Wind und Regen. Daraus entstehen später die Regeln, die Rollladen und Licht steuern.
Sensorik: Temperatur · Licht · Wind · Regen
Funk: ESP-NOW zum Gateway
MOD-C
geplant
Mobiles Terminal
Kein eigener Bildschirm-Code: Modul C zeigt dieselbe Web-UI wie Pi und Rechner, nur im Taschenformat. Damit ist die Oberfläche an einem Ort gepflegt und trotzdem überall dabei.
Anzeige: Touch-Display mit Akku
Weg: WLAN zur Zentrale, Web-UI im Browser
GW-01
Kernstück
Gateway
Sammelt alle Module per ESP-NOW und gibt sie als JSON-Zeilen über UART an den Pi — und schickt Befehle denselben Weg zurück. Der einzige Übergang zwischen Funk und Zentrale.
Funk: ESP-NOW-Master
Leitung: UART 115200, eine JSON-Zeile pro Datensatz
EXT-01
geplant
Fremde Geräte
Shelly und WLED werden nicht nachgebaut, sondern eingebunden: ein kleiner Python-Dienst (paho-mqtt) abonniert ihre Themen und legt ihre Zustände in dieselbe Datenbank.
Anbindung: MQTT-Broker im eigenen Netz
Weg: paho-mqtt → SQLite → Web-UI
Gemeinsame Basis
- Alle eigenen Module nutzen ESP32-SMD-WROOM-Module (D-015)
- eine Platinen-Familie, ein Firmware-Grundgerüst
- Gehäuse aus dem 3D-Drucker, je Raum eine Variante
Anlernen neuer Module
- Modul einschalten, die Zentrale bemerkt den unbekannten Funkpartner
- Typ und Raum zuweisen — fertig
- die Oberfläche zeigt das neue Gerät ohne Code-Änderung
// 04 — Aufbau
Vom Schaltplan zum Gehäuse
Aufgebaut wird Modul für Modul: erst Platine und Firmware, dann Gehäuse, dann der Einbau. Die Dokumentation läuft dabei mit — ein nachträglich geschriebenes Testprotokoll ist wertlos.
Platine
- ESP32-SMD-WROOM direkt auf die eigene Platine (D-015, 21.09.2026)
- Gründe: Platzgewinn und freie GPIO-Pins — Dev-Boards waren zu sperrig
- Folge laut Entscheidung: mehr Platz, geringere Bauhöhe
- Alle drei Modularten nutzen dieselbe Modulform — eine Platinenfamilie
Gehäuse
- CAD-Zeichnung und 3D-Druck gehören zur Abgabe, deshalb läuft der Entwurf mit
- Modul A: Deckengehäuse mit Belüftung — Temperatur und Feuchte müssen frei messen (D-017)
- Modul B: Außengehäuse mit Witterungsschutz
- Modul C: Handgehäuse für Display, Bedienung und Akku
Versorgung
- Modul A und B an 5 V Netz — Dauerbetrieb mit laufenden Messwerten
- Modul C mit Akku über USB-C, weil es mobil sein muss
- Das Gateway sitzt am Pi — die Zentrale ist die einzige Stelle mit Netzwerk
Firmware je Modultyp
- ESP32-Projekte mit PlatformIO, ein Projekt pro Modulart
- Nicht ein Board pro Gerät: gleiche Firmware, mehrere Geräte desselben Typs
- Die serielle Konsole zum Mitlesen gehört zum Entwickeln dazu
| Dokument | Inhalt | Warum es früh entsteht |
|---|---|---|
| Projektplan | Meilensteine, Zeitbudget, Feature-Freeze | Der Plan hält den Umfang fest |
| Funktionsbeschreibung | Module, Fähigkeiten, Nicht-Ziele | Beschreibt das Prüfungsziel in Worten |
| Schaltplan | je Modul ein Plan, Platine und Anschlüsse | Ohne ihn ist die Platine nicht prüfbar |
| Stückliste (BOM) | Bauteil, Menge, Bezugsquelle | Lieferzeiten einplanen — und Kosten belegen |
| CAD-Zeichnung | Gehäuse und Halterungen | Beim Drucken ohnehin erstellt |
| Testprotokoll | Messmittel: Multimeter, Netzwerkanalyse, Stoppuhr, serielle Konsole | Jede Anforderung bekommt einen Nachweis |
| Code-Auszüge | Prinzipstellen statt Vollabdruck | Erklärt im Fachgespräch mehr als eine Seitenzahl |
// 05 — Daten
Erst die Strecke, dann die Daten, dann die Oberfläche
Das ist die Reihenfolge, in der die Zentrale gebaut wird. Die Oberfläche kennt nur die API — deshalb lässt sich das Backend später umbauen, ohne dass man es merkt. Und deshalb stehen alle Werte an einer Stelle: in einer SQLite-Datenbank auf dem Pi.
Vier Schichten
- Kern: seriellen Empfang lesen, JSON-Zeilen auswerten
- Datenbank: Geräte, Fähigkeiten, Messwerte, Automationen
- Regel-Engine: was auf welchen Wert folgt
- API: REST unter /api/v1 und WebSocket für Live-Werte
Fähigkeiten als Daten
- Ein Gerät beschreibt beim Anlernen selbst, was es kann
- Kennung, Typ, Einheit, Grenzen, steuerbar ja/nein
- Die Oberfläche baut daraus ihre Widgets: neuer Sensor = neue Datenzeile
Regeln bleiben änderbar
- Automationen liegen in der Datenbank, nicht im Code (D-004)
- angelegt und geändert wird im Web-UI, ohne Programm neu zu schreiben
- der Benutzer entscheidet, was bei Regen oder Wind passiert
Versionierte Schnittstelle
- alle Endpunkte unter /api/v1 — Felder kommen dazu, nichts verschwindet
- FastAPI zeigt die API-Dokumentation selbst unter /docs
- Live-Ereignisse tragen Typ und Version; Unbekanntes wird ignoriert
Geräteliste
Beispielansicht — es sind noch keine Daten real
modul-a · Decke
Präsenz · 22,4 °C · 46 %
geplant
modul-b · Außen
9,1 °C · Licht · Wind · Regen
geplant
shelly · Steckdose
an / aus über MQTT
zuerst (D-013)
wled · Streifen
danach, gleiche Muster
später
modul-d
noch kein Gerät
frei
| Tabelle | Inhalt | Anmerkung |
|---|---|---|
| devices | ID, Name, Klasse (eigen/fremd), Raum, Symbol | eigene und fremde Geräte in einer Tabelle |
| capabilities | Kennung, Anzeigename, Typ, Einheit, min/max, steuerbar | daraus entstehen die Widgets |
| measurements | Zeitstempel, Gerät, Kennung, Wert | der Verlauf für Grafiken |
| automations | Bedingung, Aktion, aktiv | Regeln aus dem Web-UI (D-004) |
| events | Zeitstempel, Art, Quelle, Text | Ereignisliste im UI |
| meta | Schema-Version | Migrationen werden nummeriert angewandt |
| später | users, alarms, settings, devices.room_id, devices.icon | Platzhalter schon jetzt angelegt (R-05) |
// 06 — Zeitplan
Neun Monate, ein Freeze, eine Abgabe
Der Plan rechnet mit rund 1200 bis 1550 Stunden bis Juni 2027 — inklusive Gehäuse, Schaltplänen, Fertigung und Dokumentation. Weil das viel Zeit ist, liegt das Risiko nicht im Umfang, sondern in der Unschärfe. Deshalb gibt es ein Datum, ab dem nichts Neues dazukommt: den Feature-Freeze am 30.04.2027.
Konzept und Entscheidungen
Kernpunkte und Entscheidungen festschreiben, danach Features und Schnittstellen — die Basis für alles Weitere.
Hardware-Prototyp
Erster Aufbau auf Steckbrett: Funkstrecke, Sensorik und Übergabe an den Pi prüfen, bevor Platinen entstehen.
Modul A — Raum und Sicherheit
mmWave-Anwesenheit, Temperatur und Feuchte, Rauchmelder; dazu das Deckengehäuse (D-017).
Modul B — Wetter außen
Temperatur, Helligkeit, Sonnenstand, Wind und Regen — samt Gehäuse für draußen.
Modul C und Zentrale-Hardware
Mobiles Touch-Terminal mit Akku, parallel das Gateway als ESP-NOW-Master am Raspberry Pi.
Anlernen und Datenbank
Geräte melden sich selbst an, die Zentrale legt Fähigkeiten an — ab hier wächst die Datenbank mit echten Werten.
Oberfläche
Generische Widgets aus den Fähigkeiten: ein Design für Kiosk, Modul C, Handy und Rechner.
Automatik und fremde Geräte
Regel-Engine im UI bedienbar machen, Shelly zuerst, WLED danach (D-013). Ende des Monats: Freeze.
Integration und Tests
Dauerlauf, Messprotokolle, Fehler beheben — jede Anforderung bekommt ihren Nachweis.
Dokumentation und Abgabe
Stücklisten, CAD, Schaltpläne und Code-Auszüge zusammenstellen. Die letzten sechs Wochen gehören nicht der Software.
// Wochen je Arbeitspaket — längerer Balken = längerer Block (Maximum 8 Wochen)
| Zeitraum | Schwerpunkt | Aufwand | Summe |
|---|---|---|---|
| Okt – Dez 2026 | Konzept, Backend-Basis, erste Hardware | 10–20 h/Woche · ~13 Wochen | ≈ 130–260 h |
| Jan – Jun 2027 | Vollzeit-Fokus: Bau, Oberfläche, Tests | 40–50 h/Woche · ~26 Wochen | ≈ 1040–1300 h |
| bis zur Abgabe | inkl. Gehäuse, Schaltpläne, Fertigung und Dokumentation | 9 Monate | ≈ 1200–1550 h |
Feature-Freeze 30.04.2027
- Danach nur noch Fehler beheben, testen, fertigen und dokumentieren
- Ohne dieses Datum füllt sich jede freie Stunde mit Politur
- Der Plan hat ±2 Wochen Beweglichkeit — Ersatz für Ausfälle
Noch nicht datiert
- Umfang der Fremdgerätesteuerung (D-005), Firmware je Modultyp (D-006)
- Funkstrecke (D-007), Versorgung und Sicherheit (D-008)
- Datenmodell (D-009), Sprachsteuerung (D-010), Anlernverfahren (D-011)
- Offen: erst Hardware oder Software (D-016) und die Termine der Prüfungsordnung
// 07 — Kontakt
Fragen, Feedback, Fachgespräch
Jede Festlegung trägt eine Nummer — D-… für Entscheidungen, R-… für Regeln. Deshalb lässt sich jede Frage genau an der Stelle beantworten, an der sie entstanden ist. Wer den Stand mitverfolgen will, findet den Code auf GitHub.
GitHub
@Oz-113 — Repos und Prototyp
Prototyp
reimagined-dream — die Vorstufe
Zur Startseite
Kontakt, Projekte und Galerie
Stand und nächster Schritt
Gebaut ist noch nichts: Das Projekt steht bei Konzept und Entscheidungen, die Hardware folgt ab Herbst 2026. Bis dahin wächst diese Seite mit — jede getroffene Entscheidung kommt hier dazu.