Collector für alternative Energiequellen, welche keine Live-Daten liefern

[boecks]

In Österreich gibt es ein sehr junges Konzept der sogenannten "Erneuerbare Energiegemeinschaften" (kurz: EEG), dabei können sich sozusagen Nachbarn zusammenschließen und sich gegenseitig den Überschussstrom ihrer PV verkaufen. Da solche Energiegemeinschaften eigentlich nur innerhalb der selben Transformatorebene bestehen, können die Teilnehmer dadurch sowohl bei Einspeisung, als auch Bezug von EEG-Strom stark an den Netzkosten und manchen Steuern und Abgaben sparen, was insgesamt zu einem niedrigeren Preis pro kWh inkl. Netzkostenanteile führt.

Die Abrechnung funktioniert dabei über die Smart Meter Portale der jeweiligen Netzbetreiber. Leider aber nicht live, da man die Daten immer erst am Folgetag sehen kann und dazu nur im 15 Minuten Intervall. Trotzdem wäre es für mich und meine Energiebilanz relevant, diesen "Stromlieferanten" mit dessen Strompreise zumindest im Nachgang einfließen zu lassen.

Selbstverständlich konnte man sich auf keine Einheitliche technische Lösung verständigen und alles ist Chaos, aber in meinem Fall kann ich täglich ein CSV mit 15 Minuten Werten herunterladen, welches das Potential hätte, diese Daten in Solecturs zu importieren.
Den Weg, diese Daten zu beschaffen müsste jeder für sich selbst herausfinden - ich werde jedenfalls mal versuchen, was ich automatisieren kann.

Welche Voraussetzungen hat Solecturs und welche bräuchte es, um das Konzept mehrerer Stromliefereanten mit unterschiedlichen Strompreisen zu unterstütrzen? Wie ist das Thema verwandt mit dynamischen Stromtarifen?

Zumindest für den Import könnte ich mir einfach einen neuen CSV-Collector vorstellen, da sehe ich keine große Herausforderung im Vergleich zum Solaredge Importer oder den anderen CSV Importern.
Einzig, es wäre dann vielleicht kein Importer wie er jetzt definiert ist, sondern von der Idee her eher ein Collector der die Daten gepusht bekommt, also Files kommen rein und werden verarbeitet ohne zutun.

@ledermann hast du zu dem Thema eine Einschätzung oder Meinung? Gibt es in Deutschland ein vergleichbares Konzept zu unseren Energiegemeinschaften?

Edit: wo ich darüber nachdenken, das kommt dem Konzept von Tag- und Nachtstrom oder meinetwegen separaen Zählern für Wärmepumpen-Strom oder eAuto-Strom sehr nahe oder?

[ledermann]

Klingt interessiert, danke für deinen Input! Hier in Deutschland ist mit Energy Sharing tatsächlich etwas ähnliches in Arbeit, losgehen soll es in DE ab Juni 2026.

Neben der automatisierten Verarbeitung der CSV-Dateien wäre aus Sicht von SOLECTRUS das entscheidende Thema die grundsätzliche Befähigung im Umgang mit Strompreisen, die sich in sehr kurzen Zeitabständen (wie z.B. alle 15min) ändern können.

Dazu gibt es bereits einige Issues, die im Kern alle zur gleichen Grundvoraussetzung führen: SOLECTRUS benötigt einen flexibilisierten Umgang mit Strompreisen und Vergütungen. Es bietet sich an, die bereits vorhandenen Tageszusammenfassungen auszubauen, so dass dies nicht nur die saldierte Energie enthalten, sondern auch die entstandenen Kosten und Vergütungen (je Erzeuger bzw. Verbraucher). Es muss also in größerem Umfang an der Architektur von SOLECTRUS geschraubt werden.

Mir ist das Thema sehr wichtig, gleichzeitig ist es so groß, so dass es bislang immer wieder von anderen Themen verdrängt wurde. Auch aus heutiger Sicht denke ich, dass nach Veröffentlichung des nächsten größeren Updates (Version 1.1 soll in Kürze durch die Tür), mich etwas anderes beschäftigen wird, und das ist ein web-basiertes Konfigurations-Werkzeug für SOLECTRUS, weil derzeitig immer noch die komplexe Inbetriebnahme die größte Hürde ist, um neue User zu gewinnen.

Sobald das geschafft ist, spricht aus heutiger Sicht aber nichts dagegen, dann endlich die Umstellung auf flexible Strompreise vorzunehmen.

[ledermann]

Noch eine Ergänzung zum technischen Hintergrund:

Derzeitig werden in InfluxDB nur Messwerte abgelegt (Leistung in W, Temperatur usw.). Die Preise mit ihrem jeweiligen Geltungszeitraum liegen in PostgreSQL.

Diese Unterscheidung muss langfristig aufgegeben bzw. erweitert werden. Es müssen dann Strompreise (und vermutlich auch Einspeisevergütungen) ebenfalls in InfluxDB abgelegt werden, mit einem Zeitstempel, ab wann sie gelten. Der Tibber-Collector macht das bereits so (aber es wird noch nicht damit gerechnet). In PostgreSQL müsste dann nur noch stehen, dass von Datum X bis Y der Anbieter "Tibber" relevant ist.

Das Einsammeln der Daten ist also erst mal kein Problem, das könnte also auch mit deinen CSV-Daten so passieren. Die Herausforderung ist, mit diesen Preisen dann zu rechnen - und das auch performant. Es muss ja weiterhin möglich sein, die Kosten des Stromverbrauchs auch für einen langen Zeitraum innerhalb weniger Millisekunden zu ermitteln und im UI darzustellen.

Derzeitig funktioniert es so, hier ein Beispiel für die Ermittlung von Stromkosten und Einspeisevergütung für ein Jahr:

timeframe = Timeframe.new('2026')

query = Sensor::Query::Total.new(timeframe) do |q|
  q.sum :grid_revenue
  q.sum :grid_costs
end

Daraus generiert die Query-Engine von SOLECTRUS folgendes SQL-Statement, das Tageszusammenfassungen (saldierte Energie) mit Preisen verknüpft. Diese Art der Query ist die Kernidee der aktuell implementierten Berechnung:

WITH 
  price_ranges AS (
    SELECT 
      name, 
      starts_at, 
      LEAD(starts_at, 1, 'infinity' :: date) OVER (
        PARTITION BY name 
        ORDER BY 
          starts_at
      ) AS next_start, 
      value :: numeric AS eur_per_kwh 
    FROM 
      prices 
    WHERE 
      name IN ('electricity', 'feed_in')
  ), 

  daily AS (
    SELECT 
      sv.date, 
      SUM(sv.value) FILTER (
        WHERE sv.aggregation = 'sum' 
          AND sv.field = 'grid_import_power'
      ) AS grid_import_power_sum, 
      SUM(sv.value) FILTER (
        WHERE sv.aggregation = 'sum' 
          AND sv.field = 'grid_export_power'
      ) AS grid_export_power_sum, 
      MAX(pb.eur_per_kwh) AS pb_eur_per_kwh, 
      MAX(pf.eur_per_kwh) AS pf_eur_per_kwh 

    FROM 
      summary_values sv 
      LEFT JOIN price_ranges pb ON pb.name = 'electricity' 
                                AND sv.date >= pb.starts_at 
                                AND sv.date < pb.next_start 
      LEFT JOIN price_ranges pf ON pf.name = 'feed_in' 
                                AND sv.date >= pf.starts_at 
                                AND sv.date < pf.next_start 
    WHERE 
      sv.date BETWEEN DATE '2026-01-01' 
                  AND DATE '2026-12-31' 
      AND sv.aggregation IN ('sum') 
      AND sv.field IN ('grid_import_power', 'grid_export_power') 

    GROUP BY 
      sv.date
  ) 

SELECT 
  SUM(
    COALESCE(grid_import_power_sum, 0) * pb_eur_per_kwh / 1000.0
  ) AS grid_costs_sum_sum, 
  SUM(
    COALESCE(grid_export_power_sum, 0) * pf_eur_per_kwh / 1000.0
  ) AS grid_revenue_sum_sum 

FROM 
  daily 

PostgreSQL kann das extrem schnell ausführen, nach 4ms hat man das Ergebnis:

<Sensor::Data::Single:0x000000012cc22860 
  @raw_data={
    [:grid_costs,   :sum, :sum] => 364.9476446925, 
    [:grid_revenue, :sum, :sum] =>  40.4707681411
  }
>

InfluxDB wird für diese Berechnung also gar nicht benötigt, sie findet allein in PostgreSQL statt.

Dieses Prinzip würde nicht funktionieren, wenn es täglich mehr als einen Preis gibt. Die Stromkosten könnten dann nicht mehr on-the-fly berechnet werden, weil die Tageszusammenfassungen die Energie ja nur für ganze Tage enthält.

Eine Möglichkeit wäre, die Kosten und Vergütungen vorzuberechnen, also in die Tageszusammenfassungen zu integrieren, deren Berechnung dann aufwändiger wird. Dies zu konzipieren und implementieren ist der größte Brocken, der angegangen werden muss.

[ledermann]

@boecks Könntest du die CSV-Datei beispielhaft hier ablegen? Mich würde interessieren, welche Spalten darin konkret enthalten sind, damit ich das mit meinen bisherigen Vorstellungen für dynamische Preise abgleichen kann.

[boecks]

Ich weiß nicht, ob wir hier von den typischen, dynamischen Strompreisen sprechen. Im Endeffekt ist diese Energiegemeinschaft wie ein weiterer Stromanbieter zu verstehen, mit dem ich einen Vertrag habe und zu einem statischen Tarif Strom beziehe. Die CSV selbst enthalten keine Preisinformation, den müsste ich vom Prinzip her wie die derzeitigen Strompreise zur berechnung heranziehen.

Aber diese Energiegemeinschaften (und womöglich das Energy Sharing bei euch) könnten potentiell dynamische Preise verwenden, da jede die Preisgestaltung selbst in der Hand hat.

Anbei jedenfalls ein CSV, für deine Frage aber vermutlich weniger aufschlussreich.
2026-03-04.csv

Die Spalten kurz erklärt: timestamp= 15 Minuten Datumswert, verbrauch_kwh = gesamtmenge verbraucht laut SmartMeter, netzbezug_kwh = vom Stromlieferanten bezogen, eigenverbrauch_kwh = von der energiegemeinschaft bezogen

Wegen der Berechnung der Tageszusammenfassungen: Wenn man mittles eines Importers regelmäßig Daten für breits abgeschlossene Tage einspielt, könnte man die Tageszusammenfassungen für den Tag ja bei diesem Vorgang berechnen - ab dann ändert sich an dem Tag ja nichts mehr oder?

Ich erkenne aber auch schon das Ausmaß an fundamentalen Fragestellungen beim Thema dynamische Strompreise oder "mehr als ein Stromlieferant" - ein großer Brocken...

[ledermann]

Danke, das CSV ist hilfreich, ich hatte das bislang etwas anders verstanden. Stimmt, mit Preisen hat das dann nur indirekt zu tun, wichtig ist erst mal nur die Aufteilung in "Strom aus Nachbarschaft" und "Strom von Außen".

Bei den Tageszusammenfassungen ist es so, dass man diese tageweise auch nachträglich löschen kann, wenn sich die Berechnungsgrundlage geändert hat, dann wird der betroffene Tag einfach beim nächsten Mal neu berechnet. Die nachträgliche Anlieferung macht also kein Problem.

Ich habe mal versucht, ein Konzept zu erstellen, dass die verschiedenen offenen Issues (inkl. der weiteren Stromanbieter) abdecken würde. Die Komplexität ist wirklich nicht zu unterschätzen, aber ich denke, machbar ist das alles schon.