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

Begonnen von ch.eick, 07 Oktober 2020, 16:09:12

Vorheriges Thema - Nächstes Thema

ch.eick

Hallo zusammen,
da es von mir mehrere Threads zu diesem Thema gegeben hat fasse ich nun alles hier zusammen und schließe die anderen.

Dokumentiert wird alles auf der Wiki Seite Kostal_Plenticore_10_Plus

Es geht um folgende Themen:

  • Plenticore 10 Plus
  • KSEM
  • BYD HV
  • Forecast/Leistungsprognose
  • Bilanz
  • Eigenverbrauch Steuerung

Das Wiki umfasst momentan folgende Einträge

Stand 2020.10.07
Inhaltsverzeichnis
1 Voraussetzungen Energietechnik
2 Geräte-Registrierung
3 Hersteller Dokumentation
4 Einbindung in das Netzwerk
5 Voraussetzungen FHEM Umfeld
5.1 Alle Geräte müssen mit TCP/IP erreichbar sein
5.2 Alle Module sollten auf einem aktuellen Stand sein
5.3 Python
5.3.1 Ein Python 3 sollte vorhanden sein
5.3.2 Es müssen folgende Python Module vorhanden sein
5.4 Eine LogDB/LogDBRep sollte bereits vorhanden sein, was hier nicht weiter erklärt wird.
5.5 Verwendete Module
6 Einbindung in FHEM: Überblick
6.1 Hardware Anbindung (alles über LAN)
6.1.1 Kostal Plenticore Plus
6.1.1.1 Kostal Plenticore Plus die Basis information (Modbus/TCP)
6.1.1.1.1 Plenticore Modbus Definition
6.1.1.1.2 Modbus Timing
6.1.1.1.3 RAW Definition des konfigurations Dummy
6.1.1.1.4 RAW Definition des Wechselrichters
6.1.1.1.5 Userreadings
6.1.1.2 Kostal Plenticore Plus die API (über HTTPMOD mit Python Skript Authentifizierung)
6.1.1.2.1 Umstellungsaufwand, falls jemand früher eingestiegen ist.
6.1.1.2.2 Plenticore API
6.1.1.2.3 Dateiverzeichnis
6.1.1.2.4 Python 3
6.1.1.2.5 Passworte
6.1.1.2.6 plenticore_auth_* Erläuterung
6.1.1.2.7 plenticore_auth_finish
6.1.1.2.8 plenticore_auth_session
6.1.1.2.9 Ablaufbeschreibung PV_Anlage_1_API
6.1.1.2.10 Automatischer Login mit Sessionaufbau
6.1.1.2.11 RAW Definition des PV_Anlage_1_API
6.2 Kostal Smart Energy Manager (KSEM) (Modbus/TCP)
6.2.1 RAW Definition des KSEM
6.3 BYD Speicher (mit HTTPMOD)
6.3.1 RAW Definition BYD_Status
7 Timeing für die PV extra Funktionen
7.1 RAW Definition PV_Schedule (DOIF)
8 Energie Bilanz
8.1 RAW Definition Energiebilanz
8.2 Erstellen von zusätzlichen Werten in der Datenbank
8.2.1 RAW Definition LogDBRep_PV_total_diff_Week
8.2.2 RAW Definition LogDBRep_PV_total_max_Month
8.2.3 RAW Definition LogDBRep_PV_used_diff_Week
8.2.4 RAW Definition LogDBRep_PV_used_max_Month
8.3 Timing für die Datenbank Einträge
8.4 Löschen von nicht mehr benötigten Werten in der Datenbank
9 Wetter-/Leistungs-Prognose
9.1 Deutscher Wetter Dienst (DWD)
9.1.1 RAW Definition DWD_Forecast
9.2 99_myUtils.pm Funktionen
9.2.1 Solar_forecast
9.2.2 Solar_Plain
9.2.3 Forecast Basiseinstellung
9.2.4 Berücksichtigung von Temperatur, Bewölkung und Regen
9.2.4.1 Temperatur
9.2.4.2 Wolken und Regen
9.3 wunderground
9.4 RAW Definition Wetter_<Wohnort>
10 Diagramme
10.1 RAW Definition Hauptverbraucher
10.1.1 SVG_LogDB_Photovoltaik_2
10.1.2 GPLOTFILE SVG_LogDB_Photovoltaik_2.gplot
10.2 RAW Definition Leistungsbezug
10.2.1 SVG_LogDB_Photovoltaik_3
10.2.2 GPLOTFILE SVG_LogDB_Photovoltaik_3.gplot
10.3 RAW Definition PV_Bilanz
10.3.1 SVG_LogDB_PV_Bilanz
10.3.2 GPLOTFILE SVG_LogDB_PV_Bilanz.gplot
10.4 RAW Definition Forecast / Calculation
10.4.1 SVG_LogDB_Photovoltaik_4
10.4.2 GPLOTFILE SVG_LogDB_Photovoltaik_4.gplot
11 PV Eigenverbrauch-Steuerung
11.1 Beispiel Luft Wärme Pumpe
11.1.1 RAW Definition LWP_LuftWärmePumpe (dummy Modul)
11.1.2 RAW Definition LWP_PV (DOIF Modul)
11.1.3 RAW Definition rg_LWP_Status (readingsGroup Modul)
11.2 Beispiel Pool
11.2.1 RAW Definition Pool_Softube (dummy Modul)
11.2.2 RAW Definition Pool_PV (DOIF Modul)
11.2.3 RAW Definition Pool_Signale (Shelly Modul: shelly1pm)
11.2.4 RAW Definition Pool_Counter (HourCounter Modul)
11.2.5 RAW Definition rg_Pool_Status (readingsGroup Modul)
11.3 Beispiel Waschmaschine (mit Walzenschalter ;-) )
11.3.1 RAW Definition Waschmaschine (dummy Modul)
11.3.2 RAW Definition Waschmaschine_PV (DOIF Modul)
11.3.3 RAW Definition Waschmaschine_Signale (Shelly Modul: shelly1pm)
11.3.4 RAW Definition Waschmaschine_Counter (HourCounter Modul)
11.3.5 RAW Definition rg_Waschmaschine_Status (readingsGroup Modul)
12 Problemlösung
13 Projekte der FHEM-Community
14 Links


Gruß
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Moin,
ein Newsletter mit Informationen, die bisher verstreut waren:

durch einen Test von einem anderen Mitstreiter hat sich herausgestellt, dass BYD nun die neue Version des Speichers BYD_HVS ausliefert. Dieser neue Speicher hat anscheinend noch kein WebGui und wird nur über eine Handy App Konfiguriert. Leider kann man den somit nicht mit meiner Lösung abfragen.

BYD HV Speicher (nicht HVS!)
Diese Speicher wird über das httpmod Modul angesprochen, ist jedoch noch nicht bis in die letzten Tiefen abfragbar.
Der Begriff "Array" bezeichnet einen Speicher mit mehreren Modulen, die mit dem Series_Battery_Counts angegeben werden. Eine Battery hat dabei ca. 1.28 KW und kann über RunData.asp mit weiteren details abgefragt werden. Momentan ist jedoch noch keine gezielte Abfrage der Module 2-n über "get BYD_Status RunData" möglich.

BYD_Speicher HV mit HTTPMOD

Update: 2020.10.08
Für den bisherigen BYD_HV habe ich eine Aktualisierung im Wiki eingefügt.
Man kann jetzt über ein get den Wert Series_Battery_Counts auslesen und in einem userreading wird dieser mit 1.28 zur Gesamtkapazität berechnet.


InstallationConfig_Array_Counts 1
InstallationConfig_Array_Power 8.96
InstallationConfig_Installation_Time 2020-1-5 13:36:8
InstallationConfig_Series_Battery_Counts 7


Gruß
     Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

EDIT: Die Einspeisung ist nun auch im PV_Anlage_1_API Device integriert und in den userreadings aufgenommen worden.

Hallo zusammen,
es wurde nun bereits mehrfach nach der Darstellung der Einspeisung nachgefragt.
Hier liefert der Kostal Plenticore bereits sehr viele Informationen, bei denen man dann noch die Batterie, falls vorhanden, berücksichtigen muss.
Die Ladung der Batterie ist nicht als Einspeisung zu werten.

Meine Interpretation ist in dem Device Dum.Energie im userreading beinhaltet.
Möchte man nun einen Plot erstellen und die Einspeisung, bzw den Netzbezug darstellen, so kann man dies am einfachsten aus dem Dum.Energie Device machen,
oder muss eventuell die gewünschten userreadings zusätzlich in das PV_Anlage_1 Device übernehmen.

Dum.Energie readings

READINGS:
     AutarkyQuote   
     AutarkyQuoteDay
     AutarkyQuoteMonth
     AutarkyQuoteYear
     GridConsumption <<< Netzbezug
     GridConsumptionDay
     GridConsumptionMonth
     GridConsumptionYear
     GridFeedIn      <<< Einspeisung
     GridFeedInDay   
     GridFeedInMonth
     GridFeedInYear 
     PV             
     PVDay           
     PVMonth         
     PVTotal         
     PVTotalDay     
     PVTotalMonth   
     PVTotalYear     
     PVYear         
     SelfConsumptionQuote
     SelfConsumptionQuoteDay
     SelfConsumptionQuoteMonth
     SelfConsumptionQuoteYear
     TotalConsumption
     TotalConsumptionDay
     TotalConsumptionMonth
     TotalConsumptionYear

Bei diesen Readings handelt es sich um Statistiken, die nicht mit einer hohen Frequenz geschrieben werden. Sie eignen sich somit nicht für eine Berechnung von Verbräuchen, diese sollten besser aus dem PV_Anlage_1 Device bezogen werden, wobei wahrscheinlich die meisten Werte bereits schon vorhanden sein werden.

Eine Abfrage des KSEM ist in Verbindung mit dem Plenticore nicht notwendig und würde die LAN Belastung nur unnötig erhöhen. Wesentliche Werte vom KSEM werden vom Plenticore über RS485 oder LAN gelesen und vom Plenticore über ModBus/TCP bereit gestellt.

PV_Anlage_1

Total_active_power_(powermeter)   <<< Liefert als +/- Wert die Information vom KSEM, hierbei bedeutet - eine Einspeisung und + den Netzbezug
Home_own_consumption_from_grid   <<< zeigt nur den Netzbezug, jedoch nicht die Einspeisung

Um readings mit "(" ins Logging aufzunehmen ist zu beachten, dass "(" und ")" im Regex als Gruppenkennzeichnis verwendet wird und deshalb bei event-on-* maskiert werden muss.

DBLogInclude Total_active_power_\(powermeter\),Act_state_of_charge,Actual_battery_charge_-minus_or_discharge_-plus_Power,Actual_battery_charge_usable_Power,Battery_temperature,Home_own_consumption_from_PV,Home_own_consumption_from_battery,Home_own_consumption_from_grid,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Solar_.*

event-on-change-reading Total_active_power_\(powermeter\),Act_state_of_charge,Actual_battery_charge_.*,Battery_temperature,Home_own_consumption_from_.*,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Solar_.*

# Ergebnis in der DbLog...
| 2020-10-16 13:28:57 | PV_Anlage_1 | Total_active_power_(powermeter)                       | -4.70 |
| 2020-10-16 13:29:52 | PV_Anlage_1 | Total_active_power_(powermeter)                       | -6.20 |


PV_KSEM

M_AC_Power  <==> Total_active_power_(powermeter)


Viele Grüße
     Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

EDIT: Achtung, dieser Update kann entfallen und mit dem nächsten Post kombiniert werde, da das PV_Anlage_1_Bilanz Device in der Zwischenzeit komplett entfallen kann.


Hallo nochmal,

es gab da noch eine Unsauberkeit bei der Namensgebung für die Bilanz.
Das Device Dum.Energy wurde nun umbenannt in PV_Anlage_1_Bilanz. Die Plots ändern sich somit ebenfalls, da sie auf das Device in der Datenbank zugreifen.
Ein Vorteil dieser Änderung ist, dass bei einem SELECT in der Datenbank mit "DEVICE LIKE 'PV_Anlage_1%'" nun alle READING sehr einfach zu erreichen sind.

Alle diejenigen, die bereits vor diesem Datum eingestiegen sind müssen dann jedoch noch die Einträge in der DbLog umschreiben.
Als aller erstes solltet Ihr mal einen aktuellen Backup der Datenbank erstellen, bei einem Fehler durch die falsche Auswähl wäre ansonsten alles weg :-(

Danach geht's dann weiter

# zuerst bitte genau nachschauen, dass Ihr auch die richtigen Einträge erwischt.
SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history WHERE DEVICE='Dum.Energy' AND TIMESTAMP > '2020-01-01 00:00:00' ORDER BY TIMESTAMP LIMIT 500;

# Es ist wichtig, dass Ihr den alten TIMESTAMP beibehaltet!
UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_Bilanz' WHERE DEVICE='Dum.Energy' AND TIMESTAMP > '2020-01-01 00:00:00';


Bei mir war dann ca. 20 Minuten später alles wieder schön :-)

Hier kommt auch mal ein schönes SELECT, für Devices, bei denen einige readings nicht so häufig geschrieben werden ;-)

## Alle aktuellsten readings eines devices im letzten Tagesverlauf
SET @device = 'PV_Anlage_1_Bilanz';
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;


Gruß
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

EDIT 2020.10.21 Diese Bereinigung und Umstellung wäre dann nun erledigt. Ein späterer Schritt könnte dann noch das weitere Aufräumen der readings im PV_Anlage_1_API Device sein.

     Vielen Dank für Euer Gehör
           Christian

EDIT 2020.10.21 Das stateFormat wurde nochmals nachgearbeitet
EDIT 2020.10.21 Es wurde im PV_Schedule Device ein 5 Minuten Update für "get PV_Anlage_1_API 04_/auth/me" eingerichtet, damit das stateFormat die Aktuellen Werte häufiger aktualisiert.
EDIT 2020.10.21 Unten sind nun auch SQL zum Löschen in der Datenbank, aber erst einen Backup machen, wenn Ihr nicht sicher seit!
EDIT 2020.10.21 Im Dum.Energie => PV_Anlage_1_Bilanz tauchen jetzt in der Datenbank nur nor die Momentanwerte auf, die in der Form nicht benötigt werden.
                         Weiter unten in diesem Post habe ich noch eine sql SELECT eingefügt, um diese zu zeigen.
                         Der nächste Schritt ist nun das Löschen vom Dum.Energie bzw PV_Anlage_1_Bilanz und auch das löschen der restlichen DB Einträge.
                         Bitte achtet vorher darauf, dass Ihr alle Werte, die noch gewünscht sind zum PV_Anlage_1_API Device migriert habt.
EDIT 2020.10.21 Für die bereits in der DB erzeugten diff und max Werte habe die SQL Statements für die Migration unten hinzugefügt
EDIT 2020.10.21 Das stateFormat und userreading fon PV_Anlage_1API wurde für die Statistic_ der Bilanz angepasst. Ein Bild hängt an.
                         Momentanwerte werden hier nicht ins Log geschrieben, da sie nur der Übersicht dienen sollen.
EDIT 2020.10.20 Unten findet Ihr jetzt auch die SQL Statements für die Datenbank Änderung der readings.
EDIT 2020.10.20 Das PV_Anlage_1_Bilanz Device ist nun ebenfalls im Wiki aktualisiert. Das userreading holt nun die Werte aus dem _API Device.


Und das Aufräumen geht weiter.

Im Device PV_Anlage_1_Bilanz werden zur Zeit im userreading erweiterte Statistiken berechnet, die zum Device PV_Anlage_1_API gehören, was jedoch historisch bedingt noch nicht existiert hatte. Somit wandern diese readings dann jetzt in das richtige Device.

Betroffen sind zur Zeit folgende readings, die dann auch den Zusatz "Statistic_" bekommen
EDIT: Hierzu gibt es bereits einen aktuelleren Eintrag, damit die Namen besser zu denen vom Plenticore passen!

PVDay
PVMonth
PVYear

GridFeedInDay
GridFeedInMonth
GridFeedInYear

TotalConsumptionDay
TotalConsumptionMonth,
TotalConsumptionYear


Die Berechnungen für die Momentan Werte wird erst einmal bleiben, da diese ja nicht statistisch sind.

Im Device PV_Anlage_1_API sind die oben genannten Werte dann noch in Watt und werden anschließend im PV_Anlage_1_Bilanz Device in Kilowatt dargestellt.

Die Aktualisierung ist bereits im Wiki. Bitte beachtet, dass im Anschluss noch die Änderung im Bilanz Device folgen muss, da ansonsten doppelte werte in der Datenbank sein werden.
Bisherige Werte aus dem Bilanz Device können dann natürlich in der Datenbank später dem neuen Device zugeordnet werden und gehen somit nicht verloren. Die Vorgehensweise dürfte bereits bekannt sein.

Ich habe es natürlich jetzt schon gemacht, aber bitte prüft die SQL Statements vorher und macht auch vorher einen Backup.
EDIT: Achtung, an dieser Stelle kann man auch direkt zu den endgültigen Namen vom 2020.10.22 umziehen.

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_TotalConsumptionDay', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='TotalConsumptionDay' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_TotalConsumptionMonth', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='TotalConsumptionMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_TotalConsumptionYear', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='TotalConsumptionYear' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_PVDay', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='PVDay' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_PVMonth', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='PVMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_PVYear', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='PVYear' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_GridFeedInDay', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='GridFeedInDay' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_GridFeedInMonth', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='GridFeedInMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_GridFeedInYear', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='GridFeedInYear' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='max_month_Statistic_PVMonth'
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='max_month_PVMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='max_month_Statistic_PVTotalMonth'
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='max_month_PVTotalMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='diff_week_Statistic_PVMonth'
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='diff_week_PVMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='diff_week_Statistic_PVTotalMonth'
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='diff_week_PVTotalMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

###################### Achtung, das ist zum Löschen, also Backup machen oder sich sicher sein :-) ###################

delete FROM history WHERE DEVICE='PV_Anlage_1_Bilanz' AND TIMESTAMP > '2020-01-01 00:00:00';


Die Reste vom Dum.Energie bzw PV_Anlage_1_Bilanz Device in der Datenbank

SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history WHERE DEVICE='PV_Anlage_1_Bilanz' AND TIMESTAMP > '2020-01-01 00:00:00' order BY TIMESTAMP limit 500;

snip ...
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | AutarkyQuote         | 90    |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | GridConsumption      | 20    |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | GridFeedIn           | 0     |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | PV                   | 641   |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | PVTotal              | 734   |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | SelfConsumptionQuote | 87    |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | TotalConsumption     | 714   |
snip ...


Der Trigger von diesem Device ist im PV_Schedule enthalten und kann dann auch raus.


Gruß
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Es ist nun wiederkehrend die Frage aufgetaucht, warum das Aufsummieren von einzel readings aus der Datenbank, z.B. für den Tagesertrag stark vom Zählerstand für die Einspeisung abweicht.
Ich versuche dies dann mal zu erklären :-)

Die Devices arbeiten mit event-on-change reading, wobei somit im Nachgang in der Datenbank zum Teil unregelmäßige Einträge entstehen und diese dann auch noch vom Abstand zwischen den Triggerzeiten abhängig sind.

Vom reading "Total_active_power_(powermeter)" wäre der negative Teil die Einspeisung ins Netz.
Dargestellt, aber nicht gelogged, wird dies im Device PV_Anlage_1 im stateFormat . Hier erscheit also entweder 0 oder ein Wert in Watt.

(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0)<=0 ? abs(round(ReadingsVal("PV_Anlage_1","Total_active_power_(powermeter)",0),0)):  0)." W";


Würde man nun versuchen die negativen Werte des reading "Total_active_power_(powermeter)" in der Datenbank zu summieren, so stellt man fest, dass die Summe nicht dem Zählerstand des EVU entspricht.

Gründe dafür sind:
- Der Abfrage Zyklus mit 60 Sekunden ist für eine Messung recht grob, das macht der KSEM mindestens im Sekunden Bereich.
- Durch die grobe Abfrage fallen dann auch noch Werte heraus, die dazwischen beginnen und enden. Dies wäre z.B. das 40 Sekunden Händewaschen mit einem 21 KW Durchlauferhitzer ;-)
- Wird direkt hintereinander Abgefragt und der Wert hat sich nicht geändert, kommt auch kein neuer Eintrag in die Datenbank.
- Dies führt dazu, dass man bei der Abfrage der Datenbank auch das Delta des TIMESTAMP berücksichtigen muss, was zusätzlich ungenau wird.

Abhilfe schafft hier jedoch der Plenticore mit seinen Statistiken, die die Tages-, Monats- und Jahressummen liefern. Diese werden nun bereits durch das PV_Anlage_1_API Device stündlich abgefragt und bei Änderung ins Log geschrieben. Am ende des Tages kann man dann die zwischen Werte Löschen und nur den letzten Tageswert behalten, bzw den letzten Monats- oder Jahreswert.

Dies wird dann in einem nächsten Schritt hier noch ergänzt werden.

Desweiteren vermute ich, dass sich jeder über kurz oder lang einen Lesekopf auf den EVU Zähler installieren wird, wodurch sich dann die Zwischenschritte ablesen lassen.

Wer den KSEM zusätzlich ausliest bekommt hier die entsprechenden Register ebenfalls angezeigt, die dann jedoch noch mit einem Offset mit dem EVU Zähler synchronisiert werden sollte.
Achtung, wenn der KSEM zurück gesetzt wird, beginnt er wieder bei Null ;-)

obj-h512-reading Active_energy+ 2125.7094
obj-h516-reading Active_energy- 3709.5486
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Und noch eine Nachricht.

Da ja nicht alle elektrische Großverbraucher haben und ich den Sommer über auch kleinere Geräte angeschlossen habe gibt es nun weitere Beispiele im Wiki.

- Accu laden, z.B. Rasenroboter und E-Bike
- Brunnenpumpe mit extra Taster am Shelly2.5 und Endabschaltung bei Nichtbenutzung

Bei diesen Beispielen teilen sich die Geräte einen Shelly2.5 , was die Kosten auf gerade mal 25€ zusammen senkt.
Natürlich ohne Steckdosen und Taster :-)
Weiterhin ist die Lösung auch noch über das WLan zu verbinden.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Hallo zusammen,
auf vielfachen Wunsch meiner Ideen ;-) und einem weiteren Mitstreiter gibt es eine Bereinigung im PV_Anlage_1_API Device.
Nun sollten aber so ziemlich alle Wünsche erfüllt sein und viele Berechnungen in DOIFs erledigt sein.


- attr PV_Anlage_1_API DbLogInclude Statistic_Autarky.*,Statistic_Energy.*,Statistic_Own.*,Statistic_Total.*,Statistic_Yield.*,Statistic_PV.*,Statistic_Grid.*
- stateFormat aus dem Wiki
- userreading aus dem Wiki

Es wurden readings umbenannt, damit die userreadings besser zu den Plenticore readings passen
Die Einspeisung ins Netz:
  Statistic_EnergyFeedInGrid_Day
  Statistic_EnergyFeedInGrid_Month
  Statistic_EnergyFeedInGrid_Year
Der Hausverbrauch als Summe vom direkten PV und der Batterie
  Statistic_EnergyHomePvSum_Day
  Statistic_EnergyHomePvSum_Month
  Statistic_EnergyHomePvSum_Year

Weiterhin gibt es nun den ertrag ohne die Batterie, weil Statistic_Yield_Day laut Kostal die Batterie enthält.
  Statistic_Yield_NoBat_Day
  Statistic_Yield_NoBat_Month
  Statistic_Yield_NoBat_Year

## einmal kann man alle Statistic_ readings löschen und wieder neu einlesen
deletereading PV_Anlage_1_API Statistic_*
get PV_Anlage_1_API 20_/processdata/scb_statistic_EnergyFlow


wie immer müssen jetzt natürlich bereits vorhandene Logeinträge zu den neuen reading Namen umgezogen werden. Bitte schaut dazu zu den bisherigen Posts und modifiziert die SQLs nach den jeweiligen Anforderungen.

EDIT: Okay, hier ein kleiner Überblick

SET @device = 'PV_Anlage_1_API';
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            |
+---------------------+-----------------+------------------------------------+------------------+
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_Autarky_Day              | 78.1824126685    |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_Autarky_Month            | 69.5112729702    |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_Autarky_Total            | 68.3550253426    |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_Autarky_Year             | 78.8398715615    |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyFeedInGrid_Day     | 5.77             |                  <<<<< neu
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyFeedInGrid_Month   | 29075.31         |                  <<<<< neu
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyFeedInGrid_Year    | 5189920.93       |                  <<<<< neu
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomeBat_Day        | 2150.2203689484  |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomeBat_Month      | 106338.785185352 |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomeBat_Total      | 1456290.5320946  |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomeBat_Year       | 1310352.66285165 |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomeGrid_Day       | 786.2094131098   |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomeGrid_Month     | 122445.10343664  |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomeGrid_Total     | 2197546.68945482 |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomeGrid_Year      | 1154187.37131264 |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Day      | 2818.75          |                  <<<<< neu
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Month    | 279224.58        |                  <<<<< neu
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Year     | 4292633.31       |                  <<<<< neu
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomePv_Day         | 668.5259759135   |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomePv_Month       | 172885.790277168 |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomePv_Total       | 3259074.38706554 |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHomePv_Year        | 2982280.64988293 |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHome_Day           | 3605.3363498516  |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHome_Month         | 401702.148528503 |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHome_Total         | 6898363.7820191  |
| 2020-10-23 11:44:35 | PV_Anlage_1_API | Statistic_EnergyHome_Year          | 5444758.72015098 |
| 2020-10-23 10:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay            | 5.71             |                  <<<<< muss umziehen
| 2020-10-23 10:57:00 | PV_Anlage_1_API | Statistic_GridFeedInMonth          | 29075.25         |                  <<<<< muss umziehen
| 2020-10-23 10:57:00 | PV_Anlage_1_API | Statistic_GridFeedInYear           | 5189920.87       |                  <<<<< muss umziehen
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_OwnConsumptionRate_Day   | 99.7837913186    |
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_OwnConsumptionRate_Month | 90.5648443358    |
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_OwnConsumptionRate_Total | 47.4788047504    |
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_OwnConsumptionRate_Year  | 45.2677830054    |
| 2020-10-23 10:57:00 | PV_Anlage_1_API | Statistic_PVDay                    | 2601.82          |                  <<<<< muss umziehen
| 2020-10-23 10:57:00 | PV_Anlage_1_API | Statistic_PVMonth                  | 279007.65        |                  <<<<< muss umziehen
| 2020-10-23 10:57:00 | PV_Anlage_1_API | Statistic_PVYear                   | 4292416.38       |                  <<<<< muss umziehen
| 2020-10-23 10:57:00 | PV_Anlage_1_API | Statistic_TotalConsumptionDay      | 3353.05          |                  <<<<< muss umziehen
| 2020-10-23 10:57:00 | PV_Anlage_1_API | Statistic_TotalConsumptionMonth    | 401417.77        |                  <<<<< muss umziehen
| 2020-10-23 10:57:00 | PV_Anlage_1_API | Statistic_TotalConsumptionYear     | 5446568.78       |                  <<<<< muss umziehen
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_TotalConsumption_Day     | 3410.02          |                  <<<<< neu
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_TotalConsumption_Month   | 401474.74        |                  <<<<< neu
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_TotalConsumption_Year    | 5446625.75       |                  <<<<< neu
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_Yield_Day                | 2644.0674482191  |
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_Yield_Month              | 308119.43733729  |
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_Yield_NoBat_Day          | 496.92           |                  <<<<< neu
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_Yield_NoBat_Month        | 201783.72        |                  <<<<< neu
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_Yield_NoBat_Year         | 8172024.20       |                  <<<<< neu
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_Yield_Total              | 9931163.91202423 |
| 2020-10-23 11:09:05 | PV_Anlage_1_API | Statistic_Yield_Year               | 9482373.79571359 |
+---------------------+-----------------+------------------------------------+------------------+

## Nun zum Umziehen, hier folgen noch SQLs, da ich es gerade live mache 2020.10.23 12:00 Uhr gestartet
UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Statistic_EnergyHomePvSum_Day' WHERE DEVICE='PV_Anlage_1_API' and READING='Statistic_PVDay' AND TIMESTAMP > '2020-01-01 00:00:00';
UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Statistic_EnergyHomePvSum_Month' WHERE DEVICE='PV_Anlage_1_API' and READING='Statistic_PVMonth' AND TIMESTAMP > '2020-01-01 00:00:00';
UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Statistic_EnergyHomePvSum_Year' WHERE DEVICE='PV_Anlage_1_API' and READING='Statistic_PVYear' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Statistic_TotalConsumption_Day' WHERE DEVICE='PV_Anlage_1_API' and READING='Statistic_TotalConsumptionDay' AND TIMESTAMP > '2020-01-01 00:00:00';
UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Statistic_TotalConsumption_Month' WHERE DEVICE='PV_Anlage_1_API' and READING='Statistic_TotalConsumptionMonth' AND TIMESTAMP > '2020-01-01 00:00:00';
UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Statistic_TotalConsumption_Year' WHERE DEVICE='PV_Anlage_1_API' and READING='Statistic_TotalConsumptionYear' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Statistic_EnergyFeedInGrid_Day' WHERE DEVICE='PV_Anlage_1_API' and READING='Statistic_GridFeedInDay' AND TIMESTAMP > '2020-01-01 00:00:00';
UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Statistic_EnergyFeedInGrid_Month' WHERE DEVICE='PV_Anlage_1_API' and READING='Statistic_GridFeedInMonth' AND TIMESTAMP > '2020-01-01 00:00:00';
UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Statistic_EnergyFeedInGrid_Year' WHERE DEVICE='PV_Anlage_1_API' and READING='Statistic_GridFeedInYear' AND TIMESTAMP > '2020-01-01 00:00:00';

## Bis hierhin hat es nun ca. 45 Minuten gebraucht.

Nun fehlen noch die Werte, die durch die Datenbank monatlich und wöchentlich erstellt werden, denn dort ändert sich durch die Namensänderung auch etwas.



Viele Grüße
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Hallo zusammen,
ich hoffe es geht Euch nicht zu schnell.

Durch das Aufräumen der Datenbank und die Umbenennungen der readings  habe ich nun auch im Wiki den Bereich Erstellen von zusätzlichen Werten in der Datenbank mit den Plots für die Bilanz überarbeitet.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Moin,

wem es noch nicht aufgefallen ist:
Man kann nun beim PV_Schedule die einzelnen DOIF direkt über den Status (mit Label) anklicken (direkt auf cmd_* klicken). Dann wird dieser Zweig sofort ausgeführt und berechnet z.B. dien Forecast_0  mit
den aktuellen DWD Daten neu.

Das Ergebnis im Diagramm wird natürlich durch den Datenbank Cache und den asynchronen Betrieb der Datenbank dann verzögert dargestellt.
Den Refresh Button vom Browser nicht vergessen, damit das SVG aktualisiert wird.

BYD_Status cmd_1           Das haben natürlich nur die, die den alten HVS Speicher haben und diesen bereits auslesen.
Statistic_Update cmd_2    holt auch zwischendurch die Statistiken ab und schreibt diese in die Datenbank
Forecast_0 cmd_3             Forecast heute
Forecast_1 cmd_4             Forecast Morgen
Bilanz_Actual cmd_5         aktualisiert im stateFormat vom PV_Anlage_1_API die aktuellen Werte
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Und hier mal zwei aktuelle Bilder, wie es entstehen würde, wenn man dem Wiki folgt:
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Guten Morgen zusammen,
da nun einige Photovoltaik Enthusiasten bis zur Leistungsprognose vorgedrungen sind gibt es hier mal wieder eine weitere Information.

Die Leistungsprognose wird von der Funktion Solar_forecast() in der 99_myUtils.pm errechnet. Diese Funktion bekommt unter anderem beim Aufruf den Zeitraum [0|1]  und das Log Device übergeben. Der Aufruf erfolgt für den aktuellen Tag, aus dem PV_Schedule Device, zwischen 07:00 und 19:00 Uhr und für den Folgetag mit zwei Aktualisierungen um kurz vor 07:00 und um kurz nach 19:00 Uhr.
Diese Zeiträume richten sich nach den Aktualisierungen der Prognosedaten des DWD.

################################################################################################################
## 3 PV Prognose vom aktuellen Tag aktualisieren
##     zwischen 7 und 19 Uhr zur vollen Stunde
DOELSEIF
([07:00-20:00] and [:00])
   (
    {Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)}
   )
################################################################################################################
## 4 PV Prognose für den nächsten Tag aktualisieren
##
DOELSEIF
([06:55] or [19:11])
   (
    {Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",1)}
   )


Hierduch werden dann nun die Prognesewerte auf Stundenbasis in die Datenbank geschrieben, von wo sie in den Plots dargestellt werden.

Möchte man nun eine dieser Prognosen für eine Entscheidung verwenden muss man den Wert aus der Datenbank und nicht aus dem PV_Anlage_1 Device lesen. Ein Beispiel wurde bereits im Device Pool_PV angewendet, um im Herbst/Winter die Startzeit für den Pool nach vorne zu verlegen, damit der höhere Temperaturverlust durch die längere Laufzeit ausgeglichen werden kann.

Die entsprechenden Zeilen sehen wie folgt aus:
- Zeitpunkt für die Entscheidung ist 07:17, also kurz nach der letzten Prognoseaktualisierung
- in $timestamp wird die Prognosezeit auf 12:00:00 Uhr gesetzt (es gibt nur volle Stundenwerte !)
- DbReadingsVal() holt den Wert aus der Datenbank
- mit der nun folgenden if Anweisung wird dann durch das setzen eines readings zwischen zwei Werten gewechselt.

################################################################################################################
## 13 Pool Startzeit durch Forecast verschieben. Der Forecast wird um 7:00 im Device PV_Schedule aktualisiert
##
DOELSEIF
([07:17])
    (
     {my $timestamp = POSIX::strftime("%Y-%m-%d 12:00:00",localtime(time));
      my $VALUE     = DbReadingsVal("LogDBRep_select_PV_Forecast","PV_Anlage_1:Solar_Calculation_fc0",$timestamp,0);
      if ( $VALUE < 4000 )
         {fhem("setreading Pool TimeStart ".ReadingsVal("Pool","TimeStartWinter",0) )}
      else
         {fhem("setreading Pool TimeStart ".ReadingsVal("Pool","TimeStartSummer",0) )}
     },
     {Log 3, "Pool_PV cmd_13 : Pool TimeStart switched"}
    )


Um $timestamp richtig zu setzen wäre diese Wiki Seite zu verwenden Zeitangaben, rechnen mit

## Die aktuelle Stunde von morgen. Achtung 08:59 Uhr liefert 08:00 Uhr am nächsten Tag und nicht 09:00 Uhr
my $timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime(time +1*24*60*60))

## ein fester Werte zum Testen
my $timestring = "2020-10-26 12:00:00"

## Heute 13 Uhr
my $timestring = POSIX::strftime("%Y-%m-%d 13:00:00",localtime(time)) }

## $timestring ist die Basis, auf die man dann noch z.B. 24 h addiert
my $timestamp = POSIX::strftime("%Y-%m-%d %H:00:00",localtime(time_str2num($timestring) +1*24*60*60))
/code]

Man könnte z.B. auch den Vormittag mit dem Nachmittag vergleichen
[code]
my $VALUE_morgens      = DbReadingsVal("LogDBRep_select_PV_Forecast","PV_Anlage_1:Solar_Calculation_fc0",POSIX::strftime("%Y-%m-%d 09:00:00",localtime(time),0);
my $VALUE_nachmittags  = DbReadingsVal("LogDBRep_select_PV_Forecast","PV_Anlage_1:Solar_Calculation_fc0",POSIX::strftime("%Y-%m-%d 14:00:00",localtime(time),0);
if ( $VALUE_morgens <  $VALUE_nachmittags)
...


Viele Grüße
     Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Hallo zusammen,
ich denke nun wird jeder die letzen Umstellungen gemacht haben. Ich werde dann nun das Wiki bei Zeiten aufräumen. Ansonsten wäre nun der Zeitpunkt für eine Rückmeldung.
Übrigens ist es hier so still, weil momentan der Service per Mail gelaufen ist ;-)
Gruß
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

killah78

Hallo ch.eick
sehr geile Sache, die du hier aufgebaut hast.
Bin sehr beeindruckt aber auch sehr erschlagen von der Informationsdichte.
Ich würde das gerne umsetzen, was du hier beschreibst, aber ich bin da gerade etwas überfordert.
Als Besonderheit bei mir ist, dass ich zwei Wechelrichter habe, einen Plenticore mit Batterie und einen IQ (quasi baugleich, aber ohne Batterie).
Derzeit lese ich Werte über Modbus aus und rechne mir was zusammen. Leider klappt das nicht komplett und ich komme nicht auf die Werte, die ich im Portal sehe.

ZB. ist es so, dass der Plenticore auch über die AC Seite lädt (das was halt der IQ erzeugt). Hier erhalte ich dann falsche Ertragswerte. Denn der Plenticore zählt keine "Yield"-Werte, wenn die Batterie geladen wird, der IQ zählt aber immer "Yield", da es für ihn immer eine Einspeisung ist. Somit zählt der Plenticore dann beim Batterieentladen "Yield", die der IQ aber bereits gezählt hat. Also ist bei mir die "Yield"-Summe zu hoch. Ich habe somit keine korrekten Ertragswerte. Im Portal werden die Etragswerte gezählt, die wirklich vom Dach kommen. Also auch was in die Batterie geht. Da passt das, es muss also dann doch irgendwie errechenbar sein. Ob Ertrag jetzt gezählt wird, beim Laden oder Entladen der Batterie sei mal dahingestellt.

Ich denke, das in der Api Informationen vorhanden sein müssen, die ich im Modbus nicht bekomme.

Um deine Definitonen umzusetzen, habe ich aus dem Wiki das config-device und PV_Anlage_1 angelegt.
Wo finde ich denn die Python Scripte? also das auth_finish und auth_session?
Ich müsste die Devices ja danach dumplizieren. Also für beide Wechelrichter. Und dann irgendwie aufsummieren.
Aber erstmal gucken, welche Daten ich aus dem Api bekomme.
Kannst du mir mit dem Finden der Script-Dateien helfen?

Danke und Gruss
killah78

Edit: ok, habe die Blindenbrille abgenommen und die Dateien im Wiki gefunden :-)

Nochmal Edit: Habe das API Device jetzt eingerichtet. Aber komme nicht weiter. Muss ich "%IP-Address_Plenticore%" mit der IP-Adresse ersetzen oder wird da automatisch irgendwo ersetzt? Wenn ich jetzt die Statistik abrufen möchte, muss ich manuell zuerst get 01... und get 02... ausführen? Im moment bekomme ich immer die Meldung "authentication failed". Das password ist wirklich der Masterkey vom Gehäuse?

ch.eick

Hallo killah78

Zitat von: killah78 am 28 Oktober 2020, 13:37:48
Als Besonderheit bei mir ist, dass ich zwei Wechelrichter habe, einen Plenticore mit Batterie und einen IQ (quasi baugleich, aber ohne Batterie).
Derzeit lese ich Werte über Modbus aus und rechne mir was zusammen. Leider klappt das nicht komplett und ich komme nicht auf die Werte, die ich im Portal sehe.
Okay, das wird interessant :-)
Ich musste mich auch etwas disziplinieren. Als erstes habe ich alle Daten von den Devices gesammelt und aufbereitet.
Danach kann man auf validen Daten aufbauen und die Werte in Relation setzen.
Also eins nach dem anderen.

Zitat
Ich denke, das in der Api Informationen vorhanden sein müssen, die ich im Modbus nicht bekomme.
Die Statistiken bekommst Du nur über die PV_Anlage_1_API

Zitat
Nochmal Edit: Habe das API Device jetzt eingerichtet. Aber komme nicht weiter. Muss ich "%IP-Address_Plenticore%" mit der IP-Adresse ersetzen oder wird da automatisch irgendwo ersetzt? Wenn ich jetzt die Statistik abrufen möchte, muss ich manuell zuerst get 01... und get 02... ausführen? Im moment bekomme ich immer die Meldung "authentication failed". Das password ist wirklich der Masterkey vom Gehäuse?

Bei Dir werden das dann 2 PV_Anlage_*_API devices werden. Deshalb hatte ich versucht generische Namen zu wählen.
Und Du brauchst auch noch die zwei Modbus Devices PV_Anlage_*

Dann solltest Du auch zwei mal PV_Anlage_*-config anlegen, wo Du für jeden WR die Umgebung Konfigurieren kannst.
Dort stehen dann auch die IP-Addressen für die beiden WR drin.

Das Passwort ist wirklich auf dem Gehäuse, wenn der Installateur Dir nicht ein anderes gesetzt hat.

Der Sessionaufbau ist hier beschrieben, damit  man den Ablauf versteht. https://wiki.fhem.de/wiki/Kostal_Plenticore_10_Plus#Automatischer_Login_mit_Sessionaufbau
Wenn mal alles klappt, dann frgt man meistens nur "20_/processdata/scb_statistic_EnergyFlow" ab und die Session sollte sich bei bedarf selber aufbauen.

Puh, ich hoffe ich habe jetzt alle Fragen im Post gefunden...

Gruß
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick