Beiträge von opferwurst

    Da ich selbst immer froh bin, wenn jemand seine Erkenntnisse teilt, hier also eine Zusammenfassung meiner PV-Überschusssteuerung "OW-1"


    Funktionsübersicht:


    Aufbau:



    der OW-1 im Testaufbau mit einem Ölradiator:


    3 Tage Test:



    Mir ist bewusst, dass Phasenanschnittsteuerungen ab gewissen Wattzahlen nicht gern gesehen werden im Stromnetz. (...das waren Guerrila-PVs auch ;))

    Der verbaute Netzfilter ist ein kleiner Beitrag die entstehenden Oberschwingungen abzudämpfen, inweiweit kann ich nicht beurteilen.

    Mir ging es vorrangig um die Möglichkeiten so etwas mal umzusetzen mit einem kleinen Budget (unter 100 EU).

    Mit kleinen Verbrauchern unter 200W ist dies meines Wissens auch erlaubt.

    Vielleicht findet sich noch jemand, der dies genauer beurteilen kann als ich und noch Verbesserungen parat hat, um auch höhere Lasten zu schalten.




    Hier noch bei Interesse meine Teileliste:


    230V Komponenten


    Thyristorsteller 1 x Phasenanschnitt 230V 0 - 10V DC / 25 A

    Kühlkörper für SSR Relais, flache Bauform 125x70mm

    Sicherungshalter für Schmelzsicherungseinsätze für Sicherungseinsätze 10,3 x 38mm

    Keramik-Sicherungseinsatz gR oder aR Größe 1: 10,3 x 38mm / 16 A / gR

    Netzfilter corcom EMI Filter 10VT1 / 250V AC / 10A

    Hutschienen-Netzteil 12VDC 1,25 A 15 Watt Mean Well HDR-15-12 DIN-Rail

    div. Reihenklemmen

    Verlängerungskabel (miitg getrennt als Zu -und Verbraucherleitung)

    Gehäuse mit Montageplatte und Hutschiene



    Stromversorgung und Aufnahme für Wemos


    Lochrasterplatine

    LD1117V33 Spannungsregler - Linear, Typ78 TO-220 Positiv Fest 3.3V 800mA

    Kondensator 10nF und 100uF

    WemosD1 miniPro (oder ....)

    Leuchtdiode + 100R (visuelle Kontrolle Dimmer)



    Wandler Dimmer (PWM) zu 0-10V


    PWM To Voltage Converter Module 0%-100% to 0-10V


    das Script für den "Sender NodeMCU" an einem Easymeter q3B:


    Mein Dank noch einmal an sunburstc für die geduldige Unterstützung!


    Viele Grüsse OW

    Habe es nun so gemacht:


    Ich berechne den Wert um den der Dimmlevel an/absteigen soll aus der Differenz der aktueller Einspeisung (oder Bezug) zum Schwellwert und teile diesen durch in meinem Fall 150:


    ofs=(pcurr-sw)/150


    Somit ergeben sich bei grossen Differenzen grössere Sprungwerte des dimmlevels:


    ofs=1000W-50/150 = 6.3 d.h. der dimmlevel wird pro Sekunde um 6.3 erhöht/abgesenkt


    und bei kleineren Differenzen eben kleinere Sprungwerte:


    ofs=100W-50/150 = 0.63 d.h. der dimmlevel wird pro Sekunde um 0.63 erhöht/abgesenkt



    Da sich dabei ja die Vorzeichen ändern , da mal Einspeisung und mal Bezug, werden negative Werte positiv gemacht:



    if ofs<0{

    ofs=-ofs

    }


    aktueller Scriptauszug :



    Vergleich gestern (links) und heute (rechts). Die Ausreisser sind klar kleiner geworden:





    Und noch das schnellere und flachere Einschwingen:






    Ich denke, damit kann ich erstmal gut leben 😊

    Ich habe die Steuerung samt 1500W E-Heizer mal an eine ShellyPlugS gesteckt und die Verbrauchswerte heute mal mitgeloggt.



    Wie oben beschrieben, sind schnelle Lastwechsel nicht so schön, z.B. über die Mittagszeit das Intervallheizen des Herdes, oder das Abschalten des E-Heizers um 14.05 Uhr, oder bei Beginn und Ende der Wärmepumpentakte.


    Dafür wird ziemlich gut um den Schwellwert von -50W geregelt und der Überschuss wird schön dynamisch vom E-Heizer verbraucht.

    In meinem Script hatte ich folgende Änderungen gemacht:


    -Ausführung des dimmer-Befehls alle 20sec war natürlich zu lang -> auf jede Sekunde geändert

    -die Werte für die Verzögerung «vz» von 1 – 20 getestet

    -pheizstab mit kleineren und grösseren Werten als physischer Wert von 1500W


    Auch habe ich das Script von gnubbel mal getestet. Auch hier habe ich mit dem von ihm angebenen Werten «20» in der dimmerberechnung getestet:


    ;mit pheiz -"20" kann man ein wenig spielen wenn es trotz der Ladegerätanpassung (pheizstab) zu Überschwingern kommt

    dimmlevel=(pheiz-20)*100/pheizstab


    So sah das aus:





    Da beide Scripte bei mir massiv schwingen habe ich folgendes sehr einfaches Script getestet:

    (Achtung nur relevante Teile des Scripts)





    Ist die Einspeisung höher als der Schwellwert wird der dimmer gestartet und jede Sekunde um den Wert 0.5 aufaddiert, ist/wird sie kleiner wird entsprechend subtrahiert.


    Meiner Meinung nach ist so es egal, wieviel Leistung der gesteuerter Verbraucher hat. Die ganze pheiz Ermittlung und Umrechnung auf dimmer entfällt.

    Mir ist klar, dass dies immer hoch und runterregelt, aber das Ergebnis sieht deutlich besser aus:





    Durch den kleinen Auf/Abrechnungswert regelt der dimmer sehr träge. Fällt der Überschuss rapide z.B. durch einen zusätzlichen Verbraucher, braucht der dimmer halt mit 0.5 Schritten halt 200sec um von 100 auf 0 zu kommen.

    Hingegen höhere Werte als 0.5 bewirkten wieder ein grossen Überschwingen, dafür reagiert der dimmer dann schneller bei Veränderungen.


    Hier besteht ganz klar Optimierungsbedarf…

    Hab das nun endlich mal zusammengebaut und heute mal getestet:



    https://snapshot.raintank.io/d…utNmgi7luGF?orgId=2&kiosk

    (Graph wird nicht dargestellt ?!)


    Das Scrpt:

    als Verbraucher hatte ich einen E-Heizer mit 1500W angehängt. Die S20 Steckdose mit Heizlüfter war abgeklemmt.


    Läuft also noch nicht so wirklich rund. Was könnte man noch machen?

    Heute war mal kurz Sonne...


    if upsecs%tper==0

    and pin>0

    and curr>0 {
    if curr<15000{

    print akt curr %1curr%

    =>publish q3b/Power_curr %curr%


    ...und der curr wurde ein Minuswert und somit wurde kein publish mehr ausgeführt. (habe es gelöscht)


    Das gleiche auch hier:


    if upsecs%30==0

    and pin>0

    and curr>0 {

    dimmlevel=pheiz*100/pheizstab

    =>dimmer %0dimmlevel%


    Und mal eine Frage zum Variablenaufruf.

    Was ist der Unterschied von z.B. %curr% und %1curr% oder was bewirkt die Zahl vor der Variable?


    Ich habe auch Deine Dimmlevelbegrenzung eingefügt. Kannst Du mal bitte drüber schauen, denn ...

    .. danach hängt der NodeMCU. Keine Anzeige mehr, der Zugriff (wenn) dauert ewig. Ich dachte schon ich muss neu flashen.

    Betreffend des dimmer Befehls habe ich einfach in der Konsole mal diverse Werte getestet:



    wie oben bereits angedeutet, werden alle Dimmerwerte kleiner 0 und grösser 100 ignoriert. Bei einem Wert ausserhalb dieses Ranges bleibt der letzte gültige Dimmerwert bestehen.

    CloudySky


    Also ich würde denken, dass Dein Q3D SML statt OBIS sendet. Bisher hatte zwar nur bei Q3B SML aber egal.

    Wenn Dein Zähler also SML sendet, dann ist das hier falsch :


    >M 1
    +1,13,o,0,9600,OBIS

    1,1-0:1.8.0*255(@1,Verbrauch,KWh,Total_in,7

    1,1-0:21.7.255*255(@1,Verbrauch P1,W,Power_p1,2

    1,1-0:41.7.255*255(@1,Verbrauch P2,W,Power_p2,2

    1,1-0:61.7.255*255(@1,Verbrauch P3,W,Power_p3,2

    1,1-0:1.7.255*255(@1,Aktueller Verbrauch,W,Power_curr,2

    1,1-0:0.0.0*255(@#),Zähler Nr,,Meter_number,0


    dass muss dann z.B. so aussehen:


    >M 1

    +1,13,s,16,9600,SML

    1,77070100010800ff@1000,Verbrauch,KWh,Total_in,1

    1,77070100020801ff@1000,Einspeisung,KWh,Total_out,1

    1,77070100010700ff@1,Aktueller Verbrauch,W,Power_curr,0


    ggf. musst Du die entsprechenden Register (z.B. 77070100010800FF) anpassen

    sunburstc

    Deine Vermutung war goldrichtig! Dein Script lief ohne einen einzigen Aussetzer! Also habe ich einen neuen NodeMCU mit der aktuellen tasmota und Deinen Anpassungen geflasht um mehr Speicher usw. zu haben. Auch dieser läuft seit 12h ohne Aussetzer (sogar mit "0" statt "16" im Treiber)



    Also muss man mit => Websend aufpassen...

    Jetzt warte ich noch auf die letzten Teile für meine Ansteuerung des Heizers und auf Sonne und melde mich sicher wieder :)


    Schönen 3.Advend und vielen Dank

    OW

    ;was passiert hier?

    pcurr=0-SML#Power_curr


    Das ist ein noch ein Überbleibsel von gemus ersten Script für mich . Es wird einfach mit positiven Zahlen gerechnet (weil ja eigentlich bei PV-Überschuss/Einspeisung der Power_curr negativ ist) also 0 - (-300) = 300


    if pcurr>260{

    ->WebSend %url_1% POWER1 ON

    }if pcurr<10{

    ->WebSend %url_1% POWER1 OFF

    }


    Das könnte man natürlich auch mit Minuswerten curr rechnen, statt mit pcurr.


    Habe Deinen neuen Code (Danke!) jetzt gleich geladen. und beobachte ... Ggf. werde ich die von Dir angesprochene Websend-Geschichte mal deaktivieren.

    Ich musste allerdings das Debugfeature ,das Webdisplay und div. Kommentare löschen, da sonst nicht alles in den Speicher gepasst hat.



    dimmlevel=pheiz*100/pheizstab

    ;Warum wird der eigene Dimmlevel verändert?

    =>dimmer %0dimmlevel%


    Das kommt noch von meinen eigenen Versuchen :-) Hintergrund war die tatsächliche Leistung des Heizstabes mit einzuberechnen , da ja der Dimmer 0-100%-Werte ausgibt. Bei einem 250W Heizer wird mit dimmer 100 = 250W verbraucht , bei einem 2500W Heizer eben 2500W. Wenn das für Deine Dimmerberechnung nicht von Belang ist, kann das weg. Damals ist mir noch aufgefallen, dass Dimmerwerte über 100 ignoriert werden, es bleibt der letzte gültige Dimmerwert (0-100) bestehen .



    Bis später und vielen Dank nochmal

    Gruss OW

    Besten Dank für Deine Anpassungen!

    Durch die >M Sektion am Ende, wird nach dem speichern des Scripts (und diese also gestartet wird) bei allen drei Einzelwerten erstmal "0" gesendet. Der Power_curr wird dann nach 10 sec korrekt gesendet, Total_in und Total_out hingegen nicht. Auch eine Veränderung der upsecs%xxx

    brachte keine Änderung, bis auf upsecs%10 Erst damit werden auch diese Werte gesendet.


    Hier mal ein kurzer log vom Sensor:



    Ich konnte da eigentlich nichts ungewöhnliches erkennen, wie gesagt der NodeMCU mit TEKT5400 läuft in dieser Konstellation seit über einem Jahr ohne grössere Aussetzer.


    Und während ich dass schreibe habe ich wieder die grösseren Ausreisser:


    (liegt eventuell wieder am Treiber (0 statt 16) ?


    Mysteriöse Sache das ist :-) ...

    sunburstc

    Vielen Dank wieder für Deine Antwort.

    Ich hatte die letzten 24h nur mal den =>publish q3b/Power_curr %curr% aktiv. Hatte aber wieder so um die zehn "0er".

    Eigentlich müsste nur der Power_curr alle 10 Sekunden (meine Teleperoid) gesendet werden . Die Total_in und Total_out würde auch alle 10min reichen.

    Meine FW hatte ich auf Gitpod kompiliert und sicher nur mit 80 MHz. Werde das aber beim nächsten Mal probieren. Gibt es eigentlich hardwareseitig performante Unterschiede zwischen den vierschieden ESP-Boards?

    Zitat

    Oder die Websend Geschichte in mehrere Parts aufteilen,...

    Da bin ich überfragt. Ein delay einbauen ??


    Zitat

    Eine weitere Möglichkeit wäre, den Wert vor dem Websend abfragen. Befindet dieser sich bei <1 oder > 10kw dann soll der Wert nicht übertragen werden.

    Auch hier weiss ich nicht so recht ... Vermutlich eine if then else ??


    Gruss OW

    Das Problem bestand vorher nicht. Ich hatte im letzten Jahr vielleicht 10 Werte ausser der Reihe.
    In den letzten 24 hatte ich zehn "0"er und einmal einen 150kw Ausreisser.


    Das die Daten in jeder Teleperiod kommen, ist mir bewusst, doch diese kommen als json String :



    Da ich aber aus diversen Geräten in meine InfluxDB schreibe und die meisten nur einfache Werte ausgeben können ist im data format vom Telegraf auf "value" anstatt von "json" oder" influx" eingestellt.

    Daher die Aufsplittung in die Einzelwerte.

    Wenn ich von "=>" auf "->" wechsle, bekomme ich keine Daten mehr über mqtt.

    sunburstc


    Vielen Dank für Deine Tipps! Der mqtt Count war/ist immer 2. Daher habe ich im Treiber von 0 auf 16 gestellt. Die Min-Max-Ausschläge sind verschwunden. Einzig die "0 Watt" treten unregelmässig gehäuft auf :


        


    der letzte "Nuller" war heute Mittag um 12.15 Uhr.

    Damit kann ich leben.

    Habe jetzt seit 3 Tagen ebenfalls mal das Script zum Test laufen. (noch ohne Verbraucher) Dabei ist mir aufgefallen, dass seit dem immer wieder extreme Werte oder 0 ausgelesen werden


    Woran kann das liegen ?


    Hier mal mein derzeitiges Script:

    Ich habe mit einem Wemos D1 miniPro und diesem Konverter und nach gemus Tipp (Danke!) jetzt die folgende Werte


    Dimmer / PWM / 0-10V

    100 / 3.11 / 9.32

    80 / 2.48 / 7.99

    60 / 1.87 / 6.09

    50 / 1.56 / 5.14

    10 / 0.32 / 1.15


    Habe den Wemos auf einem DC-Shield mit 12V Netzteil, welches auch Strom für den Konverter liefert. In den Rezessionen war zu lesen, dass der Konverter min. 13V benötigt um die 10V bereitzustellen.

    Ich bin nun, aufgrund fehlender Infos von einer PVanlage ausgegangen.

    Am einfachsten wäre es übrigens wenn die Werte einzeln vorliegen würden. Also das was PV Produziert und das was der Haushalt verbraucht.

    Das würde einiges erleichtern denke ich.

    Hallo sunburstc


    Vielen Dank für Dein Script! Wenn ich alle Hardware zusammengetragen habe und mal die Sonne scheint, werde ich testen.

    Deine Annahme war richtig, ich habe aber nicht nur eine, sondern gleich 3 PVs. Angefangen habe ich vor 4 Jahren mit der 250Wp Guerilla, dann kam eine 1.6kWp dazu und jetzt nochmal ne 1.5kWp. (@gnubbel - ich verzichte bei allen 3 auf die Umverteilungsmassnahme "Einspeisevergütung")

    Wenn ich die Daten dann einzeln haben will muss ich alle 3 WRs auswerten, und das von SMA, Solax und Envertech. Ich habe zwar alle 3 am log, aber sobald einer mal keine Daten liefert, passt das dann nicht mehr. Also ist *Pcurr" die sicherste Variante meiner Meinung.


    Gruss OW

    sunburstc

    um mal hier am Beispiel zu bleiben:

    wenn die Einspeisung grösser als Schwellwert ist, dann setzte Power für Heizstab aus momentaner Einspeisung minus Schwellwert


    if pcurr>20

    then pheizstab=pcurr-20



    wenn ich das so lasse, wird ja die Einspeisung pcurr beim nächsten Aufruf der Schleife ja um die Leistung des Heizstabes kleiner (wenn der an ist).

    Somit müsste ich für den Wert für die Power des Heizstabes den beim nächsten Aufruf mit einrechnen resp. abziehen. Und genau hier müsste ich m.M. nach den Wert des letzten Wertes speichern um den beim nächsten Aufruf zu haben? Ich hoffe, verständlich?

    Wie würdest Du das machen?


    Gruss OW

    sunburstc

    kann ich eigentlich eine Variable nach einer Berechnung in einer if-then Schleife (>T) speichern und diese wieder vor dem nächsten Aufruf der Schleife wieder abrufen? Meine Versuche mit svars am Ende der Schleife führen zu keinem Erfolg. Die Variable habe ich im >D jeweils mit "p:var=0" als auch mit "var=0" probiert...

    hier nochmal mein Script. Habe es jetzt genau so am Laufen !

    Die power1 bis 3 Variablen kannst Du ignorieren

    Zum testen einfach statt:


    pcurr=0-SML#Power_curr

    pcurr=SML#Power_curr


    dann hast "Einspeisung" :-)