Ralf

Oh, das überrascht mich jetzt aber wirklich. Warum ist das so? Man kann also auch die degradationsabhängigen Ertragsunterschiede zwischen Glas-Glas- und Glas-Folie-Modulen nicht deutlich machen? Ich empfinde das angesichts der Tatsache, daß hier ein professionelles Programm eine umfangreiche und gut präsentable Dokumentation erstellt, wo ansonsten fast alles stimmig ist, als echten Mangel. Es sollte auch nicht so schwer umzusetzen sein, zumindest als überschlägige Berechnung. Es wäre sicher relativ einfach möglich, den Jahresertrag (und die Autarkie) mit dem Mittelwert der Generatorleistung über 20 Jahre Degradation zu berechnen. Also wie im obigen Beispiel mit 92%. Dazu müßten die Algorithmen gar nicht angetastet werden.

Hallo Frederik, ich nutze Premium 2021 (V3) Projektdaten habe ich Dir geschickt. Freundliche Grüße

Hallo, ich habe folgendes Problem mit der Berücksichtigung der Degradation: Ich hatte zunächst ohne Degradation gerechnet. Daraufhin kam die Frage des Kunden, ob die Degradation berücksichtigt wäre. Daraufhin habe ich diese eingegeben, 80% nach 25 Jahren linear, und stellte erstaunt fest, daß keine neue Berechnung des Ertrages erfolgte, sondern sofort das (unveränderte) Ergebnis angezeigt wurde. Daraufhin habe ich die Berechnung erzwungen, indem ich ein fiktives Verschattungsobjekt hinzugefügt und dann wieder entfernt habe. Nun wurde neu berechnet - die Degradationskurve wird im Bericht angezeigt, die Werte wurden also übernommen - aber der Ertrag hat sich nicht geändert. Hier wird (mir und dem Kunden) also ein höherer Ertrag vorgetäuscht - und wenn man das nicht im Vergleich sieht, denkt man, die Degradation sei berücksichtigt worden. Wie ist das zu erklären? Wie läßt sich das Problem lösen? Hab ich einen Fehler gemacht? Muß ich da im Programm noch irgendwo etwas einstellen? Natürlich könnte ich den Ertrag händisch ausrechnen, 16% linear/20 Jahre wären 92% Ertrag über 20 Jahre. Aber der Eigenverbrauch und die Autarkie würden sich vermutlich nicht linear ändern. Und - ich müßte dann im Dokument Zahlen editieren, was einer Verfälschung der Simulationsergebnisse gleichkäme.

Ich möchte der Vollständigkeit halber die Antwort von der HTW hier zur Kenntnis geben: "Sehr geehrter Herr... ich kann Ihre Einschätzung völlig nachvollziehen. Metadaten zu den Haushalten sind uns nicht bekannt, da die Profile vom IZES ermittelt wurden, und da es sich um gemessene Profile handelt, können in einzelnen Monaten durchaus Abweichungen auftreten. Ich empfehle Ihnen hier ein anderes Profil zu wählen. Beste Grüße Dr.-Ing. Johannes Weniger Hochschule für Technik und Wirtschaft HTW Berlin FB1 | Forschungsgruppe Solarspeichersysteme Wilhelminenhofstr. 75A, 12459 Berlin https://pvspeicher.htw-berlin.de | https://pvspeicher.htw-berlin.de/news/" Es sind also, anders als vermutet, keine gemittelten Messwerte dargestellt, sondern die Messwerte einzelner Haushalte, mit allen Besonderheiten. Die Frage bleibt, wem nützen solche Lastprofile hinsichtlich einer Ertragssimulation, und haben sie zu Recht einen Platz in der Auswahl bei PVSol gefunden?

Danke, ich habe das soeben getan. Wenn Daten unplausibel erscheinen, oder aufgrund von "Ausreißern" nicht repräsentativ sind, sollte man sie nicht verwenden. Sicher kann man die Lastprofile (aus Tagesverläufen) verwenden, die zeigen den typischen Jahresgang, wie man ihn auch erwartet. Nur ist da - leider - die Auswahl bei EFH nicht groß.

Wunsch: (Mühsam) erstellte Gebäude und Gebäudeteile als Objekt speichern und in anderen Projekten einfügen können.

Hallo, es fällt auf, daß die hinterlegten Lastprofile oftmals nicht nachvollziehbare Verläufe zeigen. Einmal zeigt der Verlauf im Oktober einen nicht nachvollziehbaren Knick nach unten. Bei einem anderen Profil scheint der gesamte Verlauf widersinnig: Der Sprung von Dezember zu Januar, und der hohe Verbrauch im Sommer gegenüber den letzten drei Monaten des Jahres. Wenn man solche Diagramme in der Präsentation für den Kunden beläßt, sind Rückfragen vorprogrammiert. Und man möchte ja auch selbst eine seriöse Ertragssimulation haben, um gut beraten zu können. Wie entstehen solche Profile? Müßte das nicht vor der Verwendung auf Plausibilität geprüft werden?

Gibt es hier inzwischen eine anwenderfreundliche Weiterentwicklung?

Welche Datei brauchst Du?

Danke, es sollte sich vor allem der Ordner öffnen, aus dem das Programm gestartet wurde. Das betrifft auch nicht nur die Speicherung von Bildern, sondern auch beim "Projekt speichern unter..." wird nicht der Ursprungsordner angezeigt.

Hallo, wenn man seine Projekte in einer eigenen Ordnerstruktur, auf einem anderen Laufwerk speichert, schlägt das Programm dennoch immer einen Ordner in der Programmumgebung vor. Seit dem Release 21.03 nun im Meteonorm-Ordner. Und das passiert nun, anders als vorm Release, sogar wiederholt, bei jedem neuen Screenshot, der gespeichert werden soll. Das Programm "merkt" also nach wie vor nicht, aus welchem Ordner das Projekt geladen wird. Und seit dem Release merkt es sich auch nicht, wo die vorhergehenden Bilder gespeichert wurden, sondern bietet immer wieder diesen Ordner "7.3" an. ? Das hält bei der Arbeit sehr auf, wenn man sich jedesmal durch die Ordnerstruktur hangeln muß. Wäre schön, wenn hier eine Korrektur erfolgen würde, denn die allermeisten anderen Programme können das problemlos. Von Mikrosoft über Freeware zur Bildbearbeitung wie ShiftN bis hin zur Fotobuch-Gestaltungssoftware einer Drogeriekette. Es kann also kein Hexenwerk sein, das zu implementieren.

Danke! Ich werde den Tipp speichern, konnte ihn noch nicht testen, da das Problem aktuell nicht auftritt. Es war ja auch ganz plötzlich aufgetaucht.

Hallo, seit dem aktuellen Release werden die Buttons in der Werkzeugleiste nicht mehr normal dargestellt, siehe Bild. Über die Einstellungen (Schraubenschlüssel) gelingt es wenigstens, die Texte darunter anzuzeigen, so daß man weiterarbeiten kann. Bitte einen Tipp, wie man zur gewohnten vollständigen Ansicht zurück kommt.

Dankeschön, das ist eine klare und nachvollziehbare Auskunft.

Hallo, es gibt scheinbar einen Widerspruch. Es handelt sich um eine Anlage mit aufgeständerten Modulen und einer Umgebung mit vielfältigen schattenwerfenden Objekten. Die Werte der Verschattung der 16 Einzelmodule liegen zwischen 4,7% und 10,6%. Die Ertragsminderung durch Abschattung wird jedoch mit 15,8% angegeben. Wie lässt sich das erklären? Ich nahm nun an, daß die angegebenen Verschattungsverluste eventuell mehr Einflüsse berücksichtigen als nur die Modulverschattung. Dann aber sollte sich der Weet der Ertragsminderung verkleinern, wenn sich die Einstrahlungsverhältnisse verbessern. Durch eine Änderung des Aufstellwinkels bei gleichzeitiger Vergrößerung des Reihenabstandes wurden der spezifische Ertrag und damit auch Jahresertrag verbessert, das war beabsichtigt und erwartbar. Erstaunlicherweise liegen nun aber die Verschattungswerte der Einzelmodule zwischen 5,3 und 13,5%, und auch die Ertragsminderung durch Abschattung stieg auf 18,7%. Wie läßt sich das entwirren?

Ok, hatte ich die Überschrift da missinterpretiert ("Wie legt man ein Gelände in PVSol an?")? Wiesen UND BÄUME, das passt auch nicht zu einer Freiflächenanlage. Vielleicht meldet sich Philip noch mal? Zu Deiner Frage: Die Modulneigung sollte (innerhalb eines gemeinsam verschalteten Bereiches) nicht variieren, das wäre durch angepaßten Unterbau auszugleichen. Das Geländeprofil spielt insofern nur für die Verschattung eine Rolle - die jeweilige Modulneigung selbst muß ja im PVSol eingegeben werden, damit der Ertrag simuliert werden kann.

Noch ein Punkt. Das Nachladen der Batterien aus dem Netz ist damit erklärt. Aber warum erfolgt im Sommer der angesprochene Netzbezug für den Verbrauch und gleichzeitig Einspeisung, obwohl die Speicher mehr als genügend Kapazität besitzen? Genau hier müßte sich doch der Speicher positiv bemerkbar machen. Und auffällig ist weiter, dass die Netzstrom-Ladung der Batterien auch nur im Sommer so auffällig ist, wo doch PV-Strom zur Verfügung steht. Im Winter wäre das eher logisch. Liegt das vielleicht daran, dass der Verbrauch im Sommer eben so sehr niedrig ist im Vergleich zur Batterieleistung? Hast Du dafür evtl. auch eine Erklärung?

Danke Dir für diese profunde und auch sehr schnelle Analyse! Das anscheinend paradoxe Ergebnis ist damit erklärt. Und an den Ladestrategien kann man ja in der Realität vermutlich nichts ändern, insofern hat die PVsol-Software hier ganz zu Recht gewarnt, dass dieses Missverhältnis von Speichergröße und restlicher Anlage zu hohen Verlusten führt. Die Speicher führen ein Eigenleben; das ist bei ausgewogenen Auslegungen nur nicht auffällig. Damit kann ich den Kunden entsprechend beraten. Das wird mit anderen Speichertypen auch nicht viel anders aussehen. Ich werde es zum Vergleich auch mal bei einer anderen Anlage mit konventionellem WR (ohne Optimierer) mit einer überdimensionierten DC-Speicher-Konfiguration probieren.

Hab ich gemacht, danke!

Das gesamte Gelände wird ja nicht benötigt. Entscheidend ist die Horizontlinie. Die kann man vor Ort aufnehmen oder aus GoogleEarth über Linienprofile einzelne Horizontpunkte ermitteln. Das dann in Form einer Tabelle eingeben. Weiteres hier: https://help.valentin-software.com/pvsol/2020/navigationsseiten/pvmodule/verschattung/

PV-Anlage von 9,77kWp mit SolarEdge verschaltet, Wechselrichter SE9K-EU-APAC . Auf Wunsch des Kunden stolze 120kWh Speicherkapazität. Eigenverbrauch 8.800kWh/a. Speicher: 2x60 kWh (Tesvolt TS HV 70 (67 kWh) + SMA Tripower Storage 60) . Simulation mit Minutenwerten Trotz dieses überdimensionierten Speichers hat er auch im Sommer Bedarf an Netzstrom, obwohl er gleichzeitig jede Menge einspeist bzw. abregeln läßt. Das wäre bei einer Anlage ohne Speicher nicht verwunderlich. Bei einer Akkukapazität vom Fünffachen des Tagesbedarfes erscheint das aber unlogisch: Wenn er den Akku nicht vollbekommt, muß er natürlich Strom aus dem Netz ziehen. Da dürfte aber auch kein Strom zum Einspeisen übrig sein! Wenn er erst einspeist, nachdem der riesige Akku gefüllt ist, braucht er aber keinen Netzstrom, weil der Speicherinhalt fünf Tage ohne jede Sonne reichen sollte. Da Lade- und Entladeleistung bei 60kW (je Batterie!) liegen, dürfte das auch nicht der Grund für den Bezug von Netzstrom und "gleichzeitige" Einspeisung statt Batterieladung sein. Zu guter Letzt irritiert mich noch, dass die Batterien auch noch aus dem Netz geladen werden, und zwar recht erheblich, 426 kWh, und nur im Sommer, während Strom eingespeist wird.

Ich habe das ähnliche Problem mit SENEC V2.1 + Kostal Piko IQ gegenüber SENEC V3 hybrid (Duo). 9,2kWp Generatorleistung, da passt der V3 hybrid Duo mit seinen Leistungsdaten genau drauf. Auch hier werden Ertrag und Autarkie falsch berechnet. Dieser Berechnungsfehler bei der PR (und damit auch der Autarkie) müsste sich aber beim Saldieren, also am Zweirichtungszähler, wieder aufheben. Das tut er leider nicht. Obwohl wegen der DC-Zwischenkreiskopplung die Batterie nur von der Hälfte des Generators geladen werden kann und dadurch die Verluste durch Ladezyklen in dieser Variante um ca 100kWh niedriger sind, ist die Gesamtbilanz Einspeisung minus Netzbezug hier trotzdem um ca. 100kWh schlechter. Könnten hier weitere Berechnungsprobleme vorliegen, oder hat der V3 generell eine schlechtere Performance? Vielleicht hat jemand ähnliches festgestellt, die Umplanung von V2.1 auf V3 wird ja nicht gar so selten versucht werden.

Vielen Dank für diese Erklärung!

Ich habe eine Anlage mit 30 Modulen = 9,6kWp geplant und möchte die in einem String verschalten, damit ein DC-gekoppelter Speicher optimal arbeiten kann. Aus Erfahrung müsste ein SE9K-EU-APAC von SolarEdge das gut verkraften. Für die Option "automatisch verschalten" habe ich mehrere SolarEdge-Wechselrichter ausgewählt. Es wird angezeigt, daß für die gewählten Verschaltungsgrenzen keine Verschaltung möglich ist. Wähle ich den WR manuell aus, wird zwar der WR selbst als ausreichend dimensioniert angezeigt. Aber der MPP-Tracker ist mit rotem Kreuz markiert. Bei Klick darauf wird nur die Prüfung des WR angezeigt und nicht der MPP-Tracker, so daß nicht ersichtlich wird, warum dort ein rotes Kreuz angezeigt wird. Die Verschaltung lässt sich trotz dieses Fehlers speichern, das Projekt wird auch berechnet. Welche Ursache kann dieser Fehlermeldung zugrunde liegen?

Danke, das versteh ich. Aber welcher Wert ist dann z.B. für die Speicher-Förderung durch die SAB heranzuziehen? Sicher doch die Nenn-Kapazität. Mir ist es bisher auch bei keinem anderen Speicher aufgefallen, daß da zwischen Datenblatt / Nennkapazität und der Angabe im Programm Differenzen bestehen, wobei ja auch keiner der anderen Lithiumspeicher tiefentladen werden darf.