developer_mh

Hallo SPARE GmbH, danke für deine Meinung. Mit Sicherheit ist die Statik ein wichtiges Element bei der Planung von PV-Anlagen, keine Frage. Es gibt daneben viele weitere, ebenfalls sehr wichtige Elemente, die ebenfalls bei einer Planung und Ertragsberechnung berücksichtigt werden müssen. Wir haben in einigen Bereichen weniger zu bieten als unsere Mitbewerber, in anderen Bereichen mehr. Welche Planungssoftware die Endkunden letzten Endes verwenden möchten, liegt ganz an den individuellen Anforderungen und Vorlieben. Punkte, in denen wir sehr gut sind, sind (unserer Meinung nach): sehr große, von den Herstellern gepflegte Produkt-Datenbank viele mögliche Anlagenarten (nur PV, PV mit Verbrauchern, mit Batterie-Speichern, mit E-Auto, mit Thermie, Offgrid etc) viele mögliche Planungsarten (3D mit Modell-Import, 3D mit Karten-Import, 3D Freiplanung, 2D Dachplanung, 2D Photoplan, 2D manuell) Minutensimulation Automatische Verschaltung, auch mit SolarEdge-Produkten sehr gute, über viele Jahre gereifte und (soweit wir es mitbekommen von allen Banken in Europa anerkannte) Ertragssimulation Viele Pläne (Schaltplan, Bemaßungsplan, Strangplan), der Schaltplan frei konfigurierbar, zur Vorlage bei den Energieversorgern Detaillierte Wirtschaftlichkeitsberechnung Frei konfigurierbaren Projektbericht usw usf. Mehr dazu auch hier: https://valentin-software.com/produkte/pvsol-premium/ Ein Erklärungsansatz, warum unsere Kunden bisher auch ohne die Statikberechnung klarkommen, auch wenn sie sie sich bestimmt auch wünschen würden, ist folgender: Wir bzw. unsere Kunden haben die Erfahrung gemacht, dass sich viele Aufdach-Anlagen, also dachparallele, mit Dachhaken und Schienen, auch gut ohne dezidierte Statikberechnung planen lassen, einfach weil man mit der Zeit ein Gefühl für die Komponenten eines bestimmten Unterkonstruktions-Herstellers bekommt und dann weiß, was man bauen kann und was eher nicht. Bzw. wo man nochmal im Tool der Hersteller nachschauen muss. Am Anfang wird man wahrscheinlich ein paar Mal die Statikberechnung im Hersteller-Tool durchführen, dann merken, dass die Dachhaken und Schienen die Module im Normalfall locker tragen, und dann wird man mit der Zeit die Berechnung immer weniger benötigen. Bei größeren, aufgeständerten Anlagen ist es in der Regel ja sowieso Pflicht, sich die Statik von einem Statiker berechnen zu lassen. Nichtsdestotrotz ist wie gesagt auch die Integration einer einfachen Statikberechnung für dachparallele Systeme geplant. Es ist aber ehrlicherweise auch nicht das einzige Feature, das sich unsere Kunden wünschen, und jeder Kundenwunsch wird mit der entsprechenden Dringlichkeit übermittelt. Insofern bleibt uns nichts anderes übrig als zu priorisieren, und so schnell wie möglich, aber immer mit der notwendigen Sorgfalt, zu entwickeln. Anderen Software-Herstellern geht es da genauso. Als Kunde muss man sich dann eben fragen, welches Feature-Set im Hier und Jetzt schon das meiste von dem abdeckt, was man braucht, was man vom Entwickler-Team in der Zukunft erwarten kann (also wie ist die Entwicklungsgeschwindigkeit, wie oft kommen neue Releases etc.), und wie mandie Punkte anders lösen könnte, die die Software bisher nicht leisten kann. Jetzt ist der Text doch länger geworden, als ich vorhatte. Ich hoffe, meine Einschätzung hilft weiter. Wenn du noch weitere Fragen hast, bitte gerne. Viele Grüße, Martin

Hallo SPARE GmbH, danke für das Projekt. Am einfachsten ist es bei flächenübergreifenden Strängen wie in diesem Projekt, vor der Verkabelung die Modulreihenfolge im Reiter "Modulverschaltung" wie gewünscht anzupassen. Dann macht die automatische Verkabelung im Anschluss auch, was sie soll. Also hier in dieser Ansicht einen Teilstrang wählen, dann mit den Optionen unten links die Module vorsortieren und dann mit der Maus per Drag'n'Drop noch nachbessern: Die Reihenfolge der Module 1 bis 12 ist nun so, wie sie auch verkabelt werden sollen. Wenn man das für die beiden größeren Dachflächen macht, kommt bei der automatischen Verkabelung dann das gewünschte Ergebnis: Hoffe, das hilft weiter. Viele Grüße, Martin

Hallo SPARE GmbH, leider haben wir (noch) keine Statik-Berechnung in PV*SOL. Wir planen, eine einfache Statikberechnung für dachparallele Anlagen zur Planungsunterstützung zu integrieren, aber aus Gewährleistungsgründen ist es derzeit so, dass man tatsächlich die Hersteller-Tools (Renusol, K2, Schletter usw.) verwenden muss, um auf der sicheren Seite zu sein. Viele Grüße, Martin

Hallo SPARE Gmbh, Das ist eigenartig. Könntest du das Projekt vielleicht mal schicken, am besten hier im Forum als private Nachricht? Oder falls das nicht geht, an hotline@valentin-software.com, mit der Bitte um Weiterleitung an mich (Martin). Vielen Dank und beste Grüße, Martin

HI Sander, yes, I guess that would be possible. If you can isolate the cost of the battery system and the financial benefit due to the higher level of self-consumption (savings on the from-grid tariff), you can enter just that. Another way would be to enter all financial data for the system as it is now, simulate and save. And the add the battery system, add the extra cost, simulate and save as another file, and then compare the two files with the project comparison. Hope that helps, kind regards, Martin

Hi Zhaoyu, the input of the right coordinates is somewhat difficult in MeteoSyn. See our help page here. The error here is the missing minus sign in front of the latitude. And also the decimal coordinates need to be changed to dd.mmss notation. Dongguang is located at 22.95 °N and 113.90 °E. So you'll have to enter this: Dongguang 22.570,-113.54,50,-8,-30 Ta Gh FF RH 30.5 0 0 0 30.3 0 0 0 [...] You can easily calculate the resulting coordinates in Excel, like so: The formula used in cell D3 is =(B3-FLOOR.MATH(B3))*60/100+FLOOR.MATH(B3) Hope that helps, kind regards, Martin

HI Jimmy, yes this is possible. Please refer to this thread here: Kind regards, Martin

Hallo Andreas, danke für die Projektdatei. Die -15.766,55 € kommen folgendermaßen zustande: Man hat den Kredit in Höhe von 14.076,00 € auf dessen Restschuld man 20 Jahre lang Zinsen von 1,76 % zahlen muss. Die Kreditschuld und die Gesamtzinsen über 20 Jahre werden als Gesamtschuld betrachtet und ergeben sich zu 16.955,95 €. Das kann man nachrechnen, indem man die Kreditzinsen aller Jahre aufsummiert. Im ersten Jahr zahlt man davon 1.189,40 € ab, das entspricht dem jährlichen Cashflow ohne die Zinsen, da man die ja schon in die anfängliche Gesamtschuld mit aufgenommen hat, also 941,66 € + 247,74 € = 1.189,40 €. Es ergeben sich -15.766,55 € im kumulierten Cashflow abzüglich noch ausstehender Kredite. Hoffe, das hilft weiter. Beste Grüße, Martin

Dear Solarific, yes, in PV*SOL you can also use DC coupled battery systems. There are three kinds of coupling: AC coupling (coupling takes place on the AC side, after the PV inverter) DC intermediate circuit coupling (coupling takes place inside the PV inverter, in the DC intermediate circuit, i.e. before the DC/AC stage) DC generator coupling (coupling takes places on the DC string, before the PV inverter) See more information and grafics here: https://help.valentin-software.com/pvsol/en/calculation/battery-systems/#type-of-coupling Hope that helps, kind regards, Martin

Dear Sondre207, the percentage value that you enter and see displayed on the input dialog (bottom section of your screenshot) is the mean or average daily consumption in %. The consumption in kWh per month that you see in the upper diagram is the mean daily consumption multiplied by the number of days per month and then multiplied by the annual energy requirement. This is why February with its 28 days is lower than March with 31 days in the upper diagram whereas it appears higher in the lower diagram. Hope that helps, kind regards, Martin

Hi Jimmy, thanks for your explanation. A service for high quality drone models, ready to be used in PV*SOL, that is one big business idea! We know that there are a lot of people out there experimenting with this work flow as you did, trying to get drone models well prepared to be used in PV*SOL. And we are aware that this involves a very high amount of manual effort at the moment, and I guess there are just few planners that can afford putting all the time into it. So I there surely is a business case there! We wish you all the best for that enterprise and please let us know how it advances. In addition an idea could be to offer paid courses, on platforms like udemy or so, where you can pass the knwoledge to other people and still get financially rewarded. Kind regards, Martin

Hi Ryan, we didn't remove the own power percentage from the yield section. If the problem persists, please open up a new thread, perhaps along with a screenshot. Thanks and kind regards, Martin

Hi Jimmy, this really is astonishing! I especially like the quality of the edges of the buildings. Also the roof areas seem to be really plane and homogeneous! I guess a lot of our users would be very interested in your work flow there, and the data sources that you used. Kind regards, Martin

Hi, since PV*SOL is using the currency symbol of Windows, follow these instructions to change it in the Windows settings: https://www.isunshare.com/windows-10/customize-currency-format-on-windows-10.html Kind regards, Martin

Hallo Andreas, könntest du uns die Projektdatei zukommen lassen, dann ist es etwas leichter nachzuvollziehen. Gerne hier im Forum per privater Nachricht. Vielen Dank und beste Grüße, Martin

Hi Venco Gary, you can use tarriff zones when defining an from-grid tarriff, like so (never mind the € sign, the currency symbol is taken from the system): In the right side of the dialog, starting frm the top, you can set the number of zones to 3, then enter the prices for each zone (1.0207, 0.5968 and 0.2529), and then, in the tarriff zone table at the bottom, just highlight the cells you want to change and type in the number of the zone. I didn't know what the last two rows (daytime and average) where referring to, so I didn't include them in the example. Hope that helps, kind regards, Martin

Hi Kate, as Jimmy pointed out already, the module temperature really is the difference here. See our help pages for details: https://help.valentin-software.com/pvsol/2022/en/calculation/pv-modules/module-temperature/ As you can see, there is only 2K difference in comparison to "Mounted - Open Space". In addition you could adjust the albedo values in order to account for the higher reflectivity of the water surface in comparison to the standard value of 0.2, which is suitable e.g. for grass. But as you can see in this table here https://help.valentin-software.com/pvsol/2022/en/calculation/irradiation/ground-reflection/ the albedo is not significantly higher than 0.2, and is also strongly dependent on the inclination angle of the sun rays. So we don't adjust those values automatically, only the temperature difference at 1000 W/m², as mentioned above. Hope that helps, kind regards, Martin

Dear PV*SOL users, PV*SOL now features a fully automated PAN file import, accessible via the database dialog: https://help.valentin-software.com/pvsol/2022/en/databases/import-pan-files/ Hope that facilitates the usage of PAN files. We'd like to hear what you think of that new feature as well! Kind regards, Martin

Hallo Mohammad, sorry für die späte Antwort, wir hatten mit dem neuen Release alle Hände voll zu tun. Also mir ist nicht 100% klar, welche Art der Wirtschaftlichkeitsberechnung das Ziel sein soll, aber abgesehen davon, kann man das durchaus so machen, wie du es hier zeigst. Man könnte evtl. noch die Einspeiseabregelung auf 0% am Einspeisepunkt stellen, damit wirklich nichts mehr ins Netz eingespeist wird. Das geht vorne auf der Seite "Anlagenart, Klima und Netz" unter dem Punkt "AC-Netz". Und die Art der Wirtschaftlichkeitsberechnung evtl. auf Überschusseinspeisung umstellen, damit man für Deutschland übliche Strombezugstarife eingeben kann (wenn diese dann zur Wirtschaftlichkeitsberechnung hinzu genommen werden sollen). Viele Grüße, Martin

Hallo dw12623, die Frage nach dem passenden Wechselrichter lässt sich auf vielflältige Weise beantworten. In der Regel möchte man den kleinstmöglichen Wechselrichter, bei dem die auftretenden Abregelungsverluste noch im Rahmen sind. Was aber noch im Rahmen ist und was nicht mehr, ist eine individuelle Entscheidung und hängt letzten Endes von den Kosten der Wechselrichter und den anderen wirtschaftlichen Faktoren wie der Einspeisevergütung oder dem Eigenverbrauch und dem Bezugstarif ab. Eine Anlage ganz ohne Abregelungsverluste ist in der Regel aus wirtschaftlicher Sicht nicht erstrebenswert, wenn man davon ausgeht, dass man den nächst kleineren Wechselrichter zu einem günstigeren Preis bekommen kann. Aber im Detail muss das natürlich die Simulation und die Wirtschaftlichkeitsberechnung zeigen. Daher: Am besten ausprobieren mit verschiedenen Wechselrichtern, und in den Wirtschaftlichkeitsparametern möglichst realistische Preise eintragen. Dann sieht man ganz gut, wie sich die finanzielle Situation darstellt und kann die Varianten dann im Projektvergleich miteinander vergleichen. Die nominale DC-Leistung auf den Datenblättern beruht auf STC-Bedingungen, also 1000 W/m² und 25°C Modultemperatur. Die in den Carpetplots gezeigten Werte sind die simulierten Werte der Modulleistung zu jedem Simulationszeitschritt. Hier variieren Einstrahlung und Temperatur ja ständig. Insofern ist das nicht wirklich vergleichbar, bzw. vom Denkansatz nicht ganz der richtige Weg, vermute ich. Was der Unterschied zwischen den einzelnen Ergebnisgrößen genau ist, lässt sich aus der Energiebilanz ganz gut ablesen: Ja, tatsächlich, das ist eine kleine Unschönheit im Programm. Die Einheit W stimmt, bei den Texten wird (der Einfachheit halber) die Bezeichnung aus der Energiebilanz verwendet, bei der es sich um Energien handelt. Hoffe, das hilft erstmal weiter. Viele Grüße, Martin

Hi SolarEPC, this is correct, for on-grid systems we calculate the electricity production costs using the total PV energy yield, not taking into account the maximum feed-in power clipping at the feed-in point or own consumption. Concerning the own consumption I'd guess that this is correct, since you can use the rest of the PV energy for other purposes like feed-in. Concerning the clipping at the feed-in point, I'd say you are right, since the clipped energy is really "wasted" and can't be used elsewhere. I'll discuss that with my colleagues and put it on our list. Thanks for the feedback, kind regards, Martin

Hallo Mohammad, der Eigenverbrauchanteil ist ein Ergebnis der Simulation, er lässt sich also nicht vorher einstellen. Hier vielleicht noch ein Link zu einer ähnlichen Frage: Auch die Stromgestehungskosten ergeben sich aus den eingestellten Werten und der Simulation. Zu beachten sind hierbei die Installationskosten sowie die laufenden Kosten, die man auf der Wirtschaftlichkeitsseite einstellen kann, sowie die tatsächlich genutzte PV-Energie. Viele Grüße, Martin

Hi Solarific, a schedule based battery management is not available right now in PV*SOL, I am afraid. But we have it on the list. Kind regards, Martin

Hi k kent, it is only running on Windows. But if you want to run it on Mac, you can use Parallels [https://www.parallels.com/], VMWare, VirtualBox [https://www.virtualbox.org/] (or any other virtual machine that runs on Mac). Same applies for Linux. Best regards, Martin

Hallo Hannes, klar, das geht. Einfach beim Anlegen eines neuen 3D-Projekts den Kartenimport wählen und dann die Option "Von Festplatte laden" wählen. Dann kann ein Grundriss oder ein beliebiges anderes Bild geladen werden (muss im Format png, jpg, bmp vorliegen): Dann muss man noch den korrekten Maßstab ermitteln. Durch Klick auf das kleine Zahnrad gelangt man in den Maßstabsdialog, in dem man die blaue Linie mit ihren Endpunkten möglichst auf eine Bemaßungslinie zieht, deren Maße man kennt. Diese gibt man dann unten in das Feld ein: Dann alles bestätigen, und es wird der Grundriss in die 3D Umgebung geladen. Dort kann man dann mit dem Polygon-Tool den Grundriss nachzeichnen und anschließend ein 3D-Gebäude daraus extrudieren: Ich hoffe, das hilft weiter. Viele Grüße, Martin