MySQL - EVU stündlichen Verbrauch aus dem Netz in der DbLog ermitteln

[ch.eick]

Hallo zusammen,
in Bezug auf die Börsen EVUs wollte ich mal meinen stündlichen Verrauch in der MySQL DbLog ermittel.
Erschwerend kommt da hinzu, dass ich nur minütlich die Geräte abfrage und dort dann auch nur die Änderungen speicher

Somit wird dies dann nur eine Näherung ergeben können.

Verwendet sollte hierbei nun ein reading, dass den Verbrauch möglichst kleinschrittig, als kontinuierlichen Zähler misst,
da ich ja auch noch eine PV-Anlage mit Speicher habe. Hierbei ist ja der Wunsch, dass der Zähler möglichst still steht und
es zumindest nur sehr geringe Verbräuche gibt.

Das Ergebnis soll dann beim Abschätzen für die Kosten von Tibber oder aWATTar dienen.

Ich besitze drei mögliche Zähler, wobei jedoch nur einer die Vorrausetzung erfüllt.
1.) Einlesekopf auf dem EVU Zähler. Da habe ich jedoch nur ganze kWh in die DbLog geschrieben
2.) Ein KSEM, bei dem ich ebenfalls nur kWh geschrieben haben

3.) Der Wechselrichter, der bis auf Watt runter geht.
    WR_1:Total_home_consumption_Grid

Und hier wäre nun das MySQL SELECT für einen Tag

Code Auswählen Erweitern

siehe weiter oben

Verwendet habe ich das MySQL SELECT natürlich außerhalb von FHEM in einem Tool meiner Wahl.

VG  Christian

[Prof. Dr. Peter Henning]

Das ist ganz einfach, aber nur schwer mit SQL zu lösen (glaub mir, hab das Zeug jahrelang unterrichtet).

Die Lösung ergibt sich daraus, dass die Tarifwechsel immer zu ganzen Stunden passieren. Wenn man also ein Messintervall hat, das innerhalb einer Stunde liegt: Kein Problem, weil während des gesamten Messintervalls derselbe Tarif gegolten hat. Wenn man nun ein Messintervall X hat, das x1 Sekunden _vor_ dem Tarifwechsel T1 -> T2 beginnt, und x2 Sekunden _nach_ dem Tarifwechsel endet, wobei x1+x2=X, und während dieses Messintervalls die Energie Y gemessen wird, ergeben sich als Kosten natürlich Y*(x1/X*T1 + x2/X*T2). Diese lineare Näherung könnte man noch verbessern, mehr als eine quadratische Näherung, welche das vorhergehende und das nachfolgende Messintervall umfasst, halte ich aber nicht für sinnvoll. Außerdem bekommt man dann den genäherten Wert erst mehr als ein Messintervall nach dem Wechsel, was auch unschön ist.

2011 habe ich mal ein Modul 15_EMX.pm geschrieben (findet sich im contrib-Ordner), als Ersatz für 15_CUL_EM.pm. Dort ist diese lineare Interpolation für Tarifwechsel drin, ebenso (und das auch in Modulen wie z.B. OWCOUNT) eine lineare Interpolation des Datenwertes um Mitternacht. War einer meiner ersten Gehversuche mit FHEM, siehe https://forum.fhem.de/index.php?topic=6449.0. Dieses 15_EMX.pm ist bei mir heute noch im Einsatz, mein entsprechendes "Energiemessystem" wird aber am nächsten Montag endgültig in den Schrott wandern.

LG

pah

[300P]

Vor mehr als nur einigen Jahren habe ich mir deshalb von einem anderen Messstellenbetreiber (nicht vom zuständigen vorgeschriebenen Netzbetreiber) einen Zähler installieren lassen, dessen Zähler mit sehr vielen Nachkommastellen misst, in der API "rüberkommt" und lokal auch (im xy Sekundentakt) bereitstellt.

Schau dir einmal genau die Beschreibung und die Optionen der INFO-Schnittstelle deines Zählers an.

Eventuell kannst du eine ähnliche Anzahl von Nachkommastellen von deinem Zähler nach PIN-Eingabe und deren dauerhafter Aktivierung dann mit deinem Lesekopf lokal am Zähler deines VNB bekommen. (siehe Code)

Code Auswählen Erweitern

2024-02-14 16:21:54    MyDiscovergyEVU    HTTPMOD    energy: 6707.2297825    energy    6707.2297825    NULL
2024-02-14 16:21:54    MyDiscovergyEVU    HTTPMOD    energyOut: 7884.3107438    energyOut    7884.3107438    NULL
2024-02-14 16:21:54    MyDiscovergyEVU    HTTPMOD    power: -0.16    power    -0.16    NULL
2024-02-14 16:21:24    MyDiscovergyEVU    HTTPMOD    energy: 6707.2297541    energy    6707.2297541    NULL
2024-02-14 16:21:24    MyDiscovergyEVU    HTTPMOD    energyOut: 7884.3107102    energyOut    7884.3107102    NULL
2024-02-14 16:21:24    MyDiscovergyEVU    HTTPMOD    power: -2.97    power    -2.97    NULL
2024-02-14 16:20:54    MyDiscovergyEVU    HTTPMOD    power: 1.58    power    1.58    NULL
2024-02-14 16:20:54    MyDiscovergyEVU    HTTPMOD    energy: 6707.2297129    energy    6707.2297129    NULL
2024-02-14 16:20:54    MyDiscovergyEVU    HTTPMOD    energyOut: 7884.3106335    energyOut    7884.3106335    NULL
2024-02-14 16:20:24    MyDiscovergyEVU    HTTPMOD    energy: 6707.2296842    energy    6707.2296842    NULL
2024-02-14 16:20:24    MyDiscovergyEVU    HTTPMOD    energyOut: 7884.310621    energyOut    7884.310621    NULL
2024-02-14 16:20:24    MyDiscovergyEVU    HTTPMOD    power: 3.65    power    3.65    NULL
2024-02-14 16:19:54    MyDiscovergyEVU    HTTPMOD    power: -2.52    power    -2.52    NULL
2024-02-14 16:19:54    MyDiscovergyEVU    HTTPMOD    energyOut: 7884.3105976    energyOut    7884.3105976    NULL
2024-02-14 16:19:54    MyDiscovergyEVU    HTTPMOD    energy: 6707.2296659    energy    6707.2296659    NULL
2024-02-14 16:19:24    MyDiscovergyEVU    HTTPMOD    energy: 6707.2296137    energy    6707.2296137    NULL
2024-02-14 16:19:24    MyDiscovergyEVU    HTTPMOD    energyOut: 7884.3105349    energyOut    7884.3105349    NULL
2024-02-14 16:19:24    MyDiscovergyEVU    HTTPMOD    power: -0.75    power    -0.75    NULL
2024-02-14 16:18:54    MyDiscovergyEVU    HTTPMOD    power: -0.92    power    -0.92    NULL
2024-02-14 16:18:54    MyDiscovergyEVU    HTTPMOD    energy: 6707.2296069    energy    6707.2296069    NULL
2024-02-14 16:18:54    MyDiscovergyEVU    HTTPMOD    energyOut: 7884.3105304    energyOut    7884.3105304    NULL

Damit sollte es, mit den Abrechnungen des jeweiligen EVU (z.B. Tibber) dann bei aktuell nutzbaren Stundenabrechnungen - selbst bei 1/4 Stundenwertabrechnungen, nur noch äußerst geringe Abweichungen durch Rundungen geben.


Bei meinen sehr geringen Bezugs- / Einspeiseleistungen reicht das z.B. vollkommen aus.
Ich bin der Auffassung das es bei "Stunden" - Verbrauchsdifferenzen von 0,XXXYYYY kWh nicht mehr maßgeblich auf die "YYYY" - Werte noch ankommen wird. 
100 % kann ich es erst Mitte des Jahres sagen. Derzeit bin ich erst ab 1.4.24 bei Tibber und bringe deshalb meinen PV-Batterien grad bei diese zum richtigen Zeitpunkt (bei wenig Sonne und mit Berücksichtigung diverser Randbedingungen  - BHKW/Brennstoffzellen + Solarforcast) zu laden.......

Gruß
300P

[ch.eick]

Das ist ganz einfach, aber nur schwer mit SQL zu lösen (glaub mir, hab das Zeug jahrelang unterrichtet).

Oh man, dann muss ich mich mit meinem Laienhaften SQL besser etwas zurück halten

Die Lösung ergibt sich daraus, dass die Tarifwechsel immer zu ganzen Stunden passieren. Wenn man also ein Messintervall hat, das innerhalb einer Stunde liegt: Kein Problem, weil während des gesamten Messintervalls derselbe Tarif gegolten hat. Wenn man nun ein Messintervall X hat, das x1 Sekunden _vor_ dem Tarifwechsel T1 -> T2 beginnt, und x2 Sekunden _nach_ dem Tarifwechsel endet, wobei x1+x2=X, und während dieses Messintervalls die Energie Y gemessen wird, ergeben sich als Kosten natürlich Y*(x1/X*T1 + x2/X*T2). Diese lineare Näherung könnte man noch verbessern, mehr als eine quadratische Näherung, welche das vorhergehende und das nachfolgende Messintervall umfasst, halte ich aber nicht für sinnvoll. Außerdem bekommt man dann den genäherten Wert erst mehr als ein Messintervall nach dem Wechsel, was auch unschön ist.

2011 habe ich mal ein Modul 15_EMX.pm geschrieben (findet sich im contrib-Ordner), als Ersatz für 15_CUL_EM.pm. Dort ist diese lineare Interpolation für Tarifwechsel drin, ebenso (und das auch in Modulen wie z.B. OWCOUNT) eine lineare Interpolation des Datenwertes um Mitternacht. War einer meiner ersten Gehversuche mit FHEM, siehe https://forum.fhem.de/index.php?topic=6449.0. Dieses 15_EMX.pm ist bei mir heute noch im Einsatz, mein entsprechendes "Energiemessystem" wird aber am nächsten Montag endgültig in den Schrott wandern.

Hallo pah,
danke für die ausführliche Excursion das hatte ich alles bereits intensiv verdrängt

In dem SQL SELECT geht es eigentlich nur darum die echten Zählerstände auf Stundenbasis auszulesen, wodurch sich die abzurechnenden kWh ergeben. Auch hier wir natürlich eine Näherung vorgenommen, da ja der letzte Zähler nicht exact auf den Stundenwechsel liegt. Dieses _vor_ oder _nach_ liegt bei mir durch die Messung im Watt Bereich bei maximal 1 Minute, was ich mir als Ungenauigkeit gegönnt habe. Durch das sehr ausgedünnte Logging von 1/Minute und dann auch nur noch die Wechsel des readings kommt es ja auch noch zu den etwas unschönen Lücken mit Null Verbrauch. Ich schau mir das mal im Sommer an, wenn die PV-Anlage im Bereich von 100% Autarkie ist.

VG   Christian

[ch.eick]

Vor mehr als nur einigen Jahren habe ich mir deshalb von einem anderen Messstellenbetreiber (nicht vom zuständigen vorgeschriebenen Netzbetreiber) einen Zähler installieren lassen, dessen Zähler mit sehr vielen Nachkommastellen misst, in der API "rüberkommt" und lokal auch (im xy Sekundentakt) bereitstellt.

Schau dir einmal genau die Beschreibung und die Optionen der INFO-Schnittstelle deines Zählers an.

Eventuell kannst du eine ähnliche Anzahl von Nachkommastellen von deinem Zähler nach PIN-Eingabe und deren dauerhafter Aktivierung dann mit deinem Lesekopf lokal am Zähler deines VNB bekommen. (siehe Code)

Code Auswählen Erweitern

< snip >


Das mit dem Zähler könnte funktionieren, nur habe ich mich im Device auf kWh gerundet beschränkt, weil eine mehr oder weniger damals egal war

Damit sollte es, mit den Abrechnungen des jeweiligen EVU (z.B. Tibber) dann bei aktuell nutzbaren Stundenabrechnungen - selbst bei 1/4 Stundenwertabrechnungen, nur noch äußerst geringe Abweichungen durch Rundungen geben.

Bei meinen sehr geringen Bezugs- / Einspeiseleistungen reicht das z.B. vollkommen aus.
Ich bin der Auffassung das es bei "Stunden" - Verbrauchsdifferenzen von 0,XXXYYYY kWh nicht mehr maßgeblich auf die "YYYY" - Werte noch ankommen wird. 

Daher rührte mein Hinweis auf die Nachkomma stellen.

100 % kann ich es erst Mitte des Jahres sagen. Derzeit bin ich erst ab 1.4.24 bei Tibber und bringe deshalb meinen PV-Batterien grad bei diese zum richtigen Zeitpunkt (bei wenig Sonne und mit Berücksichtigung diverser Randbedingungen  - BHKW/Brennstoffzellen + Solarforcast) zu laden.......

Das mit Laden des Speicher, bzw. ansteuern der Starkverbraucher nach dem Tibber Trigger klappt ja bereits mit meinem EVU_Tibber_connect , nur habe ich keinen Börsen Tarif, da für meinen geringen Verbrauch nur eine Null Runde raus kommt. Das ganze ich halt momentan nur Hobby und Vorbereiten auf Eventualitäten.

VG   Christian

[300P]

Das mit Laden des Speicher, bzw. ansteuern der Starkverbraucher nach dem Tibber Trigger klappt ja bereits mit meinem EVU_Tibber_connect , nur habe ich keinen Börsen Tarif, da für meinen geringen Verbrauch nur eine Null Runde raus kommt. Das ganze ich halt momentan nur Hobby und Vorbereiten auf Eventualitäten.

VG  Christian

Bei mir wird es wohl ab diesen Winter "Ernst" und kein Hobby mehr mit dem "richtigen" Laden der Batterien.

Meine Brennstoffzelle feiert dieses Jahr das 9 jährige (und hat 10 Jahre Garantie......)

Einen weiteren neuen Stack werden die mir sicherlich nicht mehr einbauen, er ist bislang noch innerhalb der garantierten Leistung. 
Auch die Preise für die Wartung gehen auf über 1.000 Euro / Jahr für max. erreichbare ca. 3.500 -4.500 kWh und das Gas wird sicherlich auch noch wieder teurer werden.
Und ab dann wird sich Tibber bei mir auf jeden Fall mit Batterieladung rechnen.

[ch.eick]

Hallo zusammen,
ich habe  das MySQL SELECT mal weiter entwickelt und um die Preise von Tibber ergänzt, was dann jetzt so aussieht.
Die Preise stimmen momentan eventuell noch nicht

Code Auswählen Erweitern

# DATE, HOUR, price, consumption, cost
'2024-02-16', '0', '0.234', '4.6680', '1.0923'
'2024-02-16', '1', '0.2332', '4.5880', '1.0699'
'2024-02-16', '2', '0.2318', '4.5710', '1.0596'
'2024-02-16', '3', '0.2305', '4.5850', '1.0568'
'2024-02-16', '4', '0.2336', '4.5590', '1.0650'
'2024-02-16', '5', '0.2361', '4.5840', '1.0823'
'2024-02-16', '6', '0.2428', '4.5610', '1.1074'
'2024-02-16', '7', '0.255', '3.8400', '0.9792'
'2024-02-16', '8', '0.2563', '2.1760', '0.5577'
'2024-02-16', '9', '0.2496', '3.4430', '0.8594'
'2024-02-16', '10', '0.2371', '4.6060', '1.0921'
'2024-02-16', '11', '0.2355', '1.5800', '0.3721'
'2024-02-16', '12', '0.2347', '3.5930', '0.8433'
'2024-02-16', '13', '0.2347', '0.0230', '0.0054'
'2024-02-16', '14', '0.2364', '0.0150', '0.0035'
'2024-02-16', '15', '0.2469', '0.0130', '0.0032'
'2024-02-16', '16', '0.2557', '0.0110', '0.0028'
'2024-02-16', '17', '0.2588', '0.0020', '0.0005'
'2024-02-16', '18', '0.2646', '0.0000', '0.0000'
'2024-02-16', '19', '0.2638', '0.0000', '0.0000'
'2024-02-16', '20', '0.2587', '0.0000', '0.0000'
'2024-02-16', '21', '0.255', '0.0000', '0.0000'
'2024-02-16', '22', '0.2534', '0.0000', '0.0000'
'2024-02-16', '23', '0.2439', '0.0000', '0.0000'



Code Auswählen Erweitern

set @date=curdate();     -- Nur für heute
set @date='2024-02-12';  -- für einen bestimmten Tag

SELECT DATE, HOUR, price, VALUE As consumption, cast((VALUE * price) AS DECIMAL(10,4)) AS cost
FROM (
  SELECT date(TIMESTAMP) AS DATE, hour(TIMESTAMP) AS HOUR, VALUE AS price
  FROM history
  WHERE DEVICE  = 'EVU_Tibber_connect'
    AND READING = 'fc0_total'
    AND TIMESTAMP >= @date
    AND TIMESTAMP < DATE_ADD(@date,INTERVAL +1 DAY)
  ) x1
JOIN (
  SELECT DATE, HOUR,
         -- Durch max(DIFF) werden die 0 Verbraeuche wieder unterdrueckt
     -- Es wird in kWh mit 4 Nachkommastellen umgerechnet
         cast((max(DIFF)/1000) AS DECIMAL(10,4)) AS VALUE
  FROM (
        SELECT DATE, HOUR, VALUE, DIFF, DELTA
        FROM (
           -- Hier etsteht die Tabelle mit den Zaehlerdifferenzen
           SELECT DATE, HOUR, VALUE,
                  if(@diff = 0, 0, cast((VALUE-@diff) AS DECIMAL(10))) AS DIFF,
                  @diff:=VALUE AS curr_V,
                  TIMESTAMPDIFF(HOUR, @delta, concat(DATE,' ', LPAD(HOUR, 2, 0), ':00:00')) AS DELTA,
                  @delta:=concat(DATE,' ', LPAD(HOUR, 2, 0), ':00:00') AS curr_T
           FROM (
              SELECT DATE, HOUR,
                     max(VALUE) AS VALUE,
                     @diff:=0,@delta:=NULL    -- Das wird für die Differenzbildung gebraucht
              FROM (
                   -- Wir benoetigen den letzten Zaehlerstand vom Vortag als Wert um 23 Uhr
                   SELECT DATE_ADD(@date,INTERVAL -1 DAY) AS DATE,
                          '23' AS HOUR,
                          VALUE AS VALUE
                   FROM history
                   WHERE DEVICE = 'WR_1'
                     AND READING = 'SW_Total_home_consumption_Grid'
                     AND TIMESTAMP > DATE_ADD(@date,INTERVAL -1 DAY)
                     AND TIMESTAMP < @date
     
                 UNION ALL
     
                   -- Hier kommen alle Werte vom gewuenschten Tag
                   SELECT date(TIMESTAMP) AS DATE,
                          hour(TIMESTAMP) AS HOUR,
                          VALUE
                   FROM history
                   WHERE DEVICE = 'WR_1'
                     AND READING = 'SW_Total_home_consumption_Grid'
                     AND TIMESTAMP > @date
                     AND TIMESTAMP < DATE_ADD(@date,INTERVAL +1 DAY)
        ) t1
              GROUP BY DATE,HOUR
             ) t2
          ) t3
        WHERE DATE = @date    -- Der Vortag wird nicht mehr benoetigt
     
  UNION ALL
     
        SELECT convert(DATE USING UTF8), convert(HOUR USING UTF8), convert(VALUE USING UTF8), convert(DIFF USING UTF8), convert(DELTA USING UTF8)
        FROM (
           -- Es kann vorkommen, dass es in einer Stunde mal keinen Verbrauch gegeben hat,
  -- deshalb wird eine Tabelle mit 0 Verbraeuchen dazu gemischt
           VALUES
             ROW(@date, 0,null,0,1), ROW(@date, 1,null,0,1), ROW(@date, 2,null,0,1), ROW(@date, 3,null,0,1),
             ROW(@date, 4,null,0,1), ROW(@date, 5,null,0,1), ROW(@date, 6,null,0,1), ROW(@date, 7,null,0,1),
             ROW(@date, 8,null,0,1), ROW(@date, 9,null,0,1), ROW(@date,10,null,0,1), ROW(@date,11,null,0,1),
             ROW(@date,12,null,0,1), ROW(@date,13,null,0,1), ROW(@date,14,null,0,1), ROW(@date,15,null,0,1),
             ROW(@date,16,null,0,1), ROW(@date,17,null,0,1), ROW(@date,18,null,0,1), ROW(@date,19,null,0,1),
             ROW(@date,20,null,0,1), ROW(@date,21,null,0,1), ROW(@date,22,null,0,1), ROW(@date,23,null,0,1)
        ) t4 (DATE, HOUR, VALUE, DIFF, DELTA)     
    ) t5
  GROUP BY DATE,HOUR
  ORDER BY DATE,cast(HOUR AS DECIMAL(2))
  ) X2
USING (DATE, HOUR)
;


[ch.eick]

Das ist ganz einfach, aber nur schwer mit SQL zu lösen (glaub mir, hab das Zeug jahrelang unterrichtet).

Hallo pah,
gibt es eine Möglichkeit im SELECT mit VALUES ROW die Anzahl der Zeilen dynamisch zu generieren?
Bisher würde die Berechnung ja nur für einen Tag funktionieren, wenn ich die Stunden mit 0 Verbrauch ergänzen möchte.
Ich mische ja einfach eine Tabelle mit 0 Einträgen für jede Stunde unter und schmeiße sie hinterher, wenn sie nicht benötigt werden wieder raus.

Code Auswählen Erweitern

        SELECT convert(DATE USING UTF8), convert(HOUR USING UTF8), convert(VALUE USING UTF8), convert(DIFF USING UTF8), convert(DELTA USING UTF8)
        FROM (
           -- Es kann vorkommen, dass es in einer Stunde mal keinen Verbrauch gegeben hat,
  -- deshalb wird eine Tabelle mit 0 Verbraeuchen dazu gemischt
           VALUES
             ROW(@date, 0,null,0,1), ROW(@date, 1,null,0,1), ROW(@date, 2,null,0,1), ROW(@date, 3,null,0,1),
             ROW(@date, 4,null,0,1), ROW(@date, 5,null,0,1), ROW(@date, 6,null,0,1), ROW(@date, 7,null,0,1),
             ROW(@date, 8,null,0,1), ROW(@date, 9,null,0,1), ROW(@date,10,null,0,1), ROW(@date,11,null,0,1),
             ROW(@date,12,null,0,1), ROW(@date,13,null,0,1), ROW(@date,14,null,0,1), ROW(@date,15,null,0,1),
             ROW(@date,16,null,0,1), ROW(@date,17,null,0,1), ROW(@date,18,null,0,1), ROW(@date,19,null,0,1),
             ROW(@date,20,null,0,1), ROW(@date,21,null,0,1), ROW(@date,22,null,0,1), ROW(@date,23,null,0,1)
        ) t4 (DATE, HOUR, VALUE, DIFF, DELTA)