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
siehe weiter oben
Verwendet habe ich das MySQL SELECT natürlich außerhalb von FHEM in einem Tool meiner Wahl.
VG Christian
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
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)
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
Zitat von: Prof. Dr. Peter Henning am 14 Februar 2024, 15:34:39Das 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 :-)
ZitatDie 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
Zitat von: 300P am 14 Februar 2024, 16:58:00Vor 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)
< 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 :-)
ZitatDamit 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.
Zitat100 % 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
Zitat von: ch.eick am 14 Februar 2024, 17:29:54Das 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......) :o
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. :)
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 ;-)
# 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'
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)
;
Zitat von: Prof. Dr. Peter Henning am 14 Februar 2024, 15:34:39Das 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.
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)