Mit einem Zuhause eingerichteten Balkon-Kraftwerk wegen der künstlich geschaffenen Energiepreiserhöhungen etwas Entlastung erreichen.

Auch das ist mal wieder ein äußerst heikles Thema... einerseits IT-Technisch, aber letztlich viel mehr bezogen auf die Realitäten unseres Lebensalltags. Insbesondere hierbei trifft Ideologie auf Realität, sowie quasi-religiöses Wunschdenken, mediale Indoktrination, Desinformation, Manipulation und politische Agitation auf unsere persönlichen Lebensumstände … und das alles in Kombination ganz sicher nicht positiv für uns selber. Nun ist’s wie es ist und die Umstände zwingen einen fast dazu, nach eigenen Möglichkeiten zur passiven Selbstverteidigung gegen unseren mittlerweile ziemlich übergriffigen und gegen die Bevölkerung handelnden Staat zu suchen. Im Grunde genommen war auch genau das meine Motivation, mein kleines Balkonkraftwerk einzurichten. Man kann besser das eigene Geld einmalig zum langfristigen eigenen Vorteil investieren, als es wegen vorsätzlich künstlich geschaffener struktureller Zwänge durch eine zweifelhafte politische Ideologie den Shareholdern in typischen Investment-Unternehmen über den Umweg der Energiekonzerne oder den Herstellern von vermeintlich ‚grüner‘ Groß-Technologie zu  übereignen.

Dieses Projekt war für mich hinsichtlich der IT-Technik jedenfalls in einem ziemlichen Umfang herausfordernd, so habe ich mich doch zum ersten Mal in die Programmierung mit Python einarbeiten müssen – Python war für mich eine völlig neue Erfahrung. Insofern bitte ich die erfahrenen Python-Entwickler um etwas Nachsicht, wenn ich vielleicht vorhandene bessere Möglichkeiten mangels Erfahrung nicht genutzt habe, oder ‚unnötige Umwege gefahren‘ bin, oder vielleicht hier und dort gewisse Python-Regeln verletzt habe. Am Ende ist allerdings die wichtigste Feststellung für mich, dass die Programme seit Monaten genau das tun, wofür sie entwickelt wurden, und zwar fehlerfrei und ohne Aussetzer.

Um ganz am Ende kommt auch hier wieder ein ganz persönlicher Aspekt hinzu, ich hatte nämlich durchaus auch einigen Spaß an den neuen Herausforderungen, an solchen technischen Spielereien sowieso, gerade auch und am meisten an der Software-Entwicklung ... und ich machs halt, weil bzw. wenn ich es kann.

Inhaltsübersicht über die Kapitel dieses Artikels:

> Festlegen von Rahmenbedingungen

> Anforderungsprofil und Beschreibung der Teilprozesse

> Das Programm

> Die Konfigurations-Datei(en)

> Setup

> Einrichten der Jobs

> HTML-Web-Viewer

> Benefit?

> Haftungsausschluss

Festlegen von Rahmenbedingungen

< zurück >

Nach meinem bisherigen Verständnis ist es anscheinend völlig normal, dass fortschrittliche private Solaranlagen (die sowieso) und auch die Inverter eines kleinen Balkonkraftwerks ihre Ertragsdaten auf einem modernen Smartphone automatisch mit informativen Grafiken und Diagrammen visualisieren. Weil es aber keine direkte Verbindung zwischen Inverter und den beliebigen Smartphone-Typen gibt und außerhalb des Heimnetzwerks vom Smartphone sowieso kein Zugriff auf den Inverter möglich wäre, erstellt der Inverter eben nicht selber die gewünschten Grafiken, um sie von dort mit dem Handy abrufen zu können, sondern er stellt nur Rohdaten zur Verfügung. Er überträgt aber auch diese Rohdaten nicht direkt aufs Smartphone, wo vielleicht dann ad hoc Grafiken gerechnet und gerendert werden (könnten), er sendet sie stattdessen ausgehend aus dem heimischen Netzwerk über das Internet an einen zentralen OEM-Cloud-Server zur zentralen Speicherung. Das Smartphone nutzt in der Folge dann eine spezielle App, die sich ebenfalls über das Internet zu eben diesem Cloud-Server verbindet und man bekommt die aktuellen Ertrags-Daten zum leichten Verständnis mit Diagrammen grafisch aufbereitet aufs Handy geschickt. Das hat wohl den Vorteil, das man nicht an ein Smartphone oder ein bestimmtes Smartphone-Betriebssystem gebunden ist, die entsprechenden Apps funktionieren plattformübergreifend und sind einfach in den Appstores zum Download verfügbar. Man muss sich auch nicht um die Datensicherung kümmern, man ist nicht ans heimische Netzwerk gebunden, alles funktioniert einfach und perfekt, egal wo man sich gerade aufhält, die Daten vom heimischen Kraftwerk werden auf Wunsch unmittelbar angezeigt … App installieren, Anmeldedaten in Smartphone und Inverter eingeben und schon wird das eigene Balkonkraftwerk grafisch verständlich aufbereitet in Aktion gezeigt. Einfacher und komfortabler geht fast nicht mehr. Aber ...

... in Zeiten von

- annähernd globaler digitaler Dominanz durch BigTech-Unternehmen wie Microsoft (Windows), Alphabet (Google), Meta (Facebook, Instagram, WhatsApp), Apple, Amazon, also den Big Five meisterhafter Orwell’scher Überwachung,

- dem fortschreitenden Demokratieabbau vorangetrieben durch unsere gewählten ‚Eliten‘, die beherrscht und gelenkt von NGO’s und den dahinterstehenden global aktiven Investment-/Finanz-Konzernen handeln,

- dem von der EU über zweifelhafte und lobbyistisch motivierte Gesetze permanent aufgeweichten privaten resp. persönlichen Datenschutz,

- dem allumfassend existierenden Geschäfts-Dogma, dass ein einfacher Bürger eigentlich gar nicht mehr respektiertes Subjekt ist, sondern nur noch ein beliebig manipulierbares Objekt finanziellen Profits ist,

habe ich mittlerweile jegliche Gutgläubigkeit an Integrität und Fairness zu diesen Firmen und der Politik im Allgemeinen bei der Verwendung von im Geschäftsprozess gewonnenen personenbezogenen Daten verloren. Und genau aus diesem Hintergrund ist es natürlich völlig ausgeschlossen, dass irgendein proprietäres System (der Inverter mit eigener Server-Software-Funktionalität) integraler Bestandteil unseres Netzwerkes wird und gleichzeitig über die Berechtigungen verfügt, eigene Verbindungen über das Internet mit einem fremden Cloud-Server herzustellen.

 

Ich kenne

diesen Server-Hoster nicht, also das dahinterstehende

kommerziell handelnde

Unternehmen, ebenso

wenig

deren möglicherweise an

unsere

n

privaten

Daten interessierte Geschäftspartner.

Die

u

nternehmensstrategi

schen Ziel

e

dieses Webspace-Dienstleisters

sowie deren Geschäftsphilosophie ist mir

völlig

unbekannt.

Der Service selber ist kostenlos, bezahle ich stattdessen mit meinen privaten Daten?

Mit welchen?

Handeln sie im Rahmen eines zum EU-Recht kompatiblen Compliance Management Systems oder

sind

sie nur an ‚fremde‘ und ggf. ‚lockerere‘ Gesetzgebungen gebunden?

Ich kenne den Standort

des

Servers

nicht,

ich habe keine Kenntnisse übe

r

dessen

Berechtigungskonzept

e

,

dessen

lokale

Zugangsschutz-Mechanismen,

ich habe

keinerlei Kenntnis darüber, welche Personen sich berechtigt oder unberechtigt dieses Servers bemächtigen können,

alles

vollständig

unbekannte Aspekte

.

Wobei all das allerdings nicht einmal das primäre Problem darstellt. Darüber hinaus ist im Wesentlichen eine in diesem Zusammenhang stehende Folgefunktionalität hochgradig suspekt. Und zwar, dass von mir völlig unbemerkt dieser fremde Cloud-Server automatisiert ein Software-Update auf meinem Inverter durchführen kann, also die Software des bei mir stehenden und in meinem Netzwerk autorisierten Inverters aktualisiert oder austauscht. Das bedeutet also in letzter Konsequenz, die Software des Inverters (u.a. der Web-Server) ist eine autorisierte Instanz in meinem Heimnetzwerk, sieht lokalen Netzwerk-Traffic sowie weitere Netzwerk-Komponenten, überträgt Daten nach ‚irgendwohin‘, ermöglicht einen meinerseits unautorisierten Zugang in unser Netz von außen und kann von außerhalb initiiert proprietäre Software austauschen oder installieren.

Dabei habe ich keinerlei Möglichkeiten, den TCP/UDP/Netzwerks-Funktionsumfang dieser ‚neuen‘ Software zu prüfen, zu aktivieren, zu deaktivieren, oder überhaupt deren stilles Wirken im Hintergrund festzustellen. Wenn man in Betracht zieht, dass vielleicht Linux die Software-Basis des Inverters ist und möglicherweise sogar ein SSH-Server integriert wäre, so bedeutet das schließlich, dass der Inverter quasi eine unkontrollierbare Backdoor in mein privates Netzwerk darstellen könnte. Nichts für ungut, aber das ist ein absolutes NoGo. Selbst wenn das Betreiber-Unternehmen dieser Cloud nur integre Absichten hat, so habe ich dennoch nicht die geringste Kenntnis darüber, wer sich möglicherweise auf Grund schlampiger Server-Security, mangelhafter Sicherheitskonzepte und Berechtigungsvergaben schlimmstenfalls dieses Servers bedienen könnte, um eine invasive Software auf die verbundenen in privaten lokalen Netzen integrierten Inverter zu installieren. Und sei es, wenn es durch die Administratoren selber auf behördliche Anweisung im Rahmen einer Schleierfahndung bei solchen Übergriffen wie mit dem Staatstrojaner (siehe BKA, Quellen-TKÜ) passieren könnte. Immer häufiger beinhaltet die Ermittlungsarbeit heute u.a. bei der anlasslosen (!) Massenüberwachung die Erhebung, Verdichtung und Verwertung etwa von Verbindungs- oder Telekommunikationsüberwachungs-Daten, Funkzellenauswertungen oder Daten über finanzielle Transaktionen.

Zu diesem Zweck können auch Systeme zur Telefonkommunikationsüberwachung und Analysetools angebunden werden. NoGo! Nach den vergangenen 3 Jahren und den 2 davor liegenden Legislaturperioden gibt es heute jedenfalls keine totalitären Steigerungen mehr, die ich mir jetzt nicht mehr vorstellen kann.

Nun gäbe es alternativ aber auch noch die Möglichkeit, den WLAN-Adapter des Inverters nur in unserem Gastnetz zu erlauben – das wäre wohl ausreichend getrennt von unserem lokalen Heimnetz, beantwortet letztlich aber auch nicht die Frage nach potentiell möglichen invasiven Attacken. Und schließlich, woher weiß ich, dass er nicht IP-Spoofing betreibt und sich dann doch unerlaubt ‚reinzuschleichen‘ versucht?

Darüber hinaus wäre er im Gastnetz für mich auch nicht via OpenVPN erreichbar. Insofern bleibt letztlich nur die Option, Einbindung ins lokale Netz, aber rigoroses Verbot für Verbindungen zum Internet. Aus diesen Gründen ist mein Inverter schließlich doch ein integrierter Bestandteil meines Netzwerks und damit Teil der Home-Automatisierung geworden, aber er hat wie z.B. die Web-Cams keinerlei Berechtigung, eine Verbindung ins Internet aufzubauen oder aus dem Internet heraus angesprochen werden zu können. Sicherheit und die Bewahrung meiner digitalen Privatsphäre ist innerhalb der computerisierten Welt unverändert mein primäres Interesse. Aber, um das noch einmal deutlich zu sagen, der Schutz unserer digitalen Privatsphäre betrifft ausdrücklich nicht die paar lächerlichen Stromertragsdaten meines Balkonkraftwerks, sondern ausschließlich die von mir unkontrollierbaren Netzwerksfunktionen eines in meinem Netzwerk autorisierten proprietären fremden Gerätes und die offene Frage, in welchem Umfang diese Software potentiell invasiv ist. Natürlich kann man das alles als Aluhut-Paranoia abtun und damit die Realität schlichtweg verleugnen… da sag ich dann nur, jeder wie er mag, aber bitte später nicht böse überrascht sein.

Tja, und das

bedauernswerte

Ergebnis dieser Beschränkung

en

und der abschließenden Entscheidung

ist nun offensichtlich, es gibt

leider

keine komfortabel visualisierten Daten über die Leistung und die Erträge unseres Balkonkraftwerks ... keine Daten, keine

Diagramme über Leistung und Erträge

, keine Informationen, aus denen sich ableiten lässt, wie man seinen eigenen teuren und kosten

intensiven

Stromverbrauch abgestimmt auf

die

Solarerträge optimiert.

Das heißt, wenn ich es in Bunt und mit Balken und Linien und mit Zeitraumvergleichen verständlich grafisch aufbereitet sehen und kontrollieren will, muss ich das selber erstellen.

Als Fazit auf die genannten obligatorischen Beschränkungen ergeben sich nun die folgenden grob umrissenen Rahmenbedingungen:

• ➢ 

Ein Zugriff von außerhalb des lokalen Netzwerks (also aus dem Internet) auf den Inverter ist untersagt, um eine unbemerkte Fremdkontrolle via Backdoor in unserem Netzwerk zu verhindern

• ➢ 

Dem Inverter selber wird der Zugang zum Internet vollständig untersagt, um sicherzustellen, dass sich eine interne proprietäre Server-Software nicht über eine Reverse-Connection als unkontrollierbare Schadsoftware im eigenen Netzwerk erweist

• ➢ 

Die Leistungs-Daten der Solar-Panels und der tatsächliche Ertrag müssen über das Web-Gui des Inverters ausgelesen werden

• ➢ 

Zur Speicherung der Daten und für notwendige Langzeit-Auswertungen wird eine SQL-fähige Datenbank angelegt

• ➢ 

Es sollen Grafiken über Produktivität und Erträge des BKWs über unsere Homepage via HTML-Steuerung auf allen unseren Geräten angezeigt werden können

• ➢ 

Der Upload aller visualisierten Auswertungen zur Homepage soll alternativ über FTP oder SSHFS erfolgen können

• ➢ 

Es wird eine eigene Software-Infrastruktur entwickelt, die alle Prozesse abdeckt

• ➢ 

Unser lokaler LAN-Server bekommt eine weitere virtuelle Debian-Instanz nur für diese neuen Aufgaben

Weitere sekundäre Anforderungen:

• ➢ 

Der spätere Betrieb muss wartungsarm und für mich weitestgehend aufwandsneutral erfolgen (ich will mich nicht ständig drum kümmern müssen)

• ➢ 

Wartungs-Zugriffe auf den virtuellen Server, auf Software, aufs Web-GUI resp. Customizing des Inverters erfolgen nur LAN-Intern

• ➢ 

Sofern ein Zugriff über das Internet notwendig ist, erfolgt dieser über eine OpenVPN-Verbindung (… also trotzdem nur LAN-Intern)

Anforderungsprofil und Beschreibung der Teilprozesse

< zurück >

Wie schon in der Vergangenheit bleibe ich auch hier meinem Vorsatz treu, ein mehr oder weniger kompliziertes Projekt in einzelne Teilschritte zu zerlegen, bei dem ich mich dann mit der Lösung eines jeden Einzelschritts exklusiv befasse, ohne mich dabei von anderen, gewesenen oder noch kommenden Belangen oder Problemen ablenken zu lassen. Deswegen werde ich jeden Teilprozess einzeln beschreiben. Natürlich habe ich zu Beginn schon eine genaue Vorstellung davon, was ganz am Ende dabei rauskommen soll. Und genau dafür gibt es ein kleines Pflichtenheft:

» Für die gesamte Arbeitsaufgabe sind 6 Teil-Prozesse resp. 6 Teil-Programme notwendig, jedes mit einer exklusiven Funktion. Darüber hinaus werden 2 Text-Files mit Konfigurationsangaben bzw. Einstellungen benötigt:

1. „Main“ (Shell-Eintrittspunkt) zur zentralen Prozess-Steuerung

2. Download der Daten vom Inverter und speichern in SQL-DB

3. Erzeugen von Grafiken

4. Upload via SHFS

5. Upload via FTP

6. Support-Modul für allgemeine Funktionen

7. Eine Konfigurations-Datei für die notwendige Customizing-Flexibilität

8. Eine Konfigurations-Datei für SQL-Queries

» Es ist für das Abbild eines Tages ausreichend genau, die Leistungsdaten des Inverters halbstündlich als Snapshots auszulesen

» Das Auslesen der Daten findet jahreszeitlich abgestimmt (helle/dunkle Monate, lange/kurze Tage) statt. Die notwendige Flexibilität wird über Customizing-Werte in einer Konfigurations-Datei hergestellt. Siehe Anmerkung unterhalb.

» Die Speicherung halbstündig ausgelesener Datensätze (hier max. 651 Records/Monat) erfolgt in einer SQLite-Datenbank

» Der dedizierte ‚Kraftwerks’-Server soll als isolierte Funktion im Rahmen der Home-Automatisierung in einer exklusiven VM laufen, die Datenbank selber wird auf einer Festplatte gespeichert und via Samba-Share zugemountet. Das ist keine ultimative Vorgabe, das Programm kann auch auf einem Raspberry PI, einem Arduino oder einem beliebigen anderen Linux-System laufen.

» Die gewonnenen Daten sollen zum besseren Verständnis über aussagekräftige Grafiken visualisiert werden

» Die Anzeige der Grafiken soll auch im Smartphone über das Internet unabhängig vom eigenen Standort möglich sein

» Eine permanent aktualisierte Just-in-Time Anzeigt ist nett, bleibt letztlich aber hier für die Erkenntnis über Wirkungsgrad und Zeitraum ein unnützes Gimmick, deshalb...

» ...die Grafiken werden halbstündig als JPEG erstellt und können damit von jedem beliebigen Internet-Browser angezeigt werden

» Nur die 30-Minuten-Aktualisierungen werden halbstündig grafisch upgedatet, der Tag als ganzes jedoch (optional) nur einmalig am Tag mit dem letzten Programmlauf des Tages

» Auf unseren Smartphones werden die auf der Homepage resp. im Webspace in einem besonderen Bereich gespeicherten Grafiken via beliebigen Internet-Browser angezeigt

» Für das einfache Online-Durchblättern der einzelnen Grafikseiten wird ein kleines HTML-Script erstellt

Im wesentlichen reduziert es sich auf nur drei relevante Prozess-Jobs, die unabhängig voneinander und nacheinander laufen. Zuerst das Auslesen und Speichern der Daten, dann das Erstellen der Grafiken und schließlich das  Hochladen der fertigen Grafiken auf den Web-Space, resp. zur Homepage oder Cloud. Dazu noch die primäre Ablaufsteuerung und einige Support-Routinen.

Bildlich dargestellt sieht der Ablauf wie folgt aus:

Und so sieht unsere Sonnen-Power-Installation aus. Es handelt sich um 2 Panels mit je 410 WP und dem Deye-Inverter SUN-M80G3-EU-Q0. Das Foto ist um 13 Uhr aufgenommen, Anfang August, also zur besten Mittagssonnenzeit, wie man am Schattenverlauf sehen kann. Die Neigung beträgt 55,7°, was vielleicht im Hochsommer nicht optimal ist, aber einen gerade noch akzeptablen Kompromiss zwischen Effizienz und Optik darstellt. Andererseits denke ich aber auch, dass diese Neigung wahrscheinlich etwas vorteilhafter ist, wenn in früheren und späteren Monaten des Jahres die Sonne eh flacher steht. Ums kurz zu sagen, egal, es muss sowieso so reichen.

Anmerkung:

Die schon frühzeitig vermutete Notwendigkeit zu diesem jahreszeitlich bezogenen Stunden-Setting hat sich im Laufe des Jahres bestätigt. Im Dezember, wo sich die Tage auf die Wintersonnenwende und damit dem kürzesten Tag des Jahres zubewegen, ist es irrelevant, Erträge protokollieren zu wollen, die morgens oder spät nachmittags geografisch hier am Ort  schlichtweg nicht gegeben sind. Fehlermeldungen und Nicht-Leistung muss ich wirklich nicht nachträglich ablesen können – insofern wurde hier zeitgleich mit den Erfahrungen das Setting passend für den Dezember korrigiert.

2023-12-14 09:00:02 [info] bkwDownload.py Program is started

2023-12-14 09:00:04 [warning] bkwTools.py Problem with Webserver!? [10.0.1.15]  Next attempt in 15 seconds: [1]

2023-12-14 09:00:21 [warning] bkwTools.py Problem with Webserver!? [10.0.1.15]  Next attempt in 30 seconds: [2]

2023-12-14 09:00:53 [warning] bkwTools.py Problem with Webserver!? [10.0.1.15]  Next attempt in 60 seconds: [3]

2023-12-14 09:01:55 [warning] bkwTools.py Problem with Webserver!? [10.0.1.15]  Next attempt in 120 seconds: [4]

2024-01-06 09:03:55 [info] bkwDownload.py Website-Data read out: []

2023-12-14 09:03:55 [err] bkwDownload.py Failed to fetch data/Server down!?

::::

2023-12-14 09:30:02 [info] bkwDownload.py Website-Data read out: 0,0

::::

2023-12-14 10:00:17 [info] bkwDownload.py Website-Data read out: 2,234.1

::::

2023-12-14 16:00:02 [info] bkw.py Program is started

2023-12-14 16:00:02 [info] bkwDownload.py Program is started

2023-12-14 16:00:04 [warning] bkwTools.py Problem with Webserver!? [10.0.1.15]  Next attempt in 15 seconds: [1]

2023-12-14 16:00:21 [warning] bkwTools.py Problem with Webserver!? [10.0.1.15]  Next attempt in 30 seconds: [2]

2023-12-14 16:00:53 [warning] bkwTools.py Problem with Webserver!? [10.0.1.15]  Next attempt in 60 seconds: [3]

2023-12-14 16:01:55 [warning] bkwTools.py Problem with Webserver!? [10.0.1.15]  Next attempt in 120 seconds: [4]

2023-12-14 16:03:55 [info] bkwDownload.py Website-Data read out: []

2023-12-14 16:03:55 [err] bkwDownload.py Failed to fetch data/Server down!?

Timestamp              Datum         Zeit     CurrWatt

2023-12-01 09:00:00    2023-12-01    09:00    0

2023-12-02 09:00:00    2023-12-02    09:00    11

2023-12-03 09:00:00    2023-12-03    09:00    2

2023-12-04 09:00:00    2023-12-04    09:00    3

2023-12-05 09:00:00    2023-12-05    09:00    0

2023-12-06 09:00:00    2023-12-06    09:00    0

2023-12-07 09:00:00    2023-12-07    09:00    11

2023-12-08 09:00:00    2023-12-08    09:00    0

2023-12-09 09:00:00    2023-12-09    09:00    6

2023-12-10 09:00:00    2023-12-10    09:00    0

2023-12-11 09:00:00    2023-12-11    09:00    0

2023-12-12 09:00:00    2023-12-12    09:00    0

2023-12-13 09:00:00    2023-12-13    09:00    2

2023-12-14 09:00:00    2023-12-14    09:00    0

Speziell zur Beantwortung dieser Frage, ab wann ist es hinsichtlich der Jahreszeit sinnvoll, täglich mit dem Protokollieren der Daten zu beginnen, sind im DB-Dump zwei Abfrage-Ergebnisse enthalten, die einmal den ersten Satz und einmal den letzten Satz eines Tages enthalten. Wenn man feststellt, dass ein gewisser Anteil (mehr als 1/4) der Datensätze 0 enthält, und die Mehrzahl an Datensätzen des Monats nicht über 5% der Maximal-Leistung hinauskommt, würde ich den Startwert des Zeitfensters um 1 Stunde erhöhen. Das gleiche gilt am späten Nachmittag bei der Ermittlung des letzten Tageswertes, wo man ggf. das Zeitfenster um 1 Stunde verkürzt.

Das Programm

< zurück >

Wie weiter oben schon einmal erwähnt hab ich mich entschieden, die benötigten Programm-Funktionen nicht alle innerhalb einer einzigen ‚großen‘ Datei unterzubringen, sondern das Projekt aus 6 Modulen mit jeweils einer exklusiver Funktion zu bilden. Dabei ist es natürlich nicht so, dass die 6 Module nicht wirklich als implementierte Funktionen Platz in einer einzelnen Datei gefunden hätten. Das wäre sogar gar kein Problem gewesen, weil die Module jedes für sich ganz sicher keinen Mammut-Umfang haben. Ich habe mich aber dennoch dagegen entschieden. Der Grund ist einfach, jedes Modul stellt eine autonome Job-Funktion dar, die auch ohne die anderen Job-Funktionen laufen würde. Da ist teilweise sogar noch der Shell-Eintrittspunkt enthalten und lediglich mit ‚#‘  kommentiert. Es macht mir halt die Fehlersuche in einem Modul einfacher, weil die Code-Zeilen-Anzahl schlichtweg gering ist und das Modul dadurch für mich übersichtlicher wird. Außerdem verhindert die Trennung in unterschiedlichen Dateien dumme Tippfehler in den Funktionen, die gerade nicht bearbeitet werden. Die Editor-Funktionen wie Suchen und im gesamten Dokument ersetzen können auch keinen Schaden anrichten, wenn nur die einzelne Job-Funktion das „gesamte Editor-Dokument“ darstellt.

bkw.py

bkwDownload.py

bkwChart.py

Zum Zeitpunkt der Planung und Festlegung, was ich künftig einmal sehen möchte, hatte ich zum einen nur eine vage Vorstellung über Art, Umfang und Aussehen der Datenvisualisierung, und zum anderen gab es noch gar keine auswertbaren Daten über einen längeren Zeitraum. Mit anderen Worten, es war anfangs eine rein hypothetische Festlegung, ohne einen realen Bezug oder Erfahrungen. Heute hab ich mittlerweile Daten, für mehr als 6 Monate. Und gerade auch die Wochendaten rückwirkend betrachtet sind schon sehr spannend, so beweisen sie doch mit sage und schreibe insgesamt 3 kompletten Sonnenwochen von Ende Mai bis Jahresende 2023, dass als Opfer des Klimawandels auch unser schönes Land kocht ... s.c.n.r... die restlichen Wochen waren solartechnisch schlichtweg beinahe ein ausgefallener Sommer.

bkwSSH.py

bkwFTP.py

bkwTools.py

bkw.html

Ich empfehle, das Programmverzeichnis zur Verhinderung unerwünschter bzw. unautorisierter Manipulationen im Verzeichnis /usr/local/bin mit exklusiven Schreib-/Änderungsrechten für ‚root‘ zu installieren. ‚root‘ ist/wird Eigentümer und hat als einziger das Recht, Veränderungen an den produktiven Quellcodes vorzunehmen. Ich selber halte es generell für eine gute Idee, niemals direkt im produktiven Verzeichnis Programmänderungen vorzunehmen. Für Anpassungen, Fehlerkorrekturen, irgendwelche Änderungen, etc. verwende ich immer eine separate Entwicklerumgebung, aus der nach sorgfältig durchgeführten Testläufen die neuen Dateien ins produktive Verzeichnis kopiert werden – natürlich wieder mit sofortiger exklusiver Rechte-Beschränkung nur für ‚root‘.

 

 

# ls /usr/local/bin/bkw

insgesamt 120K

drw-r--r-- 4 root root 4,0K 2024-01-21 18:31 .

drwxr-xr-x 8 root root 4,0K 2024-01-22 19:42 ..

drwxr-xr-x 2 root root 4,0K 2024-01-22 19:46 log

drwxr-xr-x 2 root root 4,0K 2024-01-20 16:10 ttf

-rw-r--r-- 1 root root  44K 2024-01-22 19:09 bkwChart.py

-rw-r--r-- 1 root root 2,5K 2024-01-23 19:24 bkw.conf

-rw-r--r-- 1 root root 7,5K 2024-01-20 15:40 bkwDownload.py

-rw-r--r-- 1 root root 2,6K 2024-01-23 18:58 bkwFTP.py

-rw-r--r-- 1 root root 8,3K 2024-01-21 18:07 bkw.py

-rw-r--r-- 1 root root 5,2K 2024-01-21 18:06 bkwSQL.xml

-rw-r--r-- 1 root root 3,4K 2024-01-23 18:58 bkwSSH.py

-rw-r--r-- 1 root root  13K 2024-01-23 19:08 bkwTools.py

-rw-r--r-- 1 root root 3,6K 2023-07-19 10:46 bkwWatermark.png

Das Programm benötigt zusätzlich die 4 folgenden temporären Arbeitsverzeichnisse, die für den korrekten Programmlauf bei Bedarf resp. zum Programmstart vom Programm erstellt werden:

/tmp/bkw/run

/tmp/bkw/jpg

/tmp/bkw/mnt

/tmp/bkw/db

1. Zum ersten benötigt Python selber das pycache-Verzeichnis zum temporären Speichern der Compiler-Byte-Codes. Das ist i.ü.S. sowas wie eine oversimplification mit dem Ziel, das Programm schneller zu machen, es dient also der Verbesserung der Programm-Performance. Sowohl das angegebene Verzeichnis als auch die Dateien werden bei jedem Start ggf. neu angelegt/kompiliert, sofern sie nicht vorhanden sind oder die Programme verändert wurden.

2. Als nächstes ist das Arbeitsverzeichnis zur vorübergehenden Speicherung der erstellten Grafiken notwendig. Das Programm legt das Verzeichnis an, wenn es nicht vorhanden ist.

3. Wenn die Grafiken via SSHFS auf den Web-Space übertragen werden sollen, ist weiterhin ein Verzeichnis für den lokalen Mount-Point notwendig. Das Verzeichnis wird ebenfalls maschinell angelegt, wenn es nicht vorhanden ist,

4. Und schließlich wird bei Verwendung der ‚undokumentierten‘ Dump-Funktion {-p} noch ein Verzeichnis für einen Datenbank-Dump über die SQL-Queries erstellt.

Weil es sich hier durchweg um nur temporär benötigte Dateien handelt, wo also die betroffenen Dateien nur eine sehr kurze zeitliche Bedeutung haben, empfehle ich, dieses Verzeichnis nach ‚tempfs‘ zu verlegen - unter Debian also das systemisch sowieso vorhandene Verzeichnis /tmp zu verwenden. Sowohl in der hier veröffentlichten Beispiel-Konfiguration ‚bkw.conf‘ als auch im Programmaufruf selber verwende ich generell /tmp.

An der Stelle ist abschließend nur festzustellen, egal wo das verwendete Verzeichnis auch angelegt wird, der User mit dessen Rechte das Programm gestartet wird, muss dort Schreib- und Leserechte für die Erstellung von Verzeichnissen und notwendigen Dateien besitzen. Die Frage erübrigt sich allerdings, wenn das Programm wie empfohlen exklusiv von root gestartet wird.

Die Konfigurations-Datei(en)

< zurück >

Für den korrekten Programmlauf sind 2 Konfigurationsdateien notwendig. Die erste (bkw.conf) enthält die primären Customizing-Settings, die also unmittelbar Einfluss auf das Programm bzw. den Programmablauf nehmen. Customizing bedeutet, dass der Systemverantwortliche an dieser Stelle Einfluss auf die Programmsteuerung nehmen kann, um vielleicht persönliche Einstellungen oder Optimierungen vorzunehmen. Die einzelnen  Parameter sowie deren Wirkweise wird hier im Kapitel anschließend erläutert.

Die zweite Einstellungsdatei (bkwSQL.xml) enthält die vom Programm auszuführenden SQL-Queries an die SQLite-Datenbank. Auch hier sind Änderungen prinzipiell möglich, die sind aber nur mit äußerster Vorsicht durchzuführen. Die Programme selber sind natürlich unmittelbar und fest an die Datenstruktur der vorhandenen Abfragen gebunden, das heißt, da gibts nur dann Flexibilität, wenn man passend zur geänderten Struktur beim Abfrage-Ergebnis auch die vorhandene Struktur in der Programmlogik ändert. Aber dazu muss man wirklich ganz genau wissen, was man tut bzw. was zu tun ist. ‚Try and error‘ wäre an dieser Stelle ganz sicher eine Katastrophe, zumal vom Programm die Spalten-Felder eines Records im Recordset teilweise auch indirekt adressiert werden. Das bedeutet, das Spaltenfelder teilweise nicht eindeutig erkennbar einfach mit ihrem Namen absolut referenziert werden, sondern auch indirekt über Iteration. Also, wenn ändern, dann aber bitte genau hingucken und sehr sorgfältig das Ergebnis überprüfen. Eine Erläuterung der einzelnen Queries erspare ich mir hier, die entsprechen halt dem Standard von SQLite-SQL-Abfragen und erklären sich zusammen mit der Datenbank von selber.

Befassen wir uns nun mit den verschiedenen Einstellungen in der bkw.conf:

sshfs_url     = www.toml.de

sshfs_user    = MySecretIdentName

sshfs_idfile  = /root/.ssh/id_rsa.ISP

sshfs_port    = 22

sshfs_path    = /tmp/bkw/mnt/www/bkw

ftp_host      = www.toml.de

ftp_user      = MySecretIdentName

ftp_pwd       =

ftp_pwdfile   = /root/.ssh/pwd_ftp.ISP

ftp_path      = /www/bkw

ftp_port      = 21

localmountpoint = /tmp/bkw/mnt

createchartin   = /tmp/bkw/jpg

rundir          = /tmp/bkw/run

dumpto          = /tmp/bkw/db

database      = /media/bkw/bkw.sdb

csvfilepath   = /usr/local/bin/bkw/log

loglevel      = 3

syslogpath    = /usr/local/bin/bkw/log

logrotate     = true

journald      = true

copylogto     = /tmp/bkw

copycsvto     = /tmp/bkw

copychartto   = /tmp/bkw

websrv_ip     = 10.0.1.15

websrv_authid = tom

websrv_authpw = myBKW-PWD

websrv_url    = http://10.0.1.15/status.html

invmaxW   = 650

invmaxKWH = 5,30,120

smoothmode = 0

watermark  = /bkw/bkwWatermark.png

Jan = 10-16

Feb = 10-16

Mär = 09-16

Apr = 09-17

Mai = 08-18

Jun = 08-18

Jul = 08-18

Aug = 08-18

Sep = 09-17

Okt = 09-17

Nov = 09-16

Dez = 10-16

Seasons = Jan-Mär,Apr-Mai,Jun-Sep,Okt-Okt,Nov-Dez

normal          = DejaVuSans,     /*/DejaVuSans.ttf

mono            = DejaVuSansMono, /*/DejaVuSansMono.ttf

monobold        = DejaVuSans*,    /*/DejaVuSans*.ttf

monoboldoblique = DejaVuSans*,    /*/DejaVuSans*.ttf

Setup

< zurück >

Die Inbetriebnahme der Programme auf einem neu installiertem System mit Debian-Bookworm hat sich bei 2 Tests erstaunlich einfach gestaltet. Sowohl auf einer ‚nackten‘ Installation ohne jegliche grafische Benutzeroberfläche (später das eigentliche produktive System) als auch mit einer xfce-Test-Installation waren nur die nachträgliche Installation von 2 zusätzlichen Paketen notwendig. Zum ersten die Support-Libs für grafische Ausgaben und Zeichnungen mit Python, und als zweites -sofern erwünscht- das Client-System für Datei-Mounts via SSH.

tom@d12: $ su -

root@d12: # dpkg -l python3-matplotlib sshfs

Wenn fehlend:

root@d12: # apt install python3-matplotlib

Wenn erwünscht:

root@d12: # apt install sshfs

Zur Verhinderung von unautorisiertem Missbrauch empfehle ich, die notwendigen Zugangsdaten für die Authentifikation zum Webspace des eigenen Internet-Service-Anbieters im root-eigenen Home-Dir mit exklusiver Leseberechtigung abzulegen. Hierbei muss man eine persönliche Entscheidung treffen: Läuft das Programm unter normalen User-Rechten mit ggf. offen lesbaren ISP-Zugangsdaten, oder läuft das Programm unter root-Rechten, wo sowohl Programm-Dateien (schreib-) als auch ISP-Zugangsdaten (lese-) geschützt sind. Ich habe mich für die root-Variante entschieden.

root@d12: # ls /root/.ssh

insgesamt 20K

drwx------ 2 root root 4,0K 2023-12-12 12:29 .

drwxr-xr-x 7 root root 4,0K 2024-01-18 19:46 ..

-rw------- 1 root root 2,6K 2021-03-30 19:50 id_rsa.ISP

-rw------- 1 root root   46 2023-12-12 12:38 pwd_ftp.ISP

Sind die notwendigen Vorbereitungen erfolgreich abgeschlossen, kann nun getestet werden, ob das Programm auch wirklich seinen Job erfolgreich erledigt:

# python3 -X pycache_prefix=/tmp/bkw/run /usr/local/bin/bkw/bkw.py -?

Startet das Programm als grundsätzlichen Basic-Test - die Hilfe wird angezeigt?

# python3 -X pycache_prefix=/tmp/bkw/run /usr/local/bin/bkw/bkw.py -d

SDD   ts: 2024-01-19 13:17:00     cw: 339    ck: 84.9

Sind die Zugangsdaten für den Deye-Inverter korrekt und die aktuellen Ertrags-Daten werden korrekt ausgelesen?

# ls /media/bkw/bkw.sdb

Zugriff auf '/bkw/bkw.sdb' nicht möglich: Datei nicht gefunden

Existiert die in der Conf angegebene Datenbank? Achtung, der angegebenen Pfad muss ggf. auf das eigene Setup angepasst werden.

# python3 -X pycache_prefix=/tmp/bkw/run /usr/local/bin/bkw/bkw.py -m

Create new SQLite-Database: [/media/bkw/bkw.sdb] Done!

Wenn nicht, anlegen!

# python3 -X pycache_prefix=/tmp/bkw/run /usr/local/bin/bkw/bkw.py -d -s

# journalctl -b | grep -i bkw

Jan 19 ... bkw.py[8604]:     New SQLite-DB successful created!

:::

Jan 19 ... bkwDownload.py[8635]: Program is started

Jan 19 ... bkwDownload.py[8641]: Website-Data read out: [216,85.0]

Jan 19 ... bkwDownload.py[8649]: Program ended successfully

Jan 19 ... bkw.py[8652]:         Program ended successfully [RC=0]

Liest die Daten von Deye-Inverter und schreibt sie in die SQLite-DB, Wenn keine Fehlermeldung erfolgt, war das erfolgreich.

# python3 -X pycache_prefix=/tmp/bkw/run /usr/local/bin/bkw/bkw.py -c

Erstellt einige Diagramme.

Achtung: Wegen grundsätzlich noch fehlenden auswertbaren Datenmengen können die Diagramme nicht sinnvoll sein. Das ändert sich erst nach einigen Tagen und wird informativer, je mehr abgeschlossene Tage vorliegen. Bei diesem Test geht es nur darum, dass der Programmlauf ohne Fehler oder Absturz erfolgt.

Sofern die Tests erfolgreich waren empfehle ich, die SQLite-DB jetzt wieder zu löschen, um den durch die Testphase angesammelten Datenmüll, der außerhalb der Zeiten der Programmlogik liegt, zu entfernen… um sie dann anschließend sofort wieder für den ersten regulären Produktivlauf als neue und leere Datei anzulegen:

# rm /media/bkw/bkw.sdb

# python3 -X pycache_prefix=/tmp/bkw/run /usr/local/bin/bkw/bkw.py -m

Einrichten der Jobs

< zurück >

Die Einrichtung des halbstündig zu startenden Jobs gestaltet sich nicht sehr kompliziert, ich nutze dafür einfach die root-Crontab, womit natürlich auch das Programm unter root-Rechten gestartet wird, Aber wie ich oben schon sagte, durch die begleitenden Maßnahmen halte ich das nicht für ein Sicherheitsrisiko oder gar für einen Exploit. Wichtig ist halt, dass die Programme außerhalb der Zugriffsrechte resp. Änderungsrechte der normalen User liegen und das der lesende Zugriff auf die zur Authentifikation zum ISP notwendigen Dateien ausschließlich durch root erfolgen kann. Damit ist dann auch dieser Blödsinn mit ‚sudo‘ vermieden, der m.M.n. bei unsachgemäßer Verwendung tatsächlich ein Exploit ist.

Zunächst ist der Wechsel des User-Kontextes in einem Terminalfenster notwendig, dann mit  crontab -e im Standard-Editor (nano, vim, o.ä.) die folgende Zeile am Ende anfügen und die Änderungen speichern.

tom@d12: $ su -

root@d12: # crontab -e

0,30 8-18 * * * /usr/bin/python3 -X pycache_prefix=/tmp/bkw/run /usr/local/bin/bkw/bkw.py -d -s -l -c -uS -t1 -t2

Wenn die Änderung gespeichert und der Editor beendet wurde, sind 2 Antworten möglich, abhängig davon, ob es schon eine aktive Crontab gab oder nicht:

# crontab -e

no crontab for root - using an empty one

crontab: installing new crontab

oder:

# crontab -e

crontab: installing new crontab

Eine kurze Erläuterung zur crontab:

Die Befehlszeile 0,30 8-18 * * * bedeutet also:

0,30

8-18

***

HTML-Web-Viewer

< zurück >

Für diesen Teilprozess hab ich mich für die tatsächlich ‚ärmste und schmuckloseste‘ Lösung entschieden, wobei ich es allerdings vorziehe, es lieber als die einfachste Lösung zu bezeichnen, die ich ohne großen eigenen Aufwand realisieren konnte. Es ist also nur ein einfaches völlig anspruchsloses html-Script geworden, welches außer vor- und zurückblättern für vordefinierte Dateinamen keine wirkliche Programmlogik enthält.

Darüber hinaus wollte ich die Sicherheit haben, dass es auch nach einem Provider-Wechsel wieder auf einer neuen Webseite läuft, denn - soweit ich mich erinnere - nicht alle privaten Provider-Verträge mit einem ISP erlauben in den günstigen Tarifen höhere Programmiersprachen wie z.B. Java oder gar Python. Nun ist’s wie es ist und ich sehe nach einem halben Jahr des Betriebs momentan keine Notwendigkeit, das zu verbessern – weil die vorhandene Funktionalität für meine Ansprüche schlichtweg ausreichend ist.

Das Programm bkw erzeugt (sofern Datensätze in ausreichender Anzahl vorliegen) die folgenden 12 jpg-Dateien, mit denen die Ertragsdaten des Balkonkraftwerks über unterschiedliche Zeiträume visualisiert werden:

• ➢ 

dsumy.jpg

Daily Summary, eine ½h aktualisierte Tagesübersicht

Akt. Snapshots+Aufgelaufen

Pie, Bars, Stack, Daten

• ➢ 

kwhy3.jpg

Ertrag Kwh je Monat

3 Kalenderjahre

Balken-Diagramm

• ➢ 

kwhm.jpg

Ertrag Kwh Summen je Monat und Jahr

10 Jahre fließend

Tabelle

• ➢ 

seasons.jpg

Effizienzbewertung nach Jahren und Jahreszeiten

12 Monate fließend

Tabelle

• ➢ 

kwhd365.jpg

Ertrag Kwh geglättet letzte 12 Monate

1 Jahr fließend

Flächen-Diagramm

• ➢ 

powerzones.jpg

Durchschnittliche Leistung in Watt/h in Jahreszeiten

12 Monate fließend

Linien-Diagramm

• ➢ 

cwd.jpg

Leistung in Watt/h heute

Aktuelle Snapshots

Balken-Diagramm

• ➢ 

cwd3.jpg

Leistung in Watt/h der letzten 3 Tage

Aktuelle Snapshots

Linien-Diagramm

• ➢ 

kwhd30.jpg

Ertrag Kwh/d der letzten 30 Tage

1 Monat fließend

Balken-Diagramm

• ➢ 

kwhd90.jpg

Ertrag Kwh/d der letzten 90 Tage

3 Monate fließend

Balken-Diagramm

• ➢ 

kwhw.jpg

Ertrag Kwh Summen je Kalenderwoche

52 Wochen fließend

Balken-Diagramm

• ➢ 

kwhd.jpg

Ertrag monatlich je Tag

12 Monate fließend

Tabelle

Das auf dem Web-Space (Homepage, im gleichen Verzeichnis) zusammen mit den Diagramm-Dateien liegende Script bkw.html scrollt mit Mouse-Click auf die Buttons vorwärts oder zurück durch die Dateien in vorgegebener Reihenfolge. Btw, falls jemand das eleganter und gleichermaßen portabel anders löst, würde ich mich über eine Verbesserung sehr freuen.

Der Beispiel-Aufruf des html-Scripts in einem beliebigen Internetbrowser zu den Testdaten auf meinem Web-Space sieht dann wie folgt aus. Aber Achtung, es handelt sich hier bei diesen Diagrammen wieder nur um die Symboldateien, die statisch sind, teilweise auf maschinell generierten Daten beruhen und nicht aktualisiert werden:

http://www.thlu.de/bkw/bkw.html

An dieser Stelle möchte ich noch einmal meinen Hinweis von oben wiederholen. Zeitnah nach der Inbetriebnahme des Programms ist es nicht möglich, die zunächst vorhandenen nur wenigen Daten sinnvoll und aussagefähig in den Diagrammen zu visualisieren, die darauf ausgelegt sind, Daten eben nur aus längeren Zeiträumen auszuwerten. Interessant wird es erst, wenn mal 2 Wochen oder mehr vorliegen. Der Informationsgehalt steigt mit der Menge an vorhandenen Datensätzen über vollständige Tage.

Benefit?

< zurück >

Und wie ist nun der Benefit zu bewerten, hat sich der Aufwand überhaupt gelohnt? Ja, tatsächlich, mein Resümee ist, es hat sich gelohnt. Es hat sich vor allem für die Monate Juni, Juli und August gelohnt, in denen wir einen permanenten Verbraucher konsequent fast vollständig kompensieren konnten – selbst vor der der Feststellung, dass speziell Juli und August eher schlappe Sonnenmonate waren, fast wie ein ausgefallener Sommer. Ein bisschen gezieltes Verbraucher-Management bei z.B. Waschmaschine und Geschirrspüler konnten an übrigen Sonnentagen zusätzliche Einsparungen erreichen. Insgesamt hat sich der am offiziellen 2W-Stromzähler aufgelaufene Wert im Vergleich zum Vorjahr merkbar reduziert. Eine Kehrseite der Medaille ist allerdings der von uns ungenutzt ins öffentliche Netz abgeflossene Ertragsstrom. Das ist zwar ärgerlich, zumal der beim Nachbarn auch noch mal von dessen Stromanbieter in Rechnung gestellt wird, obwohl dieser Anbieter den weder eingekauft noch produziert hat, aber das ist wohl so und derzeit leider auch nicht zu ändern… unsere Politik ist halt nicht Bürger- oder Verbraucherfreundlich motiviert, sondern als Unternehmens-Lobbyisten viel mehr an Konzernprofiten interessiert. Eine Saldierung von Verbrauch und Einspeisung mit dem Ergebnis „Diese Menge privat verbrauchter Strom ist die effektive Last für den Strommarkt und nur diese muss vom Kunden gekauft und bezahlt werden“ wäre zwar gerecht und entspräche auch der Fairness in einer Geschäftsbeziehung, aber das wollen die Stromkonzerne natürlich nicht … Profit geht natürlich vor Klimaschutz und offenbart schließlich auch hier wieder die obligatorische politische Heuchelei, die das durchaus ändern könnten, aber offensichtlich gar ändern nicht wollen.

Allerdings gabs auch einen Dämpfer für meine vorherige auf jegliche Erfahrung verzichtende Erwartungshaltung. Das die Erträge im Winter so einbrechen, hab ich tatsächlich zu Beginn nicht erwartet – wobei mir die heutige Erfahrung natürlich die Augen geöffnet hat. Reale Physik und eine Vorstellung ‚von irgendwas‘ passen halt nicht immer gut zusammen. Einem fast perfekten Sonnentag im Juli stehen im Dezember dann ganz andere Werte gegenüber – und das dann nicht nur für einen einzelnen Tag, sondern gleich zusammenhängend über  Wochen.

Neben den aktuellen Kurzzeitdaten ist aber insbesondere die Auswertung der Langzeitdaten hinsichtlich der grundsätzlichen Fragen nach Amortisationszeitraum, zur wirtschaftlichen Nachhaltigkeit und letztlich zum real zu erwartenden Benefit interessant. Und das über unterschiedliche lange Zeiträume, wie z.B. wochenweise, monatlich, quartalsweise, jährlich, 3-Jahreszeitraum, und schließlich eine Effizienzbewertung nach Jahreszeiten, für die hier ein Auswahl beispielhaft als Symbolbilder aufgeführt sind.

Hinweise zu den Diagrammen:

Die grüne durchgezogene Linie in Bild 2 und 3 zeigt nicht einen theoretischen Sollwert an, sondern den jeweils im gesamten Betriebszeitraum zu der jeweiligen Stunde faktisch gemessenen Höchstwert. Damit sind also nicht die Stundenhöchstwerte eines bestimmten Tages gemeint, sondern es könnten theoretisch bei 21 Halb-Stundenwerten die jeweiligen Halb-Stundenhöchstwerte von 21 verschiedenen Tagen sein.  Mit dieser Kurve ist über die bisher gespeicherten echten Ertragswerte beschrieben, zu welcher Leistung die Anlage effektiv in der Lage ist. Die grüne Linie in Bild 4 zeigt hier die geglätteten Erträge von 3 Tagen – allerdings ist das in dem Beispiel nicht sehr hilfreich, weil sich die Linien „Gemessener Wert“ und „Geglättet“ gegenseitig aufgrund der Nichterträge überlagern.

Es handelt sich bei diesen Grafiken um Symbol-Bilder, also nicht um die Darstellung von Echt-Daten, sondern um die Ergebnisse meines Entwickler-PCs, auf dem die Daten teilweise zuvor auch maschinell generiert oder repliziert wurden. Das war notwendig, um eine für Programmtests, für Plausibilitätstests der SQL-Abfragen, zur Erzeugung der Diagramme, als allgemeine Rechengrundlage für die langen Zeiträume, usw. einen ausreichend großen Datenbestand zu haben. Aber prinzipiell ist festzustellen, dass trotzdem reale Produktivdaten einigermaßen sinngemäß dargestellt werden.

1. „Daily Summary“

2. Die maximal erreichbare Leistung unter optimalen Bedingungen… was allerdings eher eine Ausnahme darstellt:

3. Ein krasser Gegensatz zum Juli dann im Dezember, der Wirkungsgrad ist im Vergleich von 97% auf 2% gefallen:

4. Diese tatsächliche Nicht-Leistung war aufgrund der typischen Dezember-Düsternis im ersten Solar-Jahr die Regel:

5. So wie in den beiden Bilder zuvor zieht es sich durch den ganzen Dezember. Und Anfang Januar, wenn sich endlich die klaren Tage mit eisigen Ost-Winden und Frosttemperaturen durchsetzen, wendet sich auf einmal das Blatt – der Wirkungsgrad steigert sich an einem günstigen Tag von 2% auf satte 73%:

6. Fließend wochenweise über die letzten 3 Jahre… wobei hier der Monat der Inbetriebnahme unseres BKWs im Mai 23 festzustellen ist… also die Darstellung wird sukzessive monatsweise ergänzt:

 

7. Fließend die letzten 12 Monate mit einer ‚geglätteten‘ Sichtweise der Einzelerträge pro Tag:

8. Jahreszeitliche Effizienzbewertung, die den saisonalen Durchschnitt mit Wirkungsgrad absolut und im Verhältnis zur tatsächlichen Bestleistung betrachtet:

 

9. Die durchschnittliche Leistung in Watt zur Tages-Uhrzeit in der betroffenen Jahreszeit in den letzten 12 Monaten:

10.0.1.0

IPv4

10.0.1.1

IPv4

10.0.1.15

IPv4

02.04.2024