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

ozwo · 24 Mai 2021, 20:48:33

Hallo Christian,
vielen Dank für die ersten Ausführungen.

ZitatSchau mal bitte nach Deiner Version, da gerade die 1.19 raus gekommen ist. Die habe ich mir noch nicht angesehen.
Falls Du einen downgrade machen möchtest, habe ich die alten Versionen noch bei mir auf dem Rechner. Dann bitte eine PN.

Ich bin schon auf 1.19.

Code Auswählen

Software-Version_IO-Controller_IOC 01.55
Software-Version_Maincontroller_MC 01.55

Das schaue ich mir dann noch gesondert an - ich würde beim WR erstmal bei der 1.19 bleiben. Falls der Zusammenhang hier überhaupt stimmt und ich nicht einen anderen Fehler habe.

ZitatDie readings Solar_* werden durch die Leistungsprognose mit der Funktion Solar_forecast(), erzeugt, die Du dann wohl noch nicht verwendest.

Doch - ich verwende auch die Solar_forecast()-Funktion. Die Readings sind auch im WR_1 (Solar_Calculation, Solar_Calculation_f0_07/08/usw.). Also die kompletten Stunden/4h/Tageswerte. Aber die in Grafana benutzten Solar_Calculation_fc0/1 genau nicht...

Im Zusammenhang mit der Solar_forecast() habe ich auch noch ein interessantes Phänomen:
Es wird ja pro Durchlauf des Forecasts der "Solar_Correction_Faktor_auto" in die DB geschrieben - als Stundenwert. Bei mir wird aber der Zeileneintrag nicht überschrieben, sondern jeweils ein neuer Eintrag erzeugt. Hänge ich mal als Screenshot an.

Das gibt dann natürlich in Solar_forecast() an folgender Stelle einen Fehler, weil immer alle Werte für die ausgewählte Stunde zurückgegeben werden:

Code Auswählen

       if ($autocorrection ne 0) {
         $Solar_Correction_Faktor_auto = CommandGet(undef, $logdbrep." sqlCmdBlocking SELECT VALUE FROM history WHERE DEVICE='".$logdevice."' AND READING='Solar_Correction_Faktor_auto' AND TIMESTAMP='".sprintf("%4d-%02d-%02d %02d:00:00",$year,$mon,$mday,$i)."';") ;
       if($Solar_Correction_Faktor_auto eq "") { $Solar_Correction_Faktor_auto = 1; };
       };

Mein Workaround dazu ist aktuell ein "SELECT DISTINCT" an dieser Stelle. Tut nicht so weh, füllt aber unnötig die DB...
Dazu habe ich aber auch noch keine Ursache finden können...ist ja immer so eine Sache mit dem Reverse-Engineering...

ZitatBitte beachte, dass ich bereits eine Schwarm Installation habe und mich somit immer auf die SW_* readings beziehe. Die sollten dann bei Dir die selben Werte beinhalten, wie die reading Namen ohne "SW_" .

Kannst Du mir dazu mal eine Rückmeldung geben, da nicht alle Anwender den wechsel bereits gemacht haben.

Klar, gerne: Die SW_*-Readings sind bei mir mit einem Wechselrichter anscheinend alle identisch zu den passenden Readings ohne SW_ gefüllt. Das scheint also prima zu passen und man muss offenbar die Konfig nicht weiter anpassen. WR_2 habe ich gar nicht angelegt.

ch.eick · 24 Mai 2021, 21:43:08

Zitat von: ozwo am 24 Mai 2021, 20:48:33
Doch - ich verwende auch die Solar_forecast()-Funktion. Die Readings sind auch im WR_1 (Solar_Calculation, Solar_Calculation_f0_07/08/usw.). Also die kompletten Stunden/4h/Tageswerte. Aber die in Grafana benutzten Solar_Calculation_fc0/1 genau nicht...

Im Zusammenhang mit der Solar_forecast() habe ich auch noch ein interessantes Phänomen:
Es wird ja pro Durchlauf des Forecasts der "Solar_Correction_Faktor_auto" in die DB geschrieben - als Stundenwert. Bei mir wird aber der Zeileneintrag nicht überschrieben, sondern jeweils ein neuer Eintrag erzeugt. Hänge ich mal als Screenshot an.

Das gibt dann natürlich in Solar_forecast() an folgender Stelle einen Fehler, weil immer alle Werte für die ausgewählte Stunde zurückgegeben werden:
Code Auswählen Erweitern
if ($autocorrection ne 0) { $Solar_Correction_Faktor_auto = CommandGet(undef, $logdbrep." sqlCmdBlocking SELECT VALUE FROM history WHERE DEVICE='".$logdevice."' AND READING='Solar_Correction_Faktor_auto' AND TIMESTAMP='".sprintf("%4d-%02d-%02d %02d:00:00",$year,$mon,$mday,$i)."';") ; if($Solar_Correction_Faktor_auto eq "") { $Solar_Correction_Faktor_auto = 1; }; };

Mein Workaround dazu ist aktuell ein "SELECT DISTINCT" an dieser Stelle. Tut nicht so weh, füllt aber unnötig die DB...
Dazu habe ich aber auch noch keine Ursache finden können...ist ja immer so eine Sache mit dem Reverse-Engineering...

Prüfe mal, ob Du auch einen primary Key definiert hast, damit sollte es keine doppelten Einträge in der DB geben.
EDIT: Du hast definitiv die Definition bezüglich duplicate key nicht gemacht, bzw Du hast keinen primary Key definiert. Das kann man nachholen, ist jedoch etwas Arbeit.

Dann schau Dir das LogDBRep_PV_Forecast_SQL Device nochmal an, denn das ist das Bindeglied für Solar_forecast() zur Datenbank.
In der Solar_forecast() Funktion ist etwas SQL drin, das mit einem "INSERT INTO ...... ON DUPLICATE KEY UPDATE" die Einträge über das LogDBRep_PV_Forecast_SQL Device berechnet und einträgt.
Die Parametrisierung ist über dieses Attribut möglich.
@reading2 ist der reading Name, den Du vermisst.

Code Auswählen


sqlCmdVars
SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;

In einer mysql Session kannst Du den Vorgang testen

Code Auswählen


## Auswertung WR_1 Prognose der letzten 30 Tage
## Differenz und Faktor zwischen fc0 und Realit\u00e4t mit D\u00e4mpfung von *0.7 und Limitierung bei 1.6
##
## Das wird einmal gesetzt
MySQL [fhem]> SET @device='WR_1';
MySQL [fhem]> SET @reading1='SW_Total_DC_P_sumOfAllPVInputs';
MySQL [fhem]> SET @reading2='Solar_Calculation_fc0';
MySQL [fhem]> SET @readingname='Solar_Correction_Faktor_auto';

## Ein List der Solar_Calculation_fc0 , die durch die Solar_forecast() Funktion geschrieben werden, was am addlog zu erkennen ist.
## Bei der DbLog muss der cache aktive sein!
  
MySQL [fhem]> SELECT * FROM history WHERE DEVICE=@device AND READING=@reading2 AND TIMESTAMP >= CURDATE();
+---------------------+--------+--------+-------+-----------------------+-------+------+
| TIMESTAMP           | DEVICE | TYPE   | EVENT | READING               | VALUE | UNIT |
+---------------------+--------+--------+-------+-----------------------+-------+------+
| 2021-05-24 07:00:00 | WR_1   | addlog |       | Solar_Calculation_fc0 | 2447  |      |
| 2021-05-24 08:00:00 | WR_1   | addlog |       | Solar_Calculation_fc0 | 5013  |      |
| 2021-05-24 09:00:00 | WR_1   | addlog |       | Solar_Calculation_fc0 | 6872  |      |
< snip >
| 2021-05-24 18:00:00 | WR_1   | addlog |       | Solar_Calculation_fc0 | 2183  |      |
| 2021-05-24 19:00:00 | WR_1   | addlog |       | Solar_Calculation_fc0 | 1706  |      |
| 2021-05-24 20:00:00 | WR_1   | addlog |       | Solar_Calculation_fc0 | 251   |      |
+---------------------+--------+--------+-------+-----------------------+-------+------+
14 rows in set (0.097 sec)

## Vor jedem Durchlauf werden diese Variablen gesetzt
MySQL [fhem]> SET @diff=0;SET @temp=0;SET @corr=0.7;SET @days=30;

## Eine Abfrage der aktuellen Einträge ginge so
MySQL [fhem]> SELECT * FROM history WHERE DEVICE=@device AND READING=@readingname AND TIMESTAMP >= CURDATE();
+---------------------+--------+------+-------+------------------------------+-------+------+
| TIMESTAMP           | DEVICE | TYPE | EVENT | READING                      | VALUE | UNIT |
+---------------------+--------+------+-------+------------------------------+-------+------+
| 2021-05-24 06:00:00 | WR_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 1.3   | NULL |
| 2021-05-24 07:00:00 | WR_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.8   | NULL |
< snip >
| 2021-05-24 20:00:00 | WR_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.3   | NULL |
+---------------------+--------+------+-------+------------------------------+-------+------+
15 rows in set (0.138 sec)
>>>>> hier darf jeder Eintrag nur einmal vorhanden sein, ansonsten ist in der DB kein primary key definiert!!!

## Eine Aktualisierung wird mit dem SQL aus der Solar_forecast() gemacht. Achtung, die Formatierung innerhalb von Perl ist etwas anders wegen der Sonderzeichen.

## Hier der original SQL Code
INSERT INTO history
 (TIMESTAMP,DEVICE,READING,VALUE)
  SELECT
    TIMESTAMP,DEVICE,READING,VALUE
  FROM (
    SELECT
      DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP,
      t2.DEVICE,
      @readingname                              AS READING,
      cast(if(avg(t2.FACTOR) > 1.6, 1.6,
              avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE
    FROM (
      SELECT * FROM (
        SELECT
          t1.TIMESTAMP,
          t1.HOUR,
          t1.DEVICE,
          t1.READING,
          t1.VALUE,
          if(@diff  = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF,
          cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(2,1))         AS FACTOR,
          @diff:=t1.VALUE                                                    AS curr_V
        FROM (
          SELECT
            TIMESTAMP,
            date(TIMESTAMP) AS DATE,
            hour(TIMESTAMP) AS HOUR,
            DEVICE,
            READING,
            VALUE
          FROM history
          WHERE DEVICE    =  @device
            AND (READING  =  @reading1 OR READING = @reading2)
            AND TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY)
            AND TIMESTAMP <= CURDATE()
            AND MINUTE(TIMESTAMP) = 0
            AND VALUE >= 0
          GROUP BY DATE,HOUR,READING
         )t1
       )tx
        WHERE
          READING != @reading2
     )t2
      GROUP BY t2.HOUR
   )t3
    WHERE
      t3.VALUE != 0
    ON DUPLICATE KEY UPDATE
      VALUE=t3.VALUE;

Query OK, 0 rows affected, 27 warnings (5.708 sec)
Records: 15  Duplicates: 0  Warnings: 27

## Dann wieder den SELECT zum Anschauen

## Für einen neuen Lauf zuerst wieder die Variablen setzen ( s.o.)

Das wäre dann jetzt ein Test für die Berechnung der Autokorrektur.

[/quote]
Klar, gerne: Die SW_*-Readings sind bei mir mit einem Wechselrichter anscheinend alle identisch zu den passenden Readings ohne SW_ gefüllt. Das scheint also prima zu passen und man muss offenbar die Konfig nicht weiter anpassen. WR_2 habe ich gar nicht angelegt.
[/quote]
Okay super, dann klappt das ja so wie ich es mir gedacht hatte. Wenn WR_2 nicht da ist zieht der Default von 0 in den userreadings.

Ich teste dann mal bald die v1.19, denn Kostal ändert schon gerne mal die ModBus Register. Wenn Du da fit bist, kannst Du natürlich gerne auch die richtigen unpack suchen und dann posten.

VG
Christian

ch.eick · 25 Mai 2021, 17:32:44

Hallo Oliver,
es geht nochmal um diese readings

Zitat
Code Auswählen Erweitern
2021.05.24 18:25:04.402 3: WR_1: CreateDataObjects unpack of 0038 with f> for Battery_Actual_SOC resulted in undefined value 2021.05.24 18:25:04.802 3: WR_1: CreateDataObjects unpack of 017f with f> for Inverter_Generation_P_Actual resulted in undefined value 2021.05.24 18:25:04.949 3: WR_1: CreateDataObjects unpack of 0004 with N for Battery_Type resulted in undefined value

Das Register Battery_Actual_SOC scheint bisher nur in der Dokumentation aufgenommen worden zu sein.
Der gewünschte Wert ist jedoch im reading Act_state_of_charge zu finden und wird momentan dort auch von mir verwendet.
Dieses Register lasse ich ermal noch definiert, da Kostal in den letzten Versionen für die Batterie einiges geändert hat. Eventuell kommt da ja noch was.
Die BA_KOSTAL_Interface_MODBUS-TCP_SunSpec.pdf Dokumentation wurde zu letzt im Dezember aktualisiert.

Das Register Inverter_Generation_P_Actual scheint es noch zu geben, es kommt jedoch immer 0.00

Code Auswählen


Wenn man das löscht bekommt man die 0.00
deleteattr WR_1 obj-h575-len 1

Dann sollte das reading entstehen:
Inverter_Generation_P_Actual 0.00

Ich werde es jedoch im Wiki einfach löschen:

deleteattr WR_1 obj-h575-len
deleteattr WR_1 obj-h575-reading

Bei diesem Register kommt kein Wert: Battery_Type
Jedoch ist die Information im WR_1_API:Battery_InternControl_Type verfügbar.

Code Auswählen


deleteattr WR_1 obj-h588-format
deleteattr WR_1 obj-h588-len
deleteattr WR_1 obj-h588-reading
deleteattr WR_1 obj-h588-unpack

Leider beinhalten die ModBus Register und die API Abfragen teilweise falsche und auch unterschiedliche Inhalte, obwohl sie gleich sein sollten. Ich hatte dazu in Bezug auf die Batterie bereits mal eine Anfrage an Kostal geschickt, die auch mit einer Nachfrage beantwortet wurde, nur konnte es wohl dort niemand nachvollziehen

Bei der nächsten Version der Kostal Dokumentation werde ich dann mal wieder aufräumen.

Gruß
Christian

ozwo · 25 Mai 2021, 17:47:13

Hallo Christian,

hab' gerade Feierabend und wollte mich später nochmal an das Thema setzen - jetzt kommst Du mir netterweise zuvor.

Zitates geht nochmal um diese readings

Interessant - vielen Dank für die Infos dazu. Wundern tut mich aber schon, dass die Readings ja so schon auch (zumindest seit ich die Lösung nutze) im WR_1 eingetragen sind, bisher aber keine Fehlermeldungen dazu kamen...
...solange die (fehlenden) Readings keine Auswirkungen auf den Rest der Konfig haben, passt es ja...

Was die Datenbankeinträge angeht:

ZitatPrüfe mal, ob Du auch einen primary Key definiert hast, damit sollte es keine doppelten Einträge in der DB geben.
EDIT: Du hast definitiv die Definition bezüglich duplicate key nicht gemacht, bzw Du hast keinen primary Key definiert. Das kann man nachholen, ist jedoch etwas Arbeit.

Ich hatte bereits vor dem Einrichten des Plenticore nach Deiner Anleitung eine LogDB im Einsatz, mich aber bisher nie weiter mit dem Thema beschäftigt bzw. nur mal rudimentär grafisch ausgewertet, wann es bei unserer lokalen Tanke besonders günstig ist...
...jetzt mit Photovoltaik und Grafana beginnt das Thema ja erst richtig spannend zu werden.
Die Doku zum DBLog habe ich mir aber nie tiefer angeschaut und in Deinem Wiki steht ja auch nur "sollte vorhanden sein"...

Lange Rede, kurzer Sinn: hast Du einen Hinweis, wie ich die DB bzgl. Primary Key auf Stand bringen kann? Ggf. lege ich auch eine neue DB an, falls das einfacher sein sollte. Daten kann man dann ja per Export/Import immer noch übertragen.

Danke und Grüße
Oliver

ch.eick · 25 Mai 2021, 18:51:16

Zitat von: ozwo am 25 Mai 2021, 17:47:13
Was die Datenbankeinträge angeht:Ich hatte bereits vor dem Einrichten des Plenticore nach Deiner Anleitung eine LogDB im Einsatz, mich aber bisher nie weiter mit dem Thema beschäftigt bzw. nur mal rudimentär grafisch ausgewertet, wann es bei unserer lokalen Tanke besonders günstig ist...
...jetzt mit Photovoltaik und Grafana beginnt das Thema ja erst richtig spannend zu werden.
Die Doku zum DBLog habe ich mir aber nie tiefer angeschaut und in Deinem Wiki steht ja auch nur "sollte vorhanden sein"...

Lange Rede, kurzer Sinn: hast Du einen Hinweis, wie ich die DB bzgl. Primary Key auf Stand bringen kann? Ggf. lege ich auch eine neue DB an, falls das einfacher sein sollte. Daten kann man dann ja per Export/Import immer noch übertragen.

Zuerst immer ein Backup machen

Hiermit kannst Du prüfen, ob Du duplicate keys hast:

Code Auswählen


SELECT
  TIMESTAMP, COUNT(TIMESTAMP),
  DEVICE, COUNT(DEVICE),
  READING, COUNT(READING)
FROM history
GROUP BY
  TIMESTAMP,
  DEVICE,
  READING
HAVING COUNT(TIMESTAMP)>1
  AND COUNT(DEVICE)>1
  AND COUNT(READING)>1;

## So kannst Du den Key abfragen

MySQL [fhem]> show index from history where Key_name = 'PRIMARY' ;
+---------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table   | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| history |          0 | PRIMARY  |            1 | TIMESTAMP   | A         |    10658576 |     NULL | NULL   |      | BTREE      |         |               |
| history |          0 | PRIMARY  |            2 | DEVICE      | A         |    10658576 |     NULL | NULL   |      | BTREE      |         |               |
| history |          0 | PRIMARY  |            3 | READING     | A         |    10658576 |     NULL | NULL   |      | BTREE      |         |               |
+---------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

Dann noch den Key über mehrere Spalten eintragen

Code Auswählen


ALTER TABLE history ADD PRIMARY KEY(TIMESTAMP,DEVICE,READING);

Nun werden Fehler auftreten, wenn vorher nicht die doppelten Einträge gelöscht wurden.

Dann müssen natürlich noch die doppelten Einträge gelöscht werden, was die meiste Zeit brauchen wird.

Beim Export/Import musst Du aber auch manuell tausende Einträge löschen.
Wenn es nur die Solar_* Einträge sind, auf die kannst Du sicherlich einfach verzichten. Was interessiert schon die Prognose der letzten Wochen

VG
Christian

ch.eick · 25 Mai 2021, 19:18:54

Nabääänd,

ich habe jetzt bereits auf die Version 1.19 aktualisiert und bisher keine Probleme festgestellt.

Sollte übrigens mal der WR den Zugang sperren, so steht folgendes reading auf 1

Code Auswählen


auth_me_locked 1

Dann einfach auf das Web Gui des Plenticore und das Passwort wieder zurück setzen. Gefragt wird nach dem Master Key, den ich dann auch wieder als Passwort setze.

VG
Christian

ozwo · 25 Mai 2021, 20:59:31

Hi Christian,

vielen Dank für's Vorkauen...

Ich habe es nun wie folgt gelöst (falls noch jemand anders mal in die Verlegenheit kommt):

Alles ohne Gewähr - ich bin kein DB-Spezi.
Denkt immer dran: Kein Backup, kein Mitleid...

Code Auswählen

## 1. Doppelte Einträge finden:
SELECT
  TIMESTAMP, COUNT(TIMESTAMP),
  DEVICE, COUNT(DEVICE),
  READING, COUNT(READING)
FROM history
GROUP BY
  TIMESTAMP,
  DEVICE,
  READING
HAVING COUNT(TIMESTAMP)>1
  AND COUNT(DEVICE)>1
  AND COUNT(READING)>1;

## 2.) Temporäre history-Tabelle anlegen

CREATE TABLE temp_history LIKE history;

## 3.) Primary Key für temp_history erstellen

ALTER TABLE temp_history ADD PRIMARY KEY(TIMESTAMP,DEVICE,READING);

## 4.) Daten ohne Duplikate kopieren:

INSERT INTO temp_history
(SELECT * FROM history
 GROUP BY
  timestamp,
  device,
  reading
);

## 4a.) temp_history mit Kommando aus 1.) auf doppelte Einträge checken => es sollte keine geben...

## 5.) Original-history löschen
DROP TABLE history;

## 6.) Temp-history zu history machen
RENAME TABLE temp_history TO history;

Nochmal dank an Christian,

Grüße
Oliver

P.S.: ich habe die Chance genutzt und zwischendrin noch einige Uralt-Einträge aus der DB gelöscht...

ch.eick · 26 Mai 2021, 11:56:22

Moin,
ich habe in der plenticore_auth() einen kleinen Schönheitsfehler beseitigt.
Ihr könnt die Zeile auch einzeln austauschen. Das beseitigt eine Fehlermeldung im Log bei einer Neuanmeldung am WR.

Code Auswählen


fhem "setreading ".$logdevice."  auth_randomString64 ".$u ;

ersetzen durch...

CommandSetReading(undef, $logdevice." auth_randomString64 ".$u) ;

Danach ein "reload 99_myUtils"

VG
Christian

ch.eick · 26 Mai 2021, 12:03:31

Und noch eine Frage für einen Stammtisch:

1. Wann würdet Ihr es bevorzugen? Innerhalb der Woche oder am WE
~~2. Welches Tool für Videopräsentationen ist Euch geläufig?~~

Rückmeldung bitte per PN, ich fasse das Ergebnis dann zusammen.

EDIT: Die Entscheidung für's Tool ist gefallen, es wird Zoom

ch.eick · 27 Mai 2021, 12:37:45

Moin,

es wieder Zeit etwas aufzuräumen. Alle, die bereits die letzte WR_1 Device Definition laufen haben werden sicher bemerkt haben, dass nun einige Werte doppelt in der DbLog erscheinen.
Dies hatte ich so gemacht, um festzustellen ob die SW_* Werte okay sind auch wenn man nur einen WR betreibt.
Durch Oliver ist dies ja nun bestätigt worden, sodass das Logging der nicht mehr verwendeten readings nun abgeschaltet werden kann.

Hierbei müsst Ihr natürlich vorher prüfen, ob alle Werte aus der Zeit bevor die SW_* readings eingeführt wurden auch entsprechend umbenannt wurden.
Meine Grafana Diagramme und das Dashboard beziehen sich nur noch auf die SW_* readings, was also auch bei nur einem WR funktionieren sollte.

Aktuelle Definition

Code Auswählen


attr WR_1 DbLogInclude Act_state_of_charge,Actual_Battery_charge_-minus_or_discharge_-plus_P,Actual_Battery_charge_usable_P,Battery_Total.*,Battery_charge.*,Battery_gross.*,Battery_temperature,Home_own_consumption.*,P_DC1,P_DC2,Total_DC_P.*,Total_DC_PV_Energy.*,Total_PV_P_reserve,Total_Active_P_EM,Solar_Calculation,Solar_Calculation_fc0_4h,Solar_Calculation_fc0_day,Solar_Calculation_fc0_rest,Solar_Correction.*,Solar_Cloud,Solar_East_Covered,Solar_Rain,Solar_SolarRadiation,Solar_Temp,Solar_WR_.*,Solar_middayhigh.*,SW_.*,Inverter_state.*

SW_* readings

Code Auswählen


SW_Home_own_consumption
SW_Home_own_consumption_from_Battery
SW_Home_own_consumption_from_PV
SW_Home_own_consumption_from_grid
SW_Total_AC_Active_P
SW_Total_DC_P
SW_Total_DC_P_Max
SW_Total_DC_P_sumOfAllPVInputs
SW_Total_PV_P_reserve
SW_Yield_Daily
SW_Yield_Monthly
SW_Yield_Total
SW_Yield_Yearly

Doppelte readings

Code Auswählen


Home_own_consumption.*
Total_DC_P
Total_DC_P_Max
Total_DC_P_sumOfAllPVInputs
Total_PV_P_reserve

Neue DbLogInclude definition

Code Auswählen


attr WR_1 DbLogInclude Act_state_of_charge,Actual_Battery_charge_-minus_or_discharge_-plus_P,Actual_Battery_charge_usable_P,Battery_Total.*,Battery_charge.*,Battery_gross.*,Battery_temperature,P_DC1,P_DC2,Total_DC_PV_Energy_sumOfAllPVInputs,Total_Active_P_EM,Solar_Calculation,Solar_Calculation_fc0_4h,Solar_Calculation_fc0_day,Solar_Calculation_fc0_rest,Solar_Correction.*,Solar_Cloud,Solar_East_Covered,Solar_Rain,Solar_SolarRadiation,Solar_Temp,Solar_WR_.*,Solar_middayhigh.*,SW_.*

mysql Abfrage aller readings eines Devices innerhalb eines Tages

Code Auswählen


SET @device = 'WR_1';
SELECT t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
  FROM history t1
  INNER JOIN
   (SELECT max(TIMESTAMP) AS TIMESTAMP,DEVICE,READING
      FROM history
      WHERE DEVICE    = @device AND
            TIMESTAMP > NOW() - INTERVAL 1 DAY
      GROUP BY READING) x
  ON x.TIMESTAMP = t1.TIMESTAMP AND
     x.DEVICE    = t1.DEVICE    AND
     x.READING   = t1.READING;

+---------------------+--------+----------------------------------------------------+------------+
| TIMESTAMP           | DEVICE | READING                                            | VALUE      |
+---------------------+--------+----------------------------------------------------+------------+
| 2021-05-27 11:29:02 | WR_1   | Actual_Battery_charge_-minus_or_discharge_-plus_P  | 11         |
| 2021-05-27 10:59:00 | WR_1   | Actual_Battery_charge_usable_P                     | 5914       |
| 2021-05-27 10:00:05 | WR_1   | Act_state_of_charge                                | 76.00      |
| 2021-05-27 11:25:02 | WR_1   | Battery_temperature                                | 21.20      |
| 2021-05-27 09:21:06 | WR_1   | Battery_Total_AC_ChargeEnergy_ACsideToBattery      | 1720.42    |
| 2021-05-27 09:21:06 | WR_1   | Battery_Total_AC_ChargeEnergy_gridToBattery        | 1369.31    |
| 2021-05-27 11:26:07 | WR_1   | Battery_Total_AC_DischargeEnergy_BatteryToGrid     | 899685.38  |
| 2021-05-27 11:26:07 | WR_1   | Battery_Total_DC_ChargeEnergy_DCsideToBattery      | 711192.31  |
| 2021-05-27 11:26:07 | WR_1   | Battery_Total_DC_DischargeEnergy_DCsideFromBattery | 645357.38  |
| 2021-05-27 11:30:01 | WR_1   | Home_own_consumption_from_Battery                  | 0.80       |
| 2021-05-27 10:39:01 | WR_1   | Home_own_consumption_from_grid                     | 0.00       |
| 2021-05-27 11:30:01 | WR_1   | Home_own_consumption_from_PV                       | 273.20     |
| 2021-05-27 11:30:03 | WR_1   | P_DC1                                              | 1659.09    |
| 2021-05-27 11:30:03 | WR_1   | P_DC2                                              | 1412.15    |
| 2021-05-27 11:00:01 | WR_1   | Solar_Calculation                                  | 2539       |
| 2021-05-27 20:00:00 | WR_1   | Solar_Calculation_fc0                              | 347        |
| 2021-05-27 11:00:02 | WR_1   | Solar_Calculation_fc0_4h                           | 11128      |
| 2021-05-27 07:00:02 | WR_1   | Solar_Calculation_fc0_day                          | 28133      |
| 2021-05-27 11:00:02 | WR_1   | Solar_Calculation_fc0_rest                         | 21649      |
| 2021-05-28 20:00:00 | WR_1   | Solar_Calculation_fc1                              | 603        |
| 2021-05-27 11:00:01 | WR_1   | Solar_Cloud                                        | 88         |
| 2021-05-27 11:00:01 | WR_1   | Solar_Correction_Cloud                             | 0.604      |
| 2021-05-27 20:00:00 | WR_1   | Solar_Correction_Faktor_auto                       | 0.5        |
| 2021-05-27 08:00:01 | WR_1   | Solar_Correction_Rain                              | 0.660      |
| 2021-05-27 11:00:01 | WR_1   | Solar_Correction_Temp                              | 1.007      |
| 2021-05-27 08:00:01 | WR_1   | Solar_Rain                                         | 170        |
| 2021-05-27 11:00:01 | WR_1   | Solar_SolarRadiation                               | 353        |
| 2021-05-27 11:00:01 | WR_1   | Solar_Temp                                         | 23.2       |
| 2021-05-27 11:00:01 | WR_1   | Solar_WR_1_Ost                                     | 1291       |
| 2021-05-27 11:00:01 | WR_1   | Solar_WR_1_West                                    | 260        |
| 2021-05-27 11:00:01 | WR_1   | Solar_WR_2_Sued                                    | 792        |
| 2021-05-27 11:00:01 | WR_1   | Solar_WR_2_West                                    | 196        |
| 2021-05-27 11:30:02 | WR_1   | SW_Home_own_consumption                            | 2818       |
| 2021-05-27 11:30:02 | WR_1   | SW_Home_own_consumption_from_Battery               | 0.80       |
| 2021-05-27 10:39:02 | WR_1   | SW_Home_own_consumption_from_grid                  | 0.00       |
| 2021-05-27 11:30:02 | WR_1   | SW_Home_own_consumption_from_PV                    | 2817.2     |
| 2021-05-27 11:30:02 | WR_1   | SW_Total_AC_Active_P                               | 5261       |
| 2021-05-27 11:30:07 | WR_1   | SW_Total_DC_P                                      | 5432       |
| 2021-05-27 11:30:07 | WR_1   | SW_Total_DC_P_Max                                  | 5455       |
| 2021-05-27 11:30:07 | WR_1   | SW_Total_DC_P_sumOfAllPVInputs                     | 5444       |
| 2021-05-27 11:30:07 | WR_1   | SW_Total_PV_P_reserve                              | 2082       |
| 2021-05-27 11:26:04 | WR_1   | SW_Yield_Daily                                     | 11744      |
| 2021-05-27 11:26:04 | WR_1   | SW_Yield_Monthly                                   | 1828693    |
| 2021-05-27 11:26:04 | WR_1   | SW_Yield_Total                                     | 15965035   |
| 2021-05-27 11:26:04 | WR_1   | SW_Yield_Yearly                                    | 5550944    |
| 2021-05-27 11:30:03 | WR_1   | Total_Active_P_EM                                  | -2473.60   |
| 2021-05-27 11:30:01 | WR_1   | Total_DC_P                                         | 3070.14    |
| 2021-05-27 11:26:07 | WR_1   | Total_DC_PV_Energy_sumOfAllPVInputs                | 3984855.25 |
| 2021-05-27 11:30:07 | WR_1   | Total_DC_P_Max                                     | 3090       |
| 2021-05-27 11:30:07 | WR_1   | Total_DC_P_sumOfAllPVInputs                        | 3078.61    |
| 2021-05-27 11:30:07 | WR_1   | Total_PV_P_reserve                                 | 2498       |
+---------------------+--------+----------------------------------------------------+------------+

Für das finden der Überschneidung habe ich einfach mal die Anzahl der Einträge durchgezählt

Code Auswählen


MySQL [fhem]> select date(TIMESTAMP) AS DATE from history where DEVICE='WR_1' and READING='SW_Home_own_consumption_from_PV' and TIMESTAMP>'2021-03-22' group by DATE limit 100;
MySQL [fhem]> select date(TIMESTAMP) AS DATE from history where DEVICE='WR_1' and READING='Home_own_consumption_from_PV' and TIMESTAMP>'2021-03-22' group by DATE limit 100;

Danach nochmals kurz die Einträge angeschaut und anschließende gelöscht, oder halt wie früher schon mal beschrieben umbenannt (achtet auf TIMESTAMP=TIMESTAMP

)

Code Auswählen


MySQL [fhem]> delete from history where DEVICE='WR_1' and READING='Home_own_consumption_from_PV';

Das dann für alle doppelten Loggings und schon ist wieder Ordnung.

VG
Christian

plin · 31 Mai 2021, 20:18:51

Zitat von: plin am 20 Mai 2021, 15:14:02
Noch eine ganz kühne Idee:

Eine Webcam in den Himmel richten,
- aufgrund der Farben (blau, hellgrau, dunkelgrau, ...) und Helligkeit feststellen wie das Wetter ist,
- auf Grund der Wechselgeschwindigkeit der Farben die Windgeschwidigkeit und somit die Qualität der Vorhersage
ermitteln.

Erfahrungsbericht

Ich habe die Daten mehrerer wunderground-Wetterstationen im 5 Minuten-Takt erfasst (am Ort sowie jeweils 30 km im Norden, Westen, Osten, Süden) und die Anzahl der solarRadiation-Änderungen der letzten Stunde ermittelt. Die "Volatilität" ergibt sich aus der kleineren Zahl der Nulldurchgänge (eine Richtung) geteilt durch die größere Zahl der Nulldurchgänge (andere Richtung). Der Mittelwert ist dann als "Volatilität" im Diagramm dargestellt. Erwartung: stabile Wetterlagen führen zu einer niedrigen Volatilität, stark wechselnde Bewölkung zu hohen Werten). Ich hatte diese Lösung heute den ersten Tag laufen, bin aber damit nicht wirklich zufrieden. Ich kann im Diagramm nicht die erhoffte Wechselwirkung zischen Volatilität und stabilem Total AC Active Power erkennen. Die Total AC Active Power war trotz hoher Volatilität brauchbar.

Mittlerweile habe ich aus der Statistic_Yield_Total eine Statistic_Yield_1hour abgeleitet (orangefarbene Linie). Die, in Kombination mit der Total AC Active Power, habe ich heute für die automatische Steuerung des Ladevorgangs genutzt. Meine Zoe lade ich mit 3,4 kW, das Haus braucht 300-400 W. Als Schwellwert habe ich

Statistic_Yield_1hour > 3000
Total_AC_active_power > 4000

verwendet. Das hat ganz gut funktioniert. Es gab wenige Phasen in denen die PV-Leistung so stark absank, dass ich zukaufen musste. Da fehlt jetzt der Aspekt der Vorschau, aber wenn man auf die Wetterlage schaut und das Gefühl hat "heute wird's gut", kann man die Zoe anschließen ([Zoe:plugStatus] eq 1) und warten bis die Schwellwerte überschritte sind, dann startet der Ladevorgang.

ch.eick · 01 Juni 2021, 08:33:54

Moin,
Das hört sich echt spannend an. Bitte achte ein wenig auf die Abfragefrequenz bei wunderground, die sperren schon mal gerne den Zugang oder verändern auch das Angebot. 5 Minuten über viele Stationen in einem Bereich wird da schon zuviel sein.

Ich verwende diese readings aus der Solar_forecast() Funktion und fahre damit recht gut.

Code Auswählen


Solar_Calculation_fc0_*
Solar_Calculation_fc0_4h
Solar_Calculation_fc0_day
Solar_Calculation_fc0_rest

Mein letzter Ansatz, der noch in Bearbeitung ist, ist eine zusätzliche Korrektur wenn SW_Total_DC_P_sumOfAllPVInputs sehr stark schwankt zwischen den Updates. Diese Steilheit ergibt dann wieder zusammengefast auf Stundenbasis einen Korrekturfaktor. An guten Tagen, wo die Kurve nicht schwankt kommen dann auch keine Korrekturen heraus, wodurch man die typischen Frühjahrestage erkennen kann. Im Endergebnis wird dann die Solar_Calculation_fc0 höher ausfallen.

Das schöne ist, dass ich das wieder in SQL über meine eigenen Daten laufen lassen kann.

VG
Christian

plin · 01 Juni 2021, 20:18:25

Meine KI hat sich heute (bei recht stabilen Lichtverhältnissen) wacker geschlagen. So wie es aussieht macht RandomForestRegressor (rote Linie forecast1) wohl das Rennen gegenüber multiple-linear Regression (blaue Linie Forecast).

Einflussgrößen fürs Training waren historische Werte für
columns = ['Rad1h','Neff','R101','Azimuth','Altitude','SunD1','VV','N','DD','RRS1c'] vom DWD
und
Total AC active power)

Einflussgrößen für die Vorhersage (Quelle: Vorhersagedaten des DWD)
columns = ['Rad1h','Neff','R101','Azimuth','Altitude','SunD1','VV','N','DD','RRS1c']

ch.eick · 02 Juni 2021, 08:32:08

Zitat von: plin am 01 Juni 2021, 20:18:25
Meine KI hat sich heute (bei recht stabilen Lichtverhältnissen) wacker geschlagen. So wie es aussieht macht RandomForestRegressor (rote Linie forecast1) wohl das Rennen gegenüber multiple-linear Regression (blaue Linie Forecast).

Das ist doch schon ziemlich nah dran.
Hast Du viel Schatten auf der Anlage, weil die Kurve so komisch aussieht?

plin · 02 Juni 2021, 09:04:32

Zitat von: ch.eick am 02 Juni 2021, 08:32:08
Das ist doch schon ziemlich nah dran.
Hast Du viel Schatten auf der Anlage, weil die Kurve so komisch aussieht?

Ich wohne im Hang, Tal in Richtung Osten. Die PV-Anlage ist in Richtung SW ausgerichtet und Nachmittags schlägt irgendwann der Schatten des Berges zu.