Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

[misux]

Hallo ich wieder!

Erstens, vielen Dank an @ch.eick für das tolle Modul und seine Unterstützung! Hat mir wirklich sehr geholfen.

Nun eine Frage und vielleicht ein Verbesserungsvorschlag:

Wäre es machbar in die WR_1_API Tabelle noch den Quartal als Übersicht zu integrieren?
Wir müssen unsere Umsatzsteuervoranmeldunggedöns Quartalsweise abgeben und das wäre ja eine feine Sache wenn man es dort einfach ablesen könnte...
Vielleicht geht es den einem oder anderem genauso..

[ch.eick]

Nun eine Frage und vielleicht ein Verbesserungsvorschlag:

Wäre es machbar in die WR_1_API Tabelle noch den Quartal als Übersicht zu integrieren?
Wir müssen unsere Umsatzsteuervoranmeldunggedöns Quartalsweise abgeben und das wäre ja eine feine Sache wenn man es dort einfach ablesen könnte...
Vielleicht geht es den einem oder anderem genauso..

Moin in den Norden
Da das nicht direkt vom Plenticore so angeboten wird wäre das eher etwas für eine Datenbank Auswertung, wie wir es zufällig gestern schon besprochen hatten.
Die Auswertung würde dann alle drei Monate gestartet werden und das vor Quartal auswerten, so wie ich es mit dem Vorjahr ähnlich implementiert habe.
Zufällig würden sich die Quartale ja auch etwas mit den Jahreszeiten annähern, wodurch da auch ein schöner Überblick entstehen würde.

Ich fange mal an in SQL zu denken
Puh, das wird sicher etwas länglicher...

Gruß
    Christian

[ch.eick]

Und nochmal hallo

für die Jahres Auswertung im WR_1_API habe ich jetzt mal das SELECT modifiziert, damit es mit der MySQL Community Server Edition und den schärferen Anforderungen im GROUP BY zurecht kommt.
Würdet Ihr das dann bitte mal mit MariaDB testen? Also entweder direkt als SQL in der Datenbank oder im LogDBRep_Statistic_previous_Year Device, was dann auch das ergebnis im WR_1_API nach einem Device Update anzeigen sollte.

Code Auswählen Erweitern


SELECT
  h.TIMESTAMP,
  h.READING,
  cast(h.VALUE/1000 AS decimal(6)) AS VALUE
FROM history h
INNER JOIN
(
SELECT max(TIMESTAMP) AS TIMESTAMP,READING FROM history
  WHERE  ( DEVICE = 'WR_1_API' )
    AND  ( READING LIKE 'Statistic_%Year' )
    AND READING NOT LIKE '%Autarky%'
    AND READING NOT LIKE '%Rate%'
AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d')
    AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d')
  GROUP BY READING
) x1
  ON    h.TIMESTAMP = x1.TIMESTAMP
    AND h.READING   = x1.READING;


[misux]

Aber die Werte zaubert er doch nicht automatisch in die Tabelle im FHEM... Oder? Ich meine, da muss doch bestimmt die tabelle brutal im stateFormat angepasst werden damit die Spalte "letztes Quartal" existiert... Oder mit der Überschrift Q1 am 01.03, Q2 am 01.06, Q3 am 01.09, Q4 am 01.01 oder am 31.12..

Also wie auf dem Bild zwischen Monat und Jahr...

[ch.eick]

Aber die Werte zaubert er doch nicht automatisch in die Tabelle im FHEM... Oder? Ich meine, da muss doch bestimmt die tabelle brutal im stateFormat angepasst werden damit die Spalte "letztes Quartal" existiert... Oder mit der Überschrift Q1 am 01.03, Q2 am 01.06, Q3 am 01.09, Q4 am 01.01 oder am 31.12..

Also wie auf dem Bild zwischen Monat und Jahr...

Da überlege ich noch, denn dann würde die Tabelle viel breiter werden.
Es stellt sich auch die Frage, ob alle Quartale in der Tabelle dargestellt werden müssten.
Oder eventuell nur das letzte, oder rollierend?
Ich habe da noch keine Idee.
Das DbRep Device, dass das letzte Quartal liefert, hätte ich schon fertig.

Es wäre schön, wenn Ihr Euch mal Gedanken über die Darstellung macht und das eventuell einfach als Skizze abfotographiert und mir zuschickt.

[misux]

Oder eventuell nur das letzte, oder rollierend?

Ja so war mein Gedanke, denn eigentlich ist nur das das wichtige...

Also nur das letzte Quartal rotierend zwischen Monat und Jahr. Das passt locker von Platz her

[ch.eick]

Ja so war mein Gedanke, denn eigentlich ist nur das das wichtige...

Also nur das letzte Quartal rotierend zwischen Monat und Jahr. Das passt locker von Platz her

Na dann schau ich mal...

[kaiman]

Und nochmal hallo

für die Jahres Auswertung im WR_1_API habe ich jetzt mal das SELECT modifiziert, damit es mit der MySQL Community Server Edition und den schärferen Anforderungen im GROUP BY zurecht kommt.
Würdet Ihr das dann bitte mal mit MariaDB testen? Also entweder direkt als SQL in der Datenbank oder im LogDBRep_Statistic_previous_Year Device, was dann auch das ergebnis im WR_1_API nach einem Device Update anzeigen sollte.

Code Auswählen Erweitern


SELECT
  h.TIMESTAMP,
  h.READING,
  cast(h.VALUE/1000 AS decimal(6)) AS VALUE
FROM history h
INNER JOIN
(
SELECT max(TIMESTAMP) AS TIMESTAMP,READING FROM history
  WHERE  ( DEVICE = 'WR_1_API' )
    AND  ( READING LIKE 'Statistic_%Year' )
    AND READING NOT LIKE '%Autarky%'
    AND READING NOT LIKE '%Rate%'
AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d')
    AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d')
  GROUP BY READING
) x1
  ON    h.TIMESTAMP = x1.TIMESTAMP
    AND h.READING   = x1.READING;


ich hab den SQL mal im LogDBRep_Statistic_previous_Year laufen lassen und bekomme dort auch

Ausgaben als Readings

SqlResultRow_01
   
TIMESTAMP|READING|VALUE
   
2022-01-06 09:38:14
SqlResultRow_02
   
2021-12-31 23:57:03|Statistic_EnergyHome_Year|667
   
2022-01-06 09:38:14
SqlResultRow_03
   
2021-12-31 23:57:03|Statistic_EnergyHomeBat_Year|0
   
2022-01-06 09:38:14
SqlResultRow_04
   
2021-12-31 23:57:03|Statistic_EnergyHomeGrid_Year|529
   
2022-01-06 09:38:14
SqlResultRow_05
   
2021-12-31 23:57:03|Statistic_EnergyHomePv_Year|137
   
2022-01-06 09:38:14
SqlResultRow_06
   
2021-12-31 23:57:03|Statistic_EnergyPv1_Year|139
   
2022-01-06 09:38:14
SqlResultRow_07
   
2021-12-31 23:57:03|Statistic_EnergyPv2_Year|46
   
2022-01-06 09:38:14
SqlResultRow_08
   
2021-12-31 23:57:03|Statistic_Yield_Year|172
   
2022-01-06 09:38:14
SqlResultRow_09
   
2021-12-31 23:57:03|Statistic_EnergyHomePvSum_Year|137
   
2022-01-06 09:38:14
SqlResultRow_10
   
2021-12-31 23:57:03|Statistic_EnergyFeedInGrid_Year|35
   
2022-01-06 09:38:14
SqlResultRow_11
   
2021-12-31 23:57:03|Statistic_TotalConsumption_Year|667
   
2022-01-06 09:38:14
SqlResultRow_12
   
2021-12-31 23:57:03|Statistic_Yield_NoBat_Year|172

Nur im WR_1_API erscheint davon irgendwie nichts, habe ich noch etwas vergessen?

[ch.eick]

ich hab den SQL mal im LogDBRep_Statistic_previous_Year laufen lassen und bekomme dort auch

Nur im WR_1_API erscheint davon irgendwie nichts, habe ich noch etwas vergessen?

Danke für den Test.
Die Report readings bleiben im LogDBRep_Statistic_previous_Year Device, das nur einmal am anfang des Jahres ausgeführt werden müsste.
Ich habe auch ein Beispiel mit einer zusätzlichen Jahressumme für z.B. eine WallBox, was ich auch ganz spannend finde.

Die Anzeige wird im WR_1_API Device im stateFormat aufbereitet. Dort solltest Du in der "Jahr/Vorjahr" Spalte die Werte sehen. Ansonsten müsstest Du das stateFormat aus dem Wiki aktualisieren.

Momentan arbeite ich noch an den Quartals Zahlen, die dann später in der Monats Spalte angezeigt werden. Also immer schön mitlesen
Der DbRep Aufruf arbeitet bereits ganz gut und liefert alle vier vorherigen Quartale. Das vorherige wird dann mit "previous" gekennzeichnet, damit man das Rollieren für eine Anzeige umsetzen kann.

VG
   Christian

[Mumpitz]

Und nochmal hallo

für die Jahres Auswertung im WR_1_API habe ich jetzt mal das SELECT modifiziert, damit es mit der MySQL Community Server Edition und den schärferen Anforderungen im GROUP BY zurecht kommt.
Würdet Ihr das dann bitte mal mit MariaDB testen? Also entweder direkt als SQL in der Datenbank oder im LogDBRep_Statistic_previous_Year Device, was dann auch das ergebnis im WR_1_API nach einem Device Update anzeigen sollte.

Hallo
Bei mir funktioniert die Abfrage in mariaDB ebenfalls problemlos. Habe es direkt auf der Datenbank gemacht

[zwölfgang]

Und nochmal hallo

für die Jahres Auswertung im WR_1_API habe ich jetzt mal das SELECT modifiziert, damit es mit der MySQL Community Server Edition und den schärferen Anforderungen im GROUP BY zurecht kommt.
Würdet Ihr das dann bitte mal mit MariaDB testen? Also entweder direkt als SQL in der Datenbank oder im LogDBRep_Statistic_previous_Year Device, was dann auch das ergebnis im WR_1_API nach einem Device Update anzeigen sollte.

Mit der MariaDB hat das bei mir einwandfrei funktioniert. Habe das SELECT im LogDBRep_Statistic_previous_Year Device mit sqlCmd ausgeführt. Daten tauchen dann auch in der aktuellen WR_1_API perfekt auf.
Danke Christian.

Grüßle Wolfgang

[kaiman]

Danke für den Test.
Die Report readings bleiben im LogDBRep_Statistic_previous_Year Device, das nur einmal am anfang des Jahres ausgeführt werden müsste.
Ich habe auch ein Beispiel mit einer zusätzlichen Jahressumme für z.B. eine WallBox, was ich auch ganz spannend finde.

Die Anzeige wird im WR_1_API Device im stateFormat aufbereitet. Dort solltest Du in der "Jahr/Vorjahr" Spalte die Werte sehen. Ansonsten müsstest Du das stateFormat aus dem Wiki aktualisieren.

VG
   Christian

Danke für den Tip, aber irgendwie stehe ich auf dem Schlauch, ich habe den stateFormat aus dem Wiki, aber ich bekomme nur 0000 angezeigt.

Meine Readings heißen in der LogDBRep_Statistic_previous_Year alle SqlResultRow_01 bis 12. Passt das so?

Ich glaube der stateFormat im WR_1_API findet die Einträge nicht?

Gruß

[ch.eick]

Danke für den Tip, aber irgendwie stehe ich auf dem Schlauch, ich habe den stateFormat aus dem Wiki, aber ich bekomme nur 0000 angezeigt.

Meine Readings heißen in der LogDBRep_Statistic_previous_Year alle SqlResultRow_01 bis 12. Passt das so?

Ich glaube der stateFormat im WR_1_API findet die Einträge nicht?

Gruß

Nein, dass passt so noch nicht

Code Auswählen Erweitern


Im LogDBRep_Statistic_previous_Year  wird mit diesem Aufruf die Funktion splitReading aus der 99_myUtils aufgerufen, die wohl bei Dir noch fehlt.
userExitFn splitReading .*:.*

Dadurch werden die SqlResultRow_* in lesbare readings verwandelt.


Zusätzlich scheinst Du den Wechsel zu den SW_* userreadings nicht nachvollzogen zu haben, was jetzt und in Zukunft mehrarbeit bedeuten würde.
Im LogDBRep_Statistic_previous_Year Device wird im SQL SELECT nach 'SW_Statistic_%Year' gefiltert und nicht nach 'Statistic_%Year' . Bitte prüf das auch mal.

Generell sollten alle SW_* readings auch bei Betreibern mit nur einem WR funktionieren, dies erleichtert die Pflege der Devices insbesondere des stateFormat ernorm.

[ch.eick]

Hier nochmal der Link für die LogDBRep_Statistic_previous_Year Implementierung, da das noch nicht im Wiki ist
LogDBRep_Statistic_previous_Year

Achtung für alle die, die es bereits implementiert haben.
Die Funktion splitReading() hat sich geringfügig geändert, da der Filter nicht für die Quartalsabfragen, die ich gerade erstell gepasst hat.
Bitte korrigiert das schonmal.

[ch.eick]

Ich was fleißig und habe hier schonmal eine Vorschau für die Quartalsabfrage:

Code Auswählen Erweitern


READINGS:
     2021-03-31 23:59:00   Q1             
     2021-03-31 23:59:00   Q1_Statistic_EnergyHomeBat 283
     2021-06-30 23:59:00   Q2             
     2021-06-30 23:59:00   Q2_Statistic_EnergyHomeBat 393
     2021-09-30 23:59:00   Q3             
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyHome 1623
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyHomeFeedInGrid 4797
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyHomeGrid 16
     2021-09-30 23:59:00   Q3_SW_Statistic_TotalConsumption 1623
     2021-09-30 23:59:00   Q3_SW_Statistic_Yield 6404
     2021-09-30 23:59:00   Q3_Statistic_EnergyHomeBat 421
     2021-12-31 23:59:00   Q4              previous
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyHome 2583
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyHomeFeedInGrid 511
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyHomeGrid 1378
     2021-12-31 23:59:00   Q4_SW_Statistic_TotalConsumption 2583
     2021-12-31 23:59:00   Q4_SW_Statistic_Yield 1716
     2021-12-31 23:59:00   Q4_Statistic_EnergyHomeBat 330

Q1 und Q2 hatte ich noch keinen Schwarm, weshalb die Werte nicht angezeigt werden. Wenn man die auch haben möchte, müsste man noch etwas in der Datenbank aufräumen.

Da es sich um rollierende Quartale handelt wird mit dem Eintrag "Q* previous" das letzte Quartal markiert. Alle anderen müssten dann in umgekehrter Reihenfolge davor gelesen werden.

Beispiel:
2022-03-31 wird in einiger Zeit das vorherige Quartal sein.
Somit ergibt sich die Verarbeitsreihenfolge: Q1 previos , Q4, Q3, Q2

Ich baue jetzt das "previous" Quartal ins stateFormat von WR_1_API ein.

Stay tuned
   Christian