So funktioniert Solvur — von Live-Daten bis Rechnung.

Solvur ist eine SaaS-Plattform für die Gemeinschaftliche Gebäudeversorgung (GG) nach §42b EnWG. Sie richtet sich an Betreiber von PV-Anlagen, die Strom an Mieter oder Eigentümer im selben Gebäude liefern und dafür rechtssichere Abrechnungen erstellen müssen.

Die Plattform erfasst die Erzeugung der PV-Anlage und den Verbrauch jeder einzelnen Wohnung sekündlich, verdichtet diese Werte zu 15-Minuten-Intervallen und ermittelt daraus monatlich, wie viel Strom jeder Kunde anteilig aus der PV-Anlage bzw. aus dem Reststrom (Netzbezug) bezogen hat. Auf dieser Basis werden Rechnungen automatisch generiert und versendet.

Was ist neu?

Bisher war die gemeinschaftliche Nutzung lokal erzeugten Stroms im Wesentlichen auf ein einziges Gebäude begrenzt (Mieterstrom nach § 42a EnWG, Gemeinschaftliche Gebäudeversorgung nach § 42b EnWG). § 42c EnWG erweitert das Modell auf mehrere Liegenschaften innerhalb desselben Verteilnetzgebiets — der Strom darf also den Zähler des Netzbetreibers passieren und trotzdem als „gemeinsam genutzt" gelten.

Die Kernpunkte im Überblick

• Wer darf teilnehmen? Private Haushalte, öffentliche Einrichtungen und kleinere Unternehmen.
• Wie wird zugeordnet? Bilanziell im 15-Minuten-Takt — Erzeugung und Verbrauch werden viertelstündlich erfasst und rechnerisch aufgeteilt.
• Smart Meter Pflicht. Jede Verbrauchsstelle und jede Erzeugungsanlage braucht ein intelligentes Messsystem (iMSys).
• Zwei Verträge. § 42c verlangt einen Liefervertrag (mit Preis) und einen Vertrag über die gemeinsame Nutzung.
• Reststromlieferant bleibt. Reicht der gemeinschaftlich erzeugte Strom nicht aus, wird die Differenz weiter vom regulären Stromlieferanten bezogen — Energy Sharing ersetzt keinen Stromvertrag.
• Räumliche Grenze. Bis 31. Mai 2028 müssen Erzeugung und Verbrauch im selben Verteilnetzgebiet liegen. Ab 1. Juni 2028 auch in benachbarten Netzgebieten.
• Netzentgelte & Umlagen fallen auf den geteilten Strom weiterhin an — anders als z. B. in Österreich.
• Bundeseinheitliche Plattform. § 20b EnWG verpflichtet die Netzbetreiber, eine zentrale Internetplattform für Abwicklung und Bilanzierung aufzubauen. Inbetriebnahme: noch offen (Stand 06/2026).

Abgrenzung zu § 42a und § 42b EnWG

Was bedeutet das für Solvur-Nutzer?

Solvur ist heute primär für § 42b (Gemeinschaftliche Gebäudeversorgung) ausgelegt — also die Abrechnung innerhalb eines Gebäudes. Die gesamte Datenarchitektur der Plattform (15-Min-Slots, immutable finalisierte Intervalle, bilanzielle Zuordnung nach Verbrauchsschlüssel, getrennter Ausweis von Solar- und Reststrom) entspricht aber exakt dem, was § 42c EnWG auch für Energy-Sharing-Gemeinschaften fordert.

Praktische Voraussetzungen für eine § 42c-Gemeinschaft

1. Gründung einer Energiegemeinschaft (z. B. als Genossenschaft, Verein oder GbR) inkl. Satzung / Gesellschaftsvertrag.
2. Liefervertrag zwischen Gemeinschaft und Teilnehmenden mit konkretem Strompreis pro kWh.
3. Vertrag über die gemeinsame Nutzung nach § 42c EnWG (Rechte, Pflichten, Verteilschlüssel).
4. Anmeldung der Gemeinschaft beim zuständigen Verteilnetzbetreiber.
5. Installation von Smart Metern (iMSys) an jeder Erzeugungs- und Verbrauchsstelle.
6. Reststromlieferant für jeden Teilnehmer weiterhin vorhalten.

Quellen & weiterführende Links

• Gesetzestext § 42c EnWG — gesetze-im-internet.de
• Bundeseinheitliche Plattform § 20b EnWG — gesetze-im-internet.de
• Verteilnetzbetreiber finden — vnbdigital.de
• Verbraucherzentrale: Energy Sharing 2026 — verbraucherzentrale.de

Der gesetzliche Rahmen für lokale Stromnutzung in Deutschland hat sich in den letzten Jahren stark entwickelt:

• 2017 — Mieterstromgesetz: § 42a EnWG, Förderung für Mieterstrom auf Wohngebäuden.
• Mai 2024 — Solarpaket I: Einführung der Gemeinschaftlichen Gebäudeversorgung (§ 42b EnWG). Stark vereinfacht: kein Versorgerstatus mehr nötig.
• Februar 2025 — Solarspitzengesetz: Steuerbarkeit, Direktvermarktung Kleinanlagen.
• 1. Juni 2026 — § 42c EnWG: Energy Sharing tritt in Kraft. Erstmals gebäudeübergreifende gemeinschaftliche Nutzung über das öffentliche Netz.
• 1. Juni 2028 — geplant: Ausweitung auf benachbarte Verteilnetzgebiete.

Es gibt drei Rollen:

• Betreiber — Anlagenbetreiber oder Hausverwaltung. Verwaltet Kunden, Anlagen, Preise, Rechnungen.
• Kunde — Mieter / Eigentümer einer Wohneinheit. Sieht im Portal eigene Verbrauchsdaten, Rechnungen und Belege.
• Admin — Solvur-interner Support, hat Plattform-weiten Zugriff für Wartung.

Anmeldung über /login. Kundenkonten werden anhand der hinterlegten E-Mail-Adresse automatisch der richtigen Wohneinheit zugeordnet.

Eine Anlage (engl. plant) besteht aus:

• 1 PV-Erzeugungszähler (Produktion)
• 1 Netzanschlusszähler (Bezug / Einspeisung)
• N Unterzähler je Wohneinheit / Kunde (Verbrauch)
• optional: Speicher, Wärmepumpe, Wallbox

Jedes Gerät hat eine eindeutige device_id und sendet Messwerte über die Ingest-API (siehe unten) an Solvur.

Die Geräte (z. B. Shelly Pro, oder ein Node.js-Gateway vor Ort) senden Live-Werte typischerweise alle 1–5 Sekunden an POST /api/public/ingest. Jede Messung enthält:

• device_id — eindeutige Geräte-ID
• ts — ISO-Timestamp der Messung
• power_w — momentane Leistung in Watt
• energy_kwh_delta — Energie-Delta seit letztem Sample

Diese Live-Werte landen in der Tabelle live_readings (rollierender Puffer, max. 1 Stunde Vorhaltung) und werden per Supabase Realtime sofort an alle eingeloggten Clients gepusht. Die Anlagen-Detailseite zeigt damit aktuelle Produktion und „Letztes Signal" in Sekunden.

Alle 5 Minuten läuft serverseitig ein Job, der die Live-Readings zu festen 15-Minuten-Slots verdichtet (meter_intervals). Sobald ein Slot älter als 20 Minuten ist, wird er als is_finalized = true markiert und kann nicht mehr verändert werden.

Im Dashboard sehen Sie deshalb getrennt:

• Historische 15-Min-Werte (finalisiert, unveränderlich)
• Aktueller Live-Slot (noch offen, ändert sich bis zum nächsten Viertelstundenwechsel)

Für jeden 15-Minuten-Slot gilt: die in dieser Viertelstunde erzeugte PV-Energie wird auf die Wohneinheiten anteilig nach deren tatsächlichem Verbrauch im selben Slot verteilt — gedeckelt durch die jeweilige Wohnung.

Pro 15-Min-Slot:
  pv_erzeugt          = z. B. 4,2 kWh
  verbrauch_total     = Σ Verbrauch aller Wohnungen
  pv_anteil[i]        = min(verbrauch[i],
                            pv_erzeugt * verbrauch[i] / verbrauch_total)
  reststrom[i]        = verbrauch[i] - pv_anteil[i]
  netzeinspeisung     = pv_erzeugt - Σ pv_anteil[i]

Das Ergebnis: jede Wohneinheit erhält monatlich zwei Mengen: Mieterstrom (aus PV) und Reststrom (aus dem Netz). Beide werden auf der Rechnung getrennt ausgewiesen.

Es gibt zwei Preis-Ebenen:

Die Netzeinspeisung (PV-Überschuss, der ins öffentliche Netz fließt) wird separat erfasst. Die Vergütung dafür gehört dem Anlagenbetreiber und erscheint in dessen Statistik unter Anlage → Monats-/Jahresstatistik.

Am 1. jedes Monats läuft der Job /api/public/cron/generate-invoices und erstellt für jeden Kunden eine Rechnung für den Vormonat. Wenn beim Kunden „Automatisch versenden" aktiv ist, wird sie direkt per E-Mail zugestellt — sonst wartet sie als Entwurf im Betreiber-Portal.

• Rechnungen sind dauerhaft unter /invoices bzw. im Kundenportal abrufbar.
• PDF wird serverseitig generiert und in Storage abgelegt.
• Versandprotokoll inkl. Zeitstempel und Empfänger wird gespeichert.

• Hosting in der EU, DSGVO-konform.
• Row-Level-Security: jeder Kunde sieht ausschließlich seine eigenen Daten.
• Verschlüsselung in transit (TLS) und at rest.
• Auftragsverarbeitungsvertrag (AVV) gemäß Art. 28 DSGVO — /avv.

Externe Node.js-Gateways oder Shelly-Geräte senden Live-Werte an folgenden Endpoint:

POST https://solvur.lovable.app/api/public/ingest
Content-Type: application/json

{
  "device_id": "shelly-em-3p-abc123",
  "samples": [
    { "ts": "2026-06-02T10:30:15.000Z",
      "power_w": 4280, "energy_kwh_delta": 0.0018 },
    { "ts": "2026-06-02T10:30:20.000Z",
      "power_w": 4310, "energy_kwh_delta": 0.0060 }
  ]
}

Antwortcodes:

• 200 OK — Werte gespeichert.
• 409 Conflict — Slot bereits finalisiert, Wert wird verworfen.
• 401 — fehlende oder ungültige Signatur.
• 422 — Validierungsfehler (z. B. unbekannte device_id).