Trucki 2 Meanwell Stick - Überschussregelung für MW NPB 450-17(T2MG) / R4850G2(T2HG)

[suedseite]

Eure Antworten und Erklärungen sind ja schlüssig.

Ich setze nur Geräte einer Fa. aus Berlin ein und achte auch auf eine gute Verbindung. Ich habe mein ganzes Haus Wlan mässig gut unter "Kontrolle"...

Aber, aus der Not gehorchend, fängt man halt an zu frickeln: repeater, Schaltschrank offen lassen usw...alles keine gute Lösung..

Gerade habe ich einen tasmota Lesekopf MIT externer Antenne entdeckt und direkt bestellt.

Am Wochenende kann ich ihn installieren und werde dann berichten. Ich habe ja dann einen guten vorher - nachher Vergleich.

Danke für die Unterstützung

Micha

[jgebauer]

So, jetzt wo die Sonne scheint, habe ich auch Probleme mit der Firmware 1.10a, denn damit lädt der Meanwell trotz Überschuss nicht. Ein Downgrade auf 1.09 hat das Problem gelöst.

Wurde in 1.10a irgendetwas geändert, was das auslösen könnte? Ich schreibe per Skript in ioBroker den Meter Wert in MeterOVR, das wurde auch korrekt angezeigt im Web-Interface des T2MG. Nur bei ZEPC stand immer 0. Nach dem Downgrade ging es sofort wieder und lädt jetzt wunderbar mit knapp 500W.

[trucki]

Ja, durch die Umstellung auf den AsyncMeter readout ist bei MeterOVR ein kleiner Fehler reingekommen. Kannst Du mir bitte einenEmail schreiben? Danke

[heiwi]

Auch bei mir gab es ähnliche hier schon berichtete Probleme:

Mit den Firmwares 1.10a bzw 1.15 auf meinen beiden Sticks hatte ich readout times von 120-140 ms, die auch schon mal auf über 3000 ms anwuchsen. In der Stick-Oberfläche stand dann auch schon mal „No Data“. Sogar die Verbindung zum Browser brach ab, weil der server nicht mehr antwortete.

Nach downgrade auf die Vorgänger-Firmwares 1.09 bzw. 1.14 war wieder alles in Ordnung. Die readout time liegt bei beiden Sticks wieder bei Werten um 50 ms und steigt nur manchmal auf 120 ms an.

Das Verhalten ist reproduzierbar.

Zum WLAN-Aufbau: IR-Kopf zu Access-Point-1 mit -46 dB, T2SG/T2MG zu Access-Point-2 mit -62db/-72db.

Aufmerksam wurde ich, weil das Lade-/Entladeverhalten in meiner Grafana-Umgebung irgendwie merkwürdig anzusehen war. Irgendwie reagierten die Lade- und Entladegeräte anders als früher. Da aber nicht so viel Sonnenschein war, war es zunächst schwer zu beobachten.

Heiko

Edit: alle Access Points sind von Unifi und per LAN angebunden, keine Repeater.

[trucki]

Das könnte vielleicht mit dem Chunked Http Transfer von Tasmota zu tun haben. Welche Tasmota Version verwendest Du? Und was für einen ESP?

[suedseite]

Guten Morgen,
bei mir ist es "tasmota32" 15.1.0
WiFi IR SMI SMA V32
beste Grüße

Micha

[heiwi]

Bei mir ist es:

13.4.0.1(tasmota32)

ESP32-C3

Da mein Verkäufer (Diamex) von updates abrät, da in der originalen Tasmotafirmware keine Script-Möglichkeit vorhanden sei, und auf seiner Seite keine neuere Firmware anbietet, habe ich bisher auch kein update durchgeführt.

Heiko

[trucki]

Ich habe mir jetzt ein Tasmota SML mit meinem SDM630 gebaut. Leider kann ich den Fehler “No Data” (noch) nicht reproduzieren.

Mein SML Script

D
B
->sensor53 r

M 1
+1,13,m,0,9600,SDM630,2(12),5,r010400340002
1,010404ffffffff@i0:1,Power_Total,W,Power_Total,2

ist sehr kurz gehalten, damit die Payload von http://192.168.1.131/cm?cmnd=status%2010 auch klein ist:

{"StatusSNS":{"Time":"2026-02-20T18:22:50","SDM630":{"Power_Total":696.88}}}

Der gesamte Abruf dauert dann auf meinem PC 121ms:

Wie sieht Euer SML Script aus? Wie groß ist Eure Payload? Wie lange dauert da Abruf auf dem PC?

Gruß, Trucki

[suedseite]

Hi Trucki,
vielen Dank für die Unterstützung!

Ich habe dieses Script auf der Github Tasmota Seite für meinen Zähler gefunden und installiert.
Seitdem funktioniert es...

D
B
=>sensor53 r
M 1
+1,3,s,0,9600,DWS7612
1,77070100010800ff@1000,Energie_bezogen,kWh,energy1,2
1,77070100020800ff@1000,Energie_geliefert,kWh,ernergy2,2
1,77070100100700ff@1,Momentanleistung,W,power,1

Ich habe leider keine Ahnung was ein "payload" ist oder wie man die Laufzeit ermittelt...

Also mit der 1.09 funktionierte es super...
Wenn Morgen mal die Sonne scheint, installiere ich die 1.10a und teste das Ladeverhalten der Meanwells ( 1x 1200-24 und 1x 750 -24, letzteres als Kaskade für über 1000W).
Das war ja bei mir der Knackpunkt, das der 1200er MW immer rauf und runter regelte ohne einen wirklichen Grund...

Ich melde mich dann noch einmal...

Danke für Deine Mühe...

Beste Grüße

Micha

[heiwi]

D
B
TelePeriod 10
=>sensor53 r
M 1
; Device: eBZ DD3 2R06 ODZ1
; protocol is D0 OBIS ASCII
; 9600@7E1 for OP-type devices, 9600@8N1 for SM-type devices
+1,3,o,0,9600,SM,1
; Zählerstand zu +A, tariflos,
; Zählerstände Auflösung 10 µWh (6 Vorkomma- und 8 Nachkommastellen)
1,1-0:1.8.0255(@0.001,Energie Bezug,Wh,1_8_0,8
; Zählerstand zu +A, Tarif 1
1,1-0:1.8.1255(@0.001*,Energie Bezug HT,Wh,1_8_1,8
; Zählerstand zu +A, Tarif 2
1,1-0:1.8.2255(@0.001,Energie Bezug NT,Wh,1_8_2,8
; Zählerstand zu -A, tariflos
1,1-0:2.8.0255(@0.001,Energie Export,Wh,2_8_0,8
; Summe der Momentan-Leistungen in allen Phasen, Auflösung 0,01W (5 Vorkomma- und 2 Nachkommastellen)
1,1-0:16.7.0255(@1,Leistung,W,16_7_0,18
; Momentane Leistung in Phase Lx, Auflösung 0,01W (5 Vorkomma- und 2 Nachkommastellen)
1,1-0:36.7.0255(@1,Leistung L1,W,36_7_0,18
1,1-0:56.7.0255(@1,Leistung L2,W,56_7_0,18
1,1-0:76.7.0255(@1,Leistung L3,W,76_7_0,18
; Spannung in Phase Lx, Auflösung 0,1V (nur über MSB)
1,1-0:32.7.0255(@1,Spannung L1,V,32_7_0,1
1,1-0:52.7.0255(@1,Spannung L2,V,52_7_0,1
1,1-0:72.7.0255(@1,Spannung L3,V,72_7_0,1
; Statuswort, 4 Byte Information über den Betriebszustand, HEX string
; tasmota can decode one string per device only!
;1,1-0:96.5.0255(@#),Status1,,96_5_0,0
;1,1-0:96.8.0255(@#),Status2,,96_8_0,0
; Geräte-Identifikation, Nach DIN 43863-5
1,1-0:96.1.0255(@#),Identifikation,,96_1_0,0
;1,1-0:0.0.0*255(@#),Identifikation,,0_0_0,0

So sieht mein Script aus. Es werden zwar einige Daten mehr übermittelt, aber unter 1.09 bzw 1.14 Zeiten von um 50 ms und keinerlei Probleme. Dass die Zeit mal auf 100-120 ms hoch geht, mag ja in Ordnung sein.
Solange es keine Probleme gibt, ist ja auch alles gut. Dass aber unter den neuen firmwares sporadisch Zeiten von etwas über 3000 ms auftreten können, bringt ja jede Regelung durcheinander.

Ich habe mal just das T2SG auf 1.15 geupdated:

Wo kommt das „linked“ her? Es scheint um diese Uhrzeit keine Sonne und das T2MG, z.Zt. auf 1.09, lädt auch nicht manuell.

Zurück auf 1.14 und die Welt ist wieder in Ordnung.

[trucki]

Vielen Dank für das schnelle Feedback.

@Suedseite gut zu wissen, dass es mit einem kurzen SML Script schon mal läuft. Das schränkt die Suche erheblich ein.

@Heiwi Könntest Du bitte mal deine MeterURL http://192.168.0.10/cm?cmnd=status%2010 in deinem Browser (vorzugsweise Chrome) öffnen und F12 drücken und die Seite neu laden. In der Spalte Name dann auf “cm?cmnd=status%2010” und dann auf den Reiter Timing und davon bitte einen Screeshot posten. Dann wüsste ich ab welcher Zeit der Timeout ausgelöst wird, was vermutlich zu dem “No Data” Fehler und der readout time von 3.000ms führt. - Danke

Edit: Der Inhalt der Seite (payload) wäre auch hilfreich.

Linked wird angezeigt wenn das T2M/SG mit seiner IP bei einem anderen T2M/SG als SUN/CHG2/3 eingetragen ist. Dann braucht es kein Meter mehr, weil die Steuerung ja vom SUN/CHG1 übernommen wird.

Gruß,

Trucki

[heiwi]

@trucki Anbei die gewünschten screenshots. Ich hoffe, ich habe alles richtig gemacht. Die Microsoft-Welt ist nicht mehr meine und Chrome auch nicht.

Zu "Linked": es taucht auch dann auf, wenn das T2MG den Akku lädt. Logisch, da da T2SG dann ja nicht entladen darf. Allerdings macht das keinen Sinn, wenn man sich in der Geisterstunde befindet.

Edit: Wobei mir jetzt nachträglich einfällt, dass das T2SG oder der SUN ca. alle 4 Stunden eine kurze Entladung von ca 30 Watt meldet, die tatsächlich aber nicht stattfindet. Eine Shelly-Steckdose vor dem SUN meldet keine Entladeleistung. In der Energiebilanz des T2SG wird diese kurze Pseudoentladung dann mit 0,1 kWh eingerechnet, was dazu führt, dass die Energieangaben des T2SG nicht benutzbar sind. Diese „Entladung“ findet sogar bei leerem Akku statt. Evtl resultiert daher das „Linked“ in dem obigen Bild.

Diese zwei Bilder, als "no data" zu lesen war:

Diese beiden Bilder als sogar "parse err" zu lesen war:

[suedseite]

Hallo zusammen,
ich habe mein MW 1200-24 von 1.09 auf 1.10a upgedated:

Siehe Bild 1+2:

Danach wieder zurück auf 1.09:

..und jetzt läuft gar nichts mehr....

Die Daten vom Tasmota kommen aber rein:

Alle device hängen an einer 7690, keine repeater...

Nachtrag:
Auch ein Neustart brachte hier keine Besserung. Ich habe mein 2. MW 750 einmal kurz eingeschaltet (Fw1.09) und nach kurzer Zeit stand unter Meter auch http err...

Der zeitgleich laufende Sun 1000 mit den identischen Daten für Meter zeigt mir den Meterwert an...

So, einmal die 7690 neu gestartet, Mw hat sein Meter wieder..
mysteriös….

Hat einer eine Idee?

Beste Grüße
Micha

[trucki]

Vielen Dank für die Screenshots. Ich konnte das Verhalten nachstellen und mit einer T2H/MG-Version mit etwas weniger aggressiven Timeouts beheben. Bei Interesse bitte Email an mich.

Ein “Linked” beim T2SG kann auch durch das Eintragen der IP beim T2H/MG→ZEPC→T2SG IP ausgelöst werden.

5.1s “Warten auf Serverantwort” ist definitiv zu viel lange für eine sinnvolle Regelung. Kann sein, dass die älteren Versionen da toleranter waren, aber hilfreich für eine stabile Regelung ist das sicher nicht. Keine Ahnung, ob das aus dem Netzwerkwerk oder vom Tasmota selbst kommt. Ggf. mal mit einem kürzeren SML Script testen. Eventuell lohnt sich auch die Investition in einen Shelly 3EM Pro mit LAN?

Viele Grüße,

Trucki

[suedseite]

Hallo Trucki,
vielen Dank für deine Wochenendarbeit...

Ich habe es heute Morgen mal getestet: Meine "Warten auf Serverantwort" beträgt ca. 70ms.

Trotzdem hatte ich ja gestern Probleme mit dem Aufspielen der Firmware. -http err?
Gibst dafür eine Erklärung?

Ich habe das Update von einem Mac (-mini, Wlan angebunden) ausgeführt.

Wäre deine geänderte Version etwas für mich? Ansonsten kann ich gut mit der 1.09 leben...

Ok, ich wünsche allen einen schönen Restsonntag und nächste Woche fette solare Gewinne..

Beste Grüße

Micha

[jenscz]

Ich habe wahrscheinlich einen BUG beim T2HG entdeckt.

Wenn der T2HG einen T2SG auf linked setzt, kann es passieren dass der T2HG einen Setpoint von 0 hat, also nicht lädt und trotzdem den T2SG auf linked hält. Der T2SG wird somit niemals einspeisen. Liegt wohl daran, dass der T2HG meint, er würde noch etwas (4,7W) in den Akku laden. Was er aber nicht tut. Das Setzen des Linked Mode beim T2SG sollte durch den T2HG nur erfolgen, wenn dieser auch einen Setpoint von > 0 hat.

Hier meint er aber er lädt noch mit 4,7 Watt, was er aber nicht macht.

[trucki]

@Suedseite: Http err heißt, dass das Meter nicht erreichbar war. Ich würde sagen das ist irgendwo aus dem Netzwerk gekommen. Mehr kann ich dazu nicht sagen. Ja, schreib mir doch mal eine Email!

@jenscz : Dein Ladegerät bleibt auf Standby und wechselt nicht auf OFF. Deshalb wird das T2SG in Linked gehalten. T2HG→CHG1→Standby hast Du auf großer 0 (z.B. 20s) gesetzt?

Gruß Trucki

[jenscz]

@trucki Danke, du bist der Beste, das war es. Jetzt weiss ich auch, warum der Lüfter nicht aus ging. Kann mich aber nicht erinnern Standby auf -1 gesetzt zu haben.

[trucki]

Standby = -1 ist Default. Steht aber auch (mehrmals) im Handbuch auf T2HG – trucki.de

Viele Grüße,

Trucki

[jenscz]

@Trucki: Bist du sicher, dass dein T2HG-Board (Kontakte) dauerhaft die 3000KW bei 48V (51,2) aushält? Mir kommen die Kontakte schon bei 2200W sehr warm vor. Habe leider nichts zum Messen da.

Mir scheinen die Federkontakte doch sehr filigran zu sein um dauerhaft 60A zu übertragen.