Architektur

Das 3-Repo-Ökosystem

EEDC besteht aus drei Repositories, die zusammen ein vollständiges Ökosystem bilden:

┌─────────────────────────┐
│   eedc (Core)           │  Shared: FastAPI + React + SQLite
│   Standalone via Docker  │  Kann unabhängig laufen
└────────────┬────────────┘
             │ Git Subtree (eedc/ Verzeichnis)
             ▼
┌─────────────────────────┐         POST /api/submit
│   eedc-homeassistant    │ ──────────────────────────► ┌──────────────────────┐
│   Home Assistant Add-on │         GET /api/benchmark   │   eedc-community     │
│   + MQTT + Sensor-      │ ◄────────────────────────── │   PostgreSQL Server   │
│     Mapping + Docs      │                              │   energy.raunet.eu   │
└─────────────────────────┘                              └──────────────────────┘

eedc (Core)

Das Herzstück — die gemeinsame Codebasis für Backend und Frontend. Kann standalone via docker-compose up gestartet werden, ohne Home Assistant.

eedc-homeassistant

Verpackt den Core als Home Assistant Add-on und ergänzt:

• MQTT Discovery für native HA-Sensoren
• Sensor-Mapping-Wizard
• HA-Statistik-Import
• Monatsabschluss-Wizard mit HA-Datenvorschlägen

Der Core wird als Git Subtree eingebunden — kein Submodule, sondern eine vollständige Kopie unter eedc/. Das vereinfacht CI/CD und ermöglicht eigenständige Builds.

eedc-community

Ein eigenständiger Server für anonyme Community-Benchmarks. Architektonisch bewusst getrennt:

• PostgreSQL statt SQLite (Multi-User, Concurrent Writes)
• Async SQLAlchemy für bessere Skalierung
• Eigene API mit 19 Endpunkten

Tech Stack

Schicht	Core / HA Add-on	Community Server
Backend	Python, FastAPI, SQLAlchemy	Python, FastAPI, SQLAlchemy 2.0 (async)
Frontend	React, TypeScript, Vite, Tailwind CSS, Recharts	React, TypeScript, Vite, Tailwind CSS, Recharts
Datenbank	SQLite	PostgreSQL
Deployment	Docker, HA Add-on	Docker, GitHub Actions, Portainer
Externe APIs	Open-Meteo, DWD Bright Sky, PVGIS	—

Datenmodell

Das zentrale Datenmodell dreht sich um die Anlage (PV-System) und ihre Investitionen (Komponenten):

Anlage (Standort, Ausrichtung, Neigung)
 ├── Monatsdaten (monatliche Zählerstände)
 ├── Strompreise (zeitlich gültige Tarife)
 └── Investitionen
      ├── Wechselrichter
      │    ├── PV-Module (Pflicht)
      │    └── DC-Speicher (optional)
      ├── AC-Speicher
      ├── E-Auto
      ├── Wärmepumpe
      ├── Wallbox
      ├── Balkonkraftwerk
      └── Sonstiges

Jede Investition hat eigene InvestitionMonatsdaten — z.B. String-Erträge pro PV-Modul, Lade-/Entladezyklen pro Speicher, gefahrene km pro E-Auto.

Design-Entscheidungen

Warum Standalone-First?

Nicht jeder nutzt Home Assistant. Durch die Trennung in Core (ohne HA-Abhängigkeit) und HA-Wrapper bleibt das Projekt:

• Testbar — Unit-Tests laufen ohne HA-Instanz
• Portabel — läuft auf jedem System mit Docker
• Zukunftssicher — neue Integrationen (z.B. ioBroker) ohne Core-Änderungen

Warum Git Subtree statt Submodule?

Git Submodules sind fehleranfällig und erschweren CI/CD. Ein Subtree ist eine vollständige Kopie im Repository — einfacher zu klonen, zu bauen und zu releasen. Updates werden mit git subtree pull synchronisiert.

Warum SQLite (Core) vs. PostgreSQL (Community)?

• Core: Einzelbenutzer, lokale Installation. SQLite = zero config, eine Datei, Backup durch Kopieren.
• Community: Multi-User-Server mit gleichzeitigen Schreibzugriffen. PostgreSQL = ACID-Transaktionen, Connection Pooling, robustes Locking.

Warum monatliche Granularität?

Für Amortisation, Eigenverbrauchsquote und Langzeittrends reichen Monatswerte. Vorteile:

• Einfache Dateneingabe (12 Werte pro Jahr statt 8.760)
• Robuster gegen Sensor-Ausfälle
• Vergleichbar mit Abrechnungen vom Netzbetreiber
• Prognosen auf Monatsbasis sind meteorologisch belastbar