Nachtverbrauch berechnen für neue Solaranlage

[pejonp]

Hallo,

ich habe einen SolarEdge SE5K Wechselrichter und 19 Soalrmodule 327Wp. Die Anlage liefert 6,25kWp. Im Frühjahr und Sommer ist es für den 5KW  SolarEdge WR machmal Grenzwertig. Läuft aber.
Die Module sind nach Osten / Süden und Westen ausgerichte und haben verschiedene Anstellwinkel und regeln sich mit den SolarEdge-Optimieren. Ich kann dadurch von jedem SolarModul die Leistung auslesen.

Notabschaltung Solarmodule: 1V pro Modul, max. Spannung 19V (Anzahl Module)

Ich hatte zu Anfang (2014) eine 8kWh Sonnenbatterie 1. Generation die nur zu 70% entladen werden konnte.

Und jetzt eine ECO 8.0 (LiFePO4) 10kWh 90% Entladung möglich. Diese kann aber noch mit ein oder zwei Batteriepacks (2,5kWh) erweitert werden. Eingebauter WR 3,3KW.
Im Frühjahr/Sommer reicht die BAT über Nacht bis zum ersten Laden am Morgen. BAT hat dann noch so 10%. Wenn inder Nacht nicht gekocht und gewaschen wird.

Mehrfamilien Haus 5,3 MWh. Eltern sind zu Hause und es wird jeden Tag gekocht und fast jeden zweiten Tag gebacken.

erzeugte Solarenergie
2015 4,51MWh nach Umbau 2018 dann
...
2018 4,81MWh.
2019 5,23MWh.
2020 5,24MWh.

2018 habe ich die Standort der Module umgebaut und 2 zusätzliche Module installiert. 4 Module nach Osten ausgerichtet. Damit war der SolarEdge SE5K WR dann ausgereizt.

Thema Durchlauferhitzer (Gästebad, geringe Nutzung) : 18KW wenn der angeht reicht Solar und BAT nicht aus, es wird aus dem Netz gezogen. Boiler (5L Garten) ist da schon besser.

Warmwasser im Sommer aus Solarthermieanlage (1000l Solarspeicher)(2004). Wenn die Sonne scheint ist ausreichend Warmwasser da, es sind 5 Module verbaut.

Vielleicht hilft das etwas.

pejonp

[KölnSolar]

soweit ich weiß ist die Rückspeißung aus E-Auto in Deutschland nicht erlaubt.

Ich glaube es ist erlaubt, aber scheinbar zu kompliziert umzusetzen. Ich weiß, dass Solarwatt sich mit ? (war es BMW ?) versucht hatte. Das Projekt ist aber wohl gestorben. Leider. Denn das ist auch ein Bsp., was ich mit

Und der allergrößte Schwachsinn aus technischer Sicht ist für mich, Solarstrom von der einen(Solar) in die andere Batterie(E-Auto) zu schaufeln. Es gäbe da, je nach individuellem Fall, zig Ansätze das zu vermeiden.

meinte.

Thema Durchlauferhitzer (Gästebad, geringe Nutzung) : 18KW wenn der angeht reicht Solar und BAT nicht aus, es wird aus dem Netz gezogen. Boiler (5L Garten) ist da schon besser.

Ja, da war doch noch was, was an meiner Konzeption ohne Speicher nicht zu Ende gedacht war  und weshalb ich in meinen Vorüberlegungen einen kleinen Speicher(30-50l) trotz seiner Nachteile in Erwägung zog. Womit man wieder beim Sinn von

, was ich generell für sinnvoll erachten würde, wenn nicht strikt zwischen Einspeisung und Bezug abgegrenzt würde, sondern eine kaufmännische Bilanzierung durchgeführt würde.

wäre. 

Das ist aber "nur" die wirtschaftliche Betrachtung bei PV. Ökologisch ist der Durchlauferhitzer(geringe Belastung der Umwelt in der Herstellung) die bessere Lösung. Mein Gaskessel verbrät ca. 3-4 kWh Gas für 30 l warmes(30K Differenz) Wasser u. produziert entsprechendes CO2. Der Durchlauferhitzer macht das mit 1 kWh, die bei Ökostrom auch noch zu 100% klimaneutral ist. Fazit: Schlecht fürs Portemonnaie u. (unsinnigem) Autarkiegrad, aber gut für die Umwelt.

[MadMax]

Hallo,

Ich habe eine WP mit 500l Pufferspeicher den die eh braucht.
Der Speicher ist ein Hybrider, warmwasser wird dort im Durchlaufverfahren erwärmt.
Der wird auch nur zur Hälfte geladen und auch nur auf 48°C und keine 60° die Frischwassermenge im Puffer liegt unter 20l darum keine Legionellengefahr. Im Sommer lade ich den überschuss der Abgerigelt werden würde über einen Heizstab in den Puffer, da muss die WP im Sommer fast nicht mehr laufen.

Der Durchlauferhitzer brauch 18kW? Da muss man ja auch im Sommer Strom zukaufen? Die Anschaffung ist natürlich günstiger.

Gruß
Max

[Nogga]

Ich hab den Thread nur überflogen, aber würde der Vollständigkeit-halber mal ein paar SQL-Queries in den Raum werfen um bestimmte Auswertungen zu fahren (Achtung - die können bei entsprechender Datenlage durchaus ein paar Minuten laufen).

Ich habe im Einsatz:
- DBlog
- RCT Wechselrichter (11.7 kWp) mit Batterie (5.7 kWh)
- OBIS-Leser für den Stromzähler

Minimal- und Maximal-Ladung der Batterie pro Tag:

Code: [Auswählen]

CREATE ALGORITHM=UNDEFINED DEFINER=`fhem`@`%` SQL SECURITY DEFINER VIEW `daily_battery_levels`
AS SELECT
   year(`history`.`TIMESTAMP`) AS `year(timestamp)`,month(`history`.`TIMESTAMP`) AS `month(timestamp)`,dayofmonth(`history`.`TIMESTAMP`) AS `day(timestamp)`,
   `history`.`READING` AS `reading`,min(`history`.`VALUE`) AS `Min`,max(`history`.`VALUE`) AS `Max`
FROM `history` where `history`.`READING` = 'battery_soc' group by year(`history`.`TIMESTAMP`),month(`history`.`TIMESTAMP`),dayofmonth(`history`.`TIMESTAMP`),`history`.`READING` order by `history`.`TIMESTAMP`;

Maximal-Leistung der zwei WR-Eingänge und Gesamt

Code: [Auswählen]

CREATE ALGORITHM=UNDEFINED DEFINER=`fhem`@`%` SQL SECURITY DEFINER VIEW `solar_peaks_per_day`
AS SELECT
   year(`history`.`TIMESTAMP`) AS `YEAR(timestamp)`,month(`history`.`TIMESTAMP`) AS `MONTH(timestamp)`,dayofmonth(`history`.`TIMESTAMP`) AS `DAY(timestamp)`,
   `history`.`READING` AS `reading`,max(`history`.`VALUE`) AS `MAX(value)`
FROM `history` where `history`.`DEVICE` = 'RCT_Wechselrichter' and `history`.`VALUE` > 1000 and (`history`.`READING` = 'power_solarCombined' or `history`.`READING` = 'power_solarA' or `history`.`READING` = 'power_solarB') group by `history`.`READING`,year(`history`.`TIMESTAMP`),month(`history`.`TIMESTAMP`),dayofmonth(`history`.`TIMESTAMP`) order by `history`.`TIMESTAMP`,`history`.`READING`;

Tagesverbrauch am Stromzähler (Differenz zwischen 00:00 und 23:59 pro Tag am Stromzähler)
Man könnte den Zeitraum auch noch beschränken um die "Nacht"-Werte zu bekommen. Bestimmt noch mit Astro-Funktionen noch genauer... Und natürlich dann Mittelwert.
Achtung: das ist noch nicht auf Einspeisung umgestellt!

Code: [Auswählen]

CREATE ALGORITHM=UNDEFINED DEFINER=`fhem`@`%` SQL SECURITY DEFINER VIEW `net_consumption_per_day`
AS SELECT
   year(`history`.`TIMESTAMP`) AS `YEAR(timestamp)`,month(`history`.`TIMESTAMP`) AS `MONTH(timestamp)`,dayofmonth(`history`.`TIMESTAMP`) AS `DAY(timestamp)`,round((max(`history`.`VALUE`) - min(`history`.`VALUE`)) / 1000,3) AS `day_consumption_kWh`
FROM `history` where `history`.`DEVICE` = 'UG_Stromzaehler' and `history`.`READING` = 'total_consumption' group by year(`history`.`TIMESTAMP`),month(`history`.`TIMESTAMP`),dayofmonth(`history`.`TIMESTAMP`) order by `history`.`TIMESTAMP`;

Man kann die Queries bestimmt noch leicht umbauen in Richtung Grundlast, usw.

Ich habe die Batterie seit Ende August. Ich hatte bisher einen Jahresverbrauch von ca. 5000 kWh (Pellets-Heizung, Wasser über Heizung).
Wenn Ihr meine Meinung hören wollt zur Batterie-Größe: für meine Anlage will ich keine größere Batterie. Im Hochsommer kann ich gut damit die Nacht überbrücken (Sonnenuntergang ca. 21:00 bis Aufgang 6:00). In den Übergangszeiten reicht es nicht ganz, aber die Batterie wird aber zumindest noch voll.

Beim jetzigen November-Wetter bekomme ich die Batterie noch nicht mal 30-40% voll...
Und Betriebswirtschaftlich sagt, man, dass man mindestens 200 komplette Zyklen (Voll zu Leer und zurück) hinbekommen soll... Das wird mit einer größeren Batterie sehr schwierig (Sommer wird sie nicht leer und Winter niemals voll...).

Und noch ein wichtiger Hinweis: Die Batterie ist nicht unbedingt dazu da lange Phasen zu überbrücken (Nacht), sondern vielmehr kürzere Phasen-Spitzen (z.B. Mittags der Herd bei schlechtem Wetter, usw.) - für solche Phasen von 30-60 Min zieht er sich dann ein paar Prozente aus der Batterie... Die Wahrscheinlichkeit grundsätzlich Nächte zu überbrücken lohnt sich dann deutlich betriebswirtschaftlich nicht...

[ch.eick]

Hallo Nogga,
vielen dank für die SQL Statements, jetz habe ich auch Muster für Views :-)
ich habe die SELECTs mal bei mir laufen lassen.

Minimal- und Maximal-Ladung der Batterie pro Tag:

Code: [Auswählen]

CREATE ALGORITHM=UNDEFINED DEFINER=`fhem`@`%` SQL SECURITY DEFINER VIEW `daily_battery_levels`
AS SELECT
   year(`history`.`TIMESTAMP`) AS `year(timestamp)`,month(`history`.`TIMESTAMP`) AS `month(timestamp)`,dayofmonth(`history`.`TIMESTAMP`) AS `day(timestamp)`,
   `history`.`READING` AS `reading`,min(`history`.`VALUE`) AS `Min`,max(`history`.`VALUE`) AS `Max`
FROM `history` where `history`.`READING` = 'battery_soc' group by year(`history`.`TIMESTAMP`),month(`history`.`TIMESTAMP`),dayofmonth(`history`.`TIMESTAMP`),`history`.`READING` order by `history`.`TIMESTAMP`;


Code: [Auswählen]

|            2019 |               12 |             14 | Act_state_of_charge | 10.00  | 9.00  |
Min und Max passt nicht immer, da Min im besten Fall nur gleich Max sein kann und nicht größer.

Ich habe die Batterie seit Ende August. Ich hatte bisher einen Jahresverbrauch von ca. 5000 kWh (Pellets-Heizung, Wasser über Heizung).
Wenn Ihr meine Meinung hören wollt zur Batterie-Größe: für meine Anlage will ich keine größere Batterie. Im Hochsommer kann ich gut damit die Nacht überbrücken (Sonnenuntergang ca. 21:00 bis Aufgang 6:00). In den Übergangszeiten reicht es nicht ganz, aber die Batterie wird aber zumindest noch voll.

Beim jetzigen November-Wetter bekomme ich die Batterie noch nicht mal 30-40% voll...
Und Betriebswirtschaftlich sagt, man, dass man mindestens 200 komplette Zyklen (Voll zu Leer und zurück) hinbekommen soll... Das wird mit einer größeren Batterie sehr schwierig (Sommer wird sie nicht leer und Winter niemals voll...).

Batterie ist was aus den Kategorie, "haben will". Wirtschaftlich ist es im Moment noch nicht, jedoch kann der kleine Mann in seinem Hobby mal testen, was schon möglich ist und bekommt ein Gefühl der Zufriedenheit etwas getan zu haben :-)

Ich habe meinen Speicher von vornherein etwas größer gewählt, damit er nach 10 Jahren nicht direkt ausgetauscht werden muss, wenn er durch Alterung Leistung verloren hat.
Durch eine externe Steuerung unterstütze ich den Speicher noch mit einem schonenderen Umgang.

- Im Sommer senke ich den SOC durch Ladungsbegrenzung, damit er Morgens niedrig aus der Nacht kommt.
- Alle paar Tage wird er auf 100% geladen (dann stimmt die SOC Berechnung besser)
- Hat er 100% erreicht wird ein ständiges Nachladen unterbunden
- Sommer MinSOC 5% Winter MinSOC 20%
- Im Winter erfolgt ein smart_Laden, bei dem der Speicher bis zum Erreichen von mindestens 90% nicht entladen wird.
  Das verhindert Notladungen und bringt voll Zyklen)
- Wenn die WallBox das BEV lädt schalte ich den Speicher auch auf smart_Laden, damit nicht von einem Speicher in den anderen Umgeladen wird.

Dadurch habe ich zwar weniger voll Zyklen, hoffe jedoch, dass der Speicher auch länger als 10 Jahre fit bleibt.

Und noch ein wichtiger Hinweis: Die Batterie ist nicht unbedingt dazu da lange Phasen zu überbrücken (Nacht), sondern vielmehr kürzere Phasen-Spitzen (z.B. Mittags der Herd bei schlechtem Wetter, usw.) - für solche Phasen von 30-60 Min zieht er sich dann ein paar Prozente aus der Batterie... Die Wahrscheinlichkeit grundsätzlich Nächte zu überbrücken lohnt sich dann deutlich betriebswirtschaftlich nicht...

Es ist aber schon klasse, wenn man von April bis Oktober 100% Autark ist ;-)

Die Meisten vergessen, das der Speicher nicht die Fehler beim Energiesparen ausbügelt. Man sollte immer vorher seinen Energieverbrauch optimieren und vorallem reduzieren.
Meine Wärmepumpe habe ich so optimiert, dass sie von sich aus in der PV-Zeit arbeitet, denn Sofortverbrauch geht vor Strom Speichern. Und selber Speichern geht vor Einspeisen ;-) Ich verwende jetzt drei Speicher:
 - Bausubstanz für Heizenergie
 - Haus Accu
 - E-Auto
 - Wirlpool :-), den habe ich extra nicht mitgezählt

VG
   Christian

[Nogga]

Wegen dem SQL-Query: Technisch gesehen macht es nichts anderes als sich für jeden Tag jeweils den kleinsten und den größten Wert der SOC zu holen. Das heisst Dein beobachteter Fehler muss in den Daten liegen. Zieh Dir doch spaßeshalber mal einfach alle Datensätze für den Tag und das Reading und schau manuell nach...

Bezügl. Deiner Batterielogik:

Ich glaube das ist ein Trugschluss mit der großen Batterie: Ich bin jetzt kein Batterie-Experte, aber vereinfacht gibt es 2 Wege der Batterie-Degradation:
1. Alterung (kalendärlich)
2. durch Nutzung = Zyklen

Du magst durch Deine Ladestrategie vielleicht die Alterung herauszögern, aber eine Batterie ist ja nicht zum "Speichern" da, sondern zum Laden und Entladen (sonst nutzt Dir die Batterie nicht).
Meine Recherchen haben ergeben, dass beim heutigen Preisniveau von Batterien ein sinnvoller (wirtschaftlicher) Einsatz nur dann ist, wenn Du mindestens ungefähr 200 Zyklen pro Jahr hast.
Bei weniger "altert" Dir die Batterie weg und Du ziehst keinen Nutzen daraus (s.o. Laden/Entladen, nicht speichern).

Aus meiner Sicht macht es mehr Sinn die Batterie lieber einen Ticken kleiner zu dimensionieren und später beim Ersatz (wenn die Batterien bestimmt deutlich günstiger sind), dann größer zu kaufen...

Ach und heutige Batterien sollten auch problemlos >10 Jahre halten (aber natürlich mit weniger Kapazität... und das ist genau der Knackpunkt der kalendarischen Alterung...)

Und ja, auch das persönliche Experimentieren/der Ehrgeiz ist durchaus legitim - ist bei mir ja auch so...

[ch.eick]

EDIT: Die Lösung liegt in dem Problem, dass das VALUE Feld auch als TEXT definiert ist, da es im FHEM ja Strings aufnehmen muss.
Um dann die max/min Funktion zu verwenden muss VALUE zuerst als dezimal Wert umgewandelt werden.

Code: [Auswählen]

max(cast(VALUE decimal(5,2))) AS VALUE


Wegen dem SQL-Query: Technisch gesehen macht es nichts anderes als sich für jeden Tag jeweils den kleinsten und den größten Wert der SOC zu holen. Das heisst Dein beobachteter Fehler muss in den Daten liegen. Zieh Dir doch spaßeshalber mal einfach alle Datensätze für den Tag und das Reading und schau manuell nach...

Wo soll da der Fehler in den Daten liegen.
Min und Max gehen auf die selbe Spalte, da ist eher die Min/Max Funktion der Übeltäter.

Min in der Spalte ist an dem Tag 6 und Max ist 20

Code: [Auswählen]

select * from history where DEVICE='WR_1' and READING='Act_state_of_charge' and TIMESTAMP>'2019-12-14 00:00:00' and TIMESTAMP<'2019-12-15 00:00:00';
+---------------------+--------+------------+-------+---------------------+-------+------+
| TIMESTAMP           | DEVICE | TYPE       | EVENT | READING             | VALUE | UNIT |
+---------------------+--------+------------+-------+---------------------+-------+------+
| 2019-12-14 00:00:16 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 9.00  |      |
| 2019-12-14 00:01:16 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 8.00  |      |
<snip>
| 2019-12-14 12:31:11 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 16.00 |      |
| 2019-12-14 12:34:14 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 16.00 |      |
<snip>
| 2019-12-14 12:45:07 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 19.00 |      |
| 2019-12-14 12:55:06 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 19.00 |      |
| 2019-12-14 12:57:13 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 20.00 |      |
| 2019-12-14 12:58:12 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 19.00 |      |
| 2019-12-14 12:59:07 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 19.00 |      |
| 2019-12-14 13:00:14 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 18.00 |      |
| 2019-12-14 13:01:13 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 18.00 |      |
<snip>
| 2019-12-14 19:56:28 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 7.00  |      |
| 2019-12-14 23:16:58 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 7.00  |      |
| 2019-12-14 23:17:48 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 6.00  |      |
| 2019-12-14 23:58:59 | WR_1   | MODBUSATTR | NULL  | Act_state_of_charge | 6.00  |      |
+---------------------+--------+------------+-------+---------------------+-------+------+
Da können wir gerne in PN weiter forschen, wenn Du magst.
Ich stelle gerade eh auf arm64 um und habe gerade eine neu MySQL 8.0.26 Datenbank im Docker Container gestartet.
Dann kann ich das da auch nochmal testen.

VG
   Christian