Beiträge von Dachbeleger

    Nein, aber zu 3. fällt mir ein:

    Die Stromspeicherinspektion 2024 der HTW Berlin kommt zu dem Ergebnis, dass das im Referenzfall SPI 10 das schlechteste System 180 Euro mehr Betriebskosten pro Jahr verursacht bzw. weniger einspart als das beste. Das beste ist dort das RCT Power Storage DC 10 mit der Batterie 11.5. Das schlechteste System hat ohne Nennung des Herstellers teilgenommen. Hier im Forum las ich letztens mindestens 2 Threads mit dem Ergebnis, dass Huawei Luna der wahrscheinlichste Kandidat für das ineffizienteste System ist. Falls das stimmt und dein Verbrauchs- und Erzeugungsprofil genau zum SPI 10 passt, dann hast du nach 11 Jahren die Mehrkosten für RCT wieder drin.


    Stromspeicher-Inspektion 2024
    20 Solarstromspeicher von 14 Herstellern hat die HTW Berlin verglichen und zeigt auf, weshalb hohe Teillastwirkungsgrade wichtig sind.
    solar.htw-berlin.de


    Hier im Forum suchte ich nach Inspektion und dem Systemkürzel des ineffizienten System.

    Wie oben geschrieben hat mir das Stromnetz Berlin das Messkonzept 4.4 im Frühjahr angeboten. Aber eben nur mit Zählern mit Dreipunktbefestigung. Auf Dreipunktbefestigung müsste ich meinen Steckzählerschrank (Hager Univers Z, ZB23ES) auf meine Kosten umbauen lassen. Hat jemand eine Idee, wie teuer der Tausch der beiden Steckzählerplatten ungefähr wäre? Ob sie auch Standardlastprofilzähler abrechnen können, soll ich nächstes Jahr nochmal fragen.

    Ich habe soeben mit Stromnetz Berlin telefoniert und dort die Aussahe erhalten, dass eine Kaskadenmessung, wie in https://www.commetering.de/pdf…essung_M%C3%A4rz-2019.pdf unter Punkt "Messkonzept 3" beschrieben nur mit Lastgangzählern ausgeführt werden kann.

    Bei mir anscheinend gleiches Problem (VNB = Stromnetz Berlin, habe 2 eHZ (1x Haus und Überschuss PV, 1x WP) im Zählerschrank, wollte eine Kaskade).


    Meine Ergänzungen:

    • Stromnetz Berlin stimmt der Kaskade zu, allerdings muss ich die Zählerplätze mit 3-Punkt-Befestigung bereitstellen. Begründung war bei mir, dass derzeit nur Lastgänge miteinander verrechnet (im Sinne von abgerechnet) werden könnten.
    • Letzter schriftlicher Zwischenstand von Mitte April 2020: "Aktuell wird geprüft ob eine Umsetzung mit SLP Zählern von unserer Vertragsabteilung auch abrechnungstechnisch automatisiert umgesetzt werden kann. Sobald ich da das OK habe können wir auf die Dreipunktbefestigung für Lastgangzähler verzichten. Ich melde mich sobald es neue Informationen gibt."
    • Bei der letzten telefonischen Nachfrage konnte mir noch immer kein Datum genannt werden, wann ich die vorhandenen Steckzähler in die Kaskade einbauen lassen kann. Sinngemäß: "Wenn Sie die Kaskade jetzt brauchen, dann rüsten Sie auf 3-Punkt-Befestigung um. Sonst warten Sie bis (keine Prognose möglich) wir das abrechnen können."
    • Wegen der vom Stromnetz gewollten überqualifizierten Messung mit Lastgangzählern würde das Stromnetz auch die im Betrieb dafür anfallenden Mehrkosten übernehmen.


    Seitdem warte ich, ob sich noch etwas tut, um den Zählerschrank nicht von Steck- auf die Dreipunktbefestigung umbauen zu müssen. Über den Solaranlagenbauer bekam ich schon ohne den Umbau auf die 3-Punkt-Befestigung ein Angebot über pauschal 500 Euro netto für den Umbau auf Kaskade und die Anmeldung beim Stromnetz. Habe leider keinen Elektriker an der Angel :(

    Der KSEM / Energymanager wird halt dazu verwendet ne 70% weich Regelung des WR zu erlauben. Und diese Steuersignale gehen (so mein Verständnis) nur über die RS485 Kiste ...

    Schön wäre es. Bei mir habe ich allerdings beobachtet:

    * Seitdem der Elektriker das KSEM eingebaut und per RS484 an den Plenticore 10 angeschlossen hat, zeigt der WR die Netzeinspeisung an und berechnet aus der Differenz zur AC-Leistung den Hausverbrauch. Während der KSEM noch zum Stromzähler sehr ähnliche Leistungswerte zeigt, weicht der im WR angegebene Einspeisewert schon deutlicher davon ab. So als ob die Übertragung der Momentanwerte über RS485 irgendwie ungenau ist.

    * Ist nur RS485 angeschlossen, dann beschränkt sich die Funktionalität bei mir auf die reine Anzeige.

    * Ist zusätzlich zu RS485 auch LAN-Verbindung aktiv, dann hat die im KSEM eingestellte Wirkleistungsbegrenzung überhaupt einen Einfluss auf dem Plenticore. Die Einspeisung bei Wirkleistungsbegrenzung scheint mir aber eher eine kleine Achterbahn zu sein. Bei konstantem Hausverbrauch und wolkenlosem Himmel hätte ich - naiv wie ich zuvor eine feste Wirkleistungsbegrenzung vom SMA-Wechselrichter kannte - auch eine konstante WR-Leistung für eine konstante Einspeisung erwartet.


    Achterbahn bedeutet, dass die Erzeugung (und bei konstantem Hausverbrauch) die Einspeisung mindestens 10 aufeinanderfolgende Sekunden kontinuierlich erhöht wird (bis z.B. 200 W über meinen vorgegebenen 70%-Wert) und dann 10 Sekunden lang sinkt z.B. bis 200 W unter den vorgegebenen 70%-Wert). So geht es dann immer weiter, immer hoch und runter. Statt +-200W hatte ich aber auch schon deutlich größere Abweichungen gesehen, je nachdem, welche Werte man im KSEM bei "Wechselrichter Mittelwert" und "Energy Meter Mittelwert" einstellt.


    Wenn ich dann das Netzwerkkabel ziehe, wenn der WR gerade "auf Talfahrt" ist, dann bleibt er auf der Talfahrt. Auch wenn er dann irgendwann nur noch <40% erzeugt.


    Vielleicht sollte ich mal gucken, was passiert, wenn ich RS485 abklemme, ob damit zufällig die Achterbahn abflacht, falls über TCP und über das serielle Kabel nicht ganz zueinander passende Infos kommen.


    Neben dem "großen" Plenticore 10 habe ich als weiteren AC-Erzeuger einen "kleinen" SolarEdge 1500 Compact auf dem Geräteschuppen (keine Wirkleistungsbegrenzung im WR konfiguriert).

    Dachbeleger Wenn ich das richtig deute hast du 3 Module auf Ost und 3 auf West liegen oder? Und dann je 2 Module Ost / 2 Module West im Reihe an je einem Eingang und dann eins Ost und eins West an je einem eigenen Eingang.

    Das hast du genau richtig erkannt :D

    Irgendwo hier im Forum hat mal jemand ausprobiert, dass nur die parallele Verschaltung von einem Ost- mit einem gegenüberliegenden West-Modul fast keinen Ertragsverlust bringt. In den anderen Beiträgen stellte aber schon jemand fest, dass damit die Maximalspannung für den SE-Optimierer überschritten würde. Beim Schalten in Reihe von einem Ost- mit einem Westmodul würde in den Tagesrandlagen das eine Modul das andere aufheizen. Um das zu vermeiden, gibt es ja gerade diese Optimierer, wenn sie denn für den jeweiligen Einsatzzweck passen.

    Einen schönen Ostermontag :)

    ob das Ding bei Dir unverändert zum Fliegen kommt

    An der Zeile "from Crypto.Cipher import AES #windows" habe ich mir fast die Zähne ausgebissen, noch den Quelltext von crypto kompilieren lassen und dann festgestellt, dass dann doch nicht alles bei war.

    Auf meinem Linux-Laptop hat stattdessen letztendlich folgende Alternative Zeile zum Erfolg geführt:

    from Cryptodome.Cipher import AES


    Super, dann funktionierte das Einloggen mit deinem Skript!


    Als kleine Verbesserung habe ich die base_url durch Angabe des Hostnamens statt der IP-Adresse verallgemeinert

    BASE_URL = "http://scb/api/v1"


    und von Port 80 auf Port 443 umgestellt, um die Zugangsdaten nicht direkt im Klartext zu übertragen

    BASE_URL = "https://scb/api/v1"

    Dabei kam es dann wie erwartet zum Zertifikatsfehler

    Der WR verschickt keine Zertifikate

    Klar, dass die Authentifizierung des Clients nicht mit einem Clientzertifikat, sondern mit dem spannenden Algorithmus stattfindet. Hier geht es um das Serverzertifikat, welches nicht nur selbst signiert, sondern auch bereits vor über 30 Jahren abgelaufen ist.

    Mein Versuch das Zertifikat in eine Datei zu speichern und das abgerufene Zertifikat gegen die Datei zu validieren klappte bei mir nicht. Stattdessen habe ich als nicht so saubere Lösung bei allen (!) HTTPS-Aufrufen die clientseitige Prüfung des erhaltenen Serverzertifikats mit verify=False deaktiviert, z.B. beim ersten Request

    response = requests.post(url, data=step1, headers=headers, verify=False)


    Nun bin ich für meinen Teil zufrieden. Mit der von deinem Programm erzeugten Session kann mein bash-Skript nun die Leistungswerte herunterladen

    wget --no-check-certificate --header='Content-Type:application/json' --header="Authorization:$(python3 getsession.py)" --post-data='{"begin":"2020-04-03"}' -O rohdaten/eschensued$(date +%Y%m%d%H%M).csv https://scb/api/v1/logdata/download

    und anschließend auf dem Server zum Import in meine Ertragsdatenbank laden.


    kruki, du hast mir sehr geholfen, habe vielen lieben Dank dafür!


    Frohe Ostern :)

    Klasse kruki, dein Skript enthält genau die mir fehlenden Berechnungen für finish und createSession :love::danke:

    Das werde ich morgen gleich mal ausprobieren. Von Python habe ich keine Ahnung, mal gucken wie man das unbekannte Zertifikat vom WR akzeptieren kann, wenn man die Base url von http auf https ändert. Für mein Shell-Skript mit wget hatte ich den Parameter schon gefunden. Als default für deine IP könntest du auch den hostname "scb" verwenden. Trotz dass ich meinen WR-Namen geändert habe und der geänderte Name in download-Log und der Weboberfläche auftaucht, bleibt der Hostname scb bei mir erhalten.

    Ich erwarte dass der VNB eine auf 600W reduzierte Wirkleistungsbegrenzung akzeptiert? - entsprechende Anfrage ist raus.Das sollte wenn ichs richtig verstehe auch mit der Basisausführung des WRs möglich sein?

    Ich denke leider nicht: Wenn ich die Anleitung vom SE Compact richtig lese, dann steht im Kapitel für "Basic" die Konfiguration des Landes per DIP-Schalter. Ende, mehr nicht. Die Wirkleistungsbegrenzung steht nur im Kapitel von "Extended" per SetApp.

    Hallo Flo,


    richtig, ich verwende keinen Modbuszähler. Eine Wirkleistungsbegrenzung habe ich jedoch nicht eingestellt. Das könnte man mit der SetApp machen, habe ich aber nicht probiert. Bislang lag ich immer locker unter den 70%. Bei mir soll das Kostal-Energymeter am Netzverknüpfungspunkt messen und meinen Kostal-WR abregeln, wenn ich insgesamt zu viel einspeisen sollte.