@hacki11 said in Test Adapter mhi-wfrac v2.1.x GitHub:

@mabbi Die elektrische Energie bezieht sich wohl auf den aktuellen Tag. Es handelt sich um den Wert, der in der App ganz oben auf der Detailseite steht. Wie genau der Wert ist kann ich dir nicht sagen. Ich vertraue hier lieber auf einen vorgeschalteten Hutschienenzähler.

Ok, ich habe leider keine Verbrauchsmessung auf den Leitungen, an denen die beiden Aussengeräte angeschlossen sind. Und meine Schaltschränke sind so voll, dass ich um jeden Platz auf den Hutschienen kämpfe. Mein Tigo Funk Adapter sitzt schon draussen, kein Witz:

Wenn ich auf die Eco Taste drücke, bekomme ich vom IG keinen Bestätigungston, daher gehe ich davon aus, dass dies bei dem Modell ohne Funktion ist.

Das ist bei mir anders, die Innengeräte piepen bei jedem Durchschlaten mit der HI/Eco Taste auf der Fernbedienung.
Schade, dass es damlas nicht reverse engineerd wurde, wäre halt cool gewesen

Bzgl. Blockierzeit verstehe ich, und auch, dass du andere schützen willst aber ich sehe aktuell dennoch keine Regelungslogik im Adapter. Ich glaube die anderen Klimaadapter funktionieren hier ähnlich.

Ok, verstehe ich. Und ich habe ja für mich eine Lösung schon umgesetzt, die unabhängig vom Adapter funktioniert.

Danke für Deine Antworten.

Hi,

ich habe gestern Nacht noch ein paar Fortschritte gemacht:

Heute morgen:

Akku lädt mit 2300 Watt, kann nun auch mit 2400 Watt das Haus unterstützen.
Der technisch interessierte Nutzer fragt sich nun, warum 2 unterschiedliche Werte ?

Antwort: Weil die Zendure APP beim Input nur max. 2300 W erlaubt, beim Output aber das eigentlich für beide Werte beworbene 2400 W. Ich hoffe auf ein Update.

Aktuell:

Wie man sieht, habe ich eben noch 5 Minuten in das vis investiert...

Was ich aus dem Datalog heute Nacht gelernt habe:
Das Haus hat Nachts eine durchschnittliche Grundlast von ca. 310 W.
Durch meine träges und konservatives Script war der durchschnittliche Stromverbrauch heute Nacht 49 W.
Der Akku hat mit durchschnittlich 258 W eingespeist.
Und wieder Messungenauigkeiten...sigh.
Um 7.03 Uhr heute morgen hat der Akku wegen SOC <= 9% abgeschaltet.
Seit 9:32 Uhr lädt er wieder, da hatte er aber nur noch einen SOC von 8 % ? Habe nichts am Notstrom dran, ich packe das mal unter Messtoleranzen. (to be monitored)

Script funktioniert, die Klimas/Wärmepumpen waren alle schon am Start als der Akku endlich ran durfte.
Ladeleistungsregelung scheint auch zu funktionieren, um 11:01 Uhr war der Akku voll.

Langsam werde ich zum happy camper.

fyi: Ich habe einen shelly vor dem AC 2400. Die durchschnittlichte Differenz zwischen effektiver Stromaufnahme und effektiver Stromabgabe sind bei mir so ca. 16-18%, schwankt ein bisschen.
Finde ich für einen reinen Stecker-Akku, der muss den Strom ja 2x wechselrichten, ganz OK oder ?

@schimi

Jo, ich teste seit 3 Tagen mit dem AC 2400

heute habe ich das erste 'träge' script zum Laufen gebracht, mangels ecoTracker im Versandweg einfach mal probiert, das über die cloud zu regeln.

Steuern lässt sich der AC2400 einwandfrei, die Fehlermeldungen aus der letzten release-version sind weg (Danke an @nograx, echt schnell gelöst), an 2 Stellen habe ich aber noch den Wurm drin:

Nummer 1:

Ich kann den AC2400 auf inputLimit/outputLimit jeweils auf bis zu 2400W setzen im Object/Control.
Allerdings pfuscht mir die cloud(denke ich?) da rein....nach kurzer sind die Werte wieder auf 800 begrenzt.
Und das, obwohl ich vorher in der APP die Grenzen mit Bestätigung rausgenommen habe.

Da ist aktuell unklar, warum das passiert...vor 2 Tagen konnte ich den noch problemlos auf 2400 stellen und er blieb da auch. Ich muss dass noch genauer austesten, was nun anders ist.

Ansonsten, das Script steuert den AC 2400 alle 10 Sekunden und zieht die Einspeise- respektive Ladeleistung den aktuellen Werten nach...
Ist natürlich träge und nicht genau, aber schon viel besser als mit Zeitplan zu laden und zu entladen....

Mal ein Beispiel:

Grundlast des Hauses am Abend so um die 500-550W, meine Frau bügelt (kein Witz), das Bügeleisen schaltet dauernd an und aus, Netzbezug pulst bis 3 KW hoch.
Info: In meinem script habe ich die Limits aktuell auf 2000 W gesetzt aktuell.
Man sieht im Log, wie das script den Akku ansteuert mit 2000 W Einspeisung, auf meiner vis tauchen die 2000 W auch kurz auf und werden dann nach 1-2 Sekunden auf 800 zurückgesetzt, im Protokoll kann man sehen, dass das nicht vom script kam. Da sind dann 10 Sekunden später nur noch 506W notwendig, weitere 10 Sekunden später zieht das Bügeldings wieder Saft etc.

Ansonsten ganz unten im Bild:
Komme mit dieser trägen Regelung ziemlich dicht an meinen realen Verbrauch ran, für eine cloudbasierte Steuerung deutlich besser als erwartet, das 800 W Limit ist halt noch zu knacken.

Problem 2:
... ist nur witzig, hat aber nicht wirklich mit dem Adapter zu tun.
Natürlich produziert meine Steuerung auch Einspeisung, sie regelt ja nur alle 10 Sekunden.
Dann passiert was richtig krasses...mein Sunny Home Manager Smartmeter kommt darauf nicht klar und setzt einfach mal alle Werte auf 0.
Sobald wieder Netzbezug da ist, kommen nach 2-3 Sekunden wieder brauchbare Werte.
Ich denke, das Smarty versteht nicht, dass es eine Einspeisung geben kann, wenn der Wechselrichter keinen PV-Ertrag meldet.
Ich habs erstmal rausprogrammiert und senke die Einspeisung durch den AC 2400 drastisch wenn alle Daten im Smarty 0 sind, um dann schnell wieder in den minimalen Netzbezug zu kommen, voila...Smarty liefert wieder brauchbare Werte.
Ist halt ein dirty hotfix, nicht für die Ewigkeit hoffe ich.

Noch 10 Tage bis der ecotracker kommt... dann pack ich das script als Fingerübung an die Seite und klemme den AC2400 hoffentlich nur noch im Automodus per Trackersteuerung an oder verbiete Ihm per Adapter zu Laden, wenn ich Strom für den Start meiner Klimaanlagen/Wärmepumpen brauche.

@nograx : Danke für Deine Arbeit und Unterstützung

Nachtrag: Nochmal etwas gepfeilt, da jetzt keine Großverbraucher mehr pulsen, regelt der sich schön bei 15-60 W Netzbezug ein.
Als Zielwert habe ich 50 W Netzbezg in der Berechnung angepeilt, um möglichst selten den Smarty abzuschiessen...

Hi,

ich weis noch nicht mal, ob ich etwas verstellt habe, ob es am letzten Update liegt oder der Fehler vor dem Bildschirm sitzt.

Ist wahrscheinlich eine totaler nerd bug, ich finde dazu aber nichts sinnvolles im Netz.

Im IOBroker wird meine Protokoll Datei jedesmal gelöscht/geleert, wenn ich das Protokoll öffne.
Ich sehe also in der Übersicht orange/rot die kleine Anzeige mit der Anzahl der Fehler, wenn ich dann das Protokoll öffne ist die Anzeige leer, solange das Protokoll offen ist listet er auch schön alle neuen Einträge auf.

Anzeige

click

Log das ich vorher in einem 2. Tab aufgemacht habe hat viele Zeilen, hier ist die angezeigte Warnung(ganz unten) :

Das hier macht mir etwas Kopfzerbrechen:

Die war früher deutlich grösser, ich finde hierzu aber keine Einstellung....

Frage: Warum löscht/leert der IOB die Anzeige, wenn ich den Protokoll-TAB öffne, habe ich etwas falsch eingestellt oder sehe ich den Wald vor Bäumen nicht ?

Nachtrag: Die Loggröße wird mit 0 Byte angezeigt wenn man das Protokoll öffnet.

P.S.: Das gleiche passiert auch, wenn ich auf aktualisieren in der Protokoll-Anzeige drücke.

@nograx
Den EcoTracker hatte ich geholt, weil ich die Hoffnung hatte, dichter am realen Geschehen(direkt am Zähler auslesen) zu sein und weil der Zendure ihn im Automatikmodus erkennt und unterstützt.

Das er langsamer ist als der Sunny Home Manager von SMA hätte ich auch nicht gedacht, allerdings ist der Zeitversatz minimalst und fällt bei der Steuerung des Akkus über die Cloud nicht ins Gewicht.

Wenn ich es schaffe, den Akku aus der Cloud zu puhlen nehme ich definitiv die Daten vom SMA Smartmeter zum steuern. Aber da muss ich mich erstmal schlau lesen und mit mqtt habe ich auch noch nie etwas gemacht.
Ich hatte Dich hierzu angeschreiben.

Grundsätzlich sehe ich aber einen ganz grossen Vorteil im EcoTracker.
Wenn ich per Akku ins Haus einspeise und nachts kein PV-Ertrag da ist, kommt es ja auch zu kurzen kleinen Netzeinspeisungen bevor der Akku regelt.
Hiermit kommt das Smartmeter von SMA oder mein script überhaupt nicht klar und stellt einfach alle Werte auf "0", was zur Regelung aktuell nicht taugt. Den Fehler suche ich noch, entweder ist das in meinem script irgendwo falsch oder der SMA mag einfach keine Netzeinspeisung, wenn der PV-Wechselrichter keinen Strom liefert.
Ich habe es noch nicht richtig debuggt.

In dieser Situation bekomme ich saubere Werte vom Ecotracker und benutze den bei der Einspeisung zum Regeln, beim Laden des Akkus greife ich auf den SMA zurück.

Kleines Update:

Habe nun die EcoTracker-Daten als Basis für die Akkusteuerung, immer noch träge und im 10 Sekunden Takt, schneller reagiert die Zendure cloud nicht.

Man sieht schön, wo ich mit einem Bügeleisen mal eben maximale Last abgefordert habe und wie schnell er mit dem +/- power Werten des Ecotracker nachregelt.

Wenn keine grossen Verbraucher schalten, dann pendelt er sich schön um die Nulllage ein.

Δ 5 Mins Netzbezug liegt bei 5 Watt. Nice.

Nachtrag: Ich bau mal eben eine Δ 10 Sekunden für den EcoTracker/power, dann sollte die Steuerkurve theoretisch smoother sein.

@homoran said in EcoTracker per httpGET, Werte mit Zeitversatz ?:

Woran machst du fest, dass das httpGet "Sekunden" braucht.

Wenn ich in den js code Zeitstempel mache und die logge, dann ist der httpGET echt schnell, ca. 10-15 Millisekunden.
Für mich sieht es eher so aus, als ob der Ecotracker die letzte ganze Sekunde(?) 'vermittelt' und den Datenwert schickt ?
Ist aber nur eine vage Vermutung.

@homoran

...ok...erwischt...ich bin halt ein Optimierer...Berufskrankheit

Hi,

ich habe einen Zendure AC 2400 Steckdosenakku und nun ist endlich heute mein EcoTracker angekommen.
Da der Zendure mein SMA-Smartmeter nicht erkennt habe ich den von dem Zendure unterstützten Ecotracker geholt.

Energieversorger Hotline für Zugangs-Pin zum Stromzähler -> 25 Minuten (nervig)
Taschenlampe und Stromzähler, PIN eingeben, Info freischalten -> 10 Minuten (voll nervig, leider hat mein Stromzähler keinen Taster)
EverHome App installiert, Ecotracker verbunden -> 5 Minuten (ziemlich gut und benutzerfreundlich gemacht )
Den EcoTracker zum Laufen gebracht(klacks ), aus der Cloud wieder rausgenommen und ein Skript für ein httpGet gemacht, im VIS dargestellt -> 15 Minuten

Und dann kam der Frust..... der EcoTracker hängt ca. 1-2 Sekunden hinter meinem SMA Smartmeter, dass ich mit dem Adapter sma-em auslese und die Werte in genau dem gleichen Zeitplan im 1 Sekunden Takt für die Visualisierung berechne.

Ich hatte eigentlich die Hoffnung, wenn ich direkt am Stromzähler in meinem eigenen Netzwerk per httpGet auslese, dass ich zeitlich wirklich dicht(er) am Geschehen bin.
Und gerade für die Steuerung des Akkus ist mir das wichtig, jede Sekunde zu lang Strom einspeisen bringt lausige paar Cent, jede Sekunde zu lange Strom beziehen kostet....

Bevor mich nun hate trifft...der EcoTracker ist was die Installation und die Einbindung in die EverHome Cloud betrifft wirklich gut, für mich als technischer Laie einfach zu installieren und mit 2x Google wusste ich auch wie ich den Stromzähler freischalte etc. Der Tracker selber ist quasi p&p, wenn man eine App auf seinem Handy installieren kann.
Echt gutes Konzept und durchdachte Installation. Auch die Tatsache, dass man Ihn dann cloudless betreiben kann finde ich gut. Also an alle EcoTracker Fanboys....ich mag das Teil.

Habe ich bei diesem Ansatz etwas falsch gemacht oder hat jemand eine Idee, wie ich das besser hinbekomme ?

P.S.:Der harte Weg wäre nun, den Zendure aus der cloud zu holen und dann mit den SMA Daten per MQTT zu steuern.
Ein simples script dafür (das aktuell noch die Zendure Cloud und den Adapter von @nograx nutzt) optimiere ich schon seit ein paar Tagen.

Kleines Update:

Akku Einspeisung war diese Nacht schon um 3:10 Uhr beendet (habe gestern Abend viel Strom verbraucht)
Wie geplant erfolgte die Beendung der Eispeisung bei 15% SOC.
Und wieder ist er danach abgefalllen auf 8 % runter (die Nächte davor Abschaltung bei 10%, danach runter auf 4-5%). Eigentlich ist das Verhalten von Messtoleranzen mal abgesehen identisch.

Das der SOC nicht wirklich aussagekräftig ist, das ist mir nach den letzten posts klar.
Deswegen habe ich die Spannung auch aufgezeichnet:

Kurz vor dem Beenden der Einspeisung fällt die Spannung auf unter 48 V, davor und danach ist sie konstant über 48 V.

Das gleiche bei der Zellspannung(?), die fällt beim Einspeisen von 3,51 V auf 3,21 V mit einem kurzen Einbruch zur gleichen Zeit wie bei der Akkuspannung, aber auch hier geht es gerade mal auf 3,17 V runter.

Ich bin kein Elektriker/Elektroniker, ich sehe hier einfach keine so deutlich zum Ende hin abfallende Kurve wie in dem Graphen von @Homoran ?
Das sieht eher aus wie bei @warp735, für mich als technischer Laie ist das wirklich wenig Bewegung bei den Volt-Zahlen (0,51 V bzw. 0,04 V).

Wenn der SOC als Schätzeisen nicht taugt zur akkuraten Akkusteuerung, wodran kann man sich denn sinnvoll orientieren ?

@nograx

6:43 Uhr Der AC2400 meldet schrittweise weniger SOC, diese Nacht von 14% runter auf 5 %

5:53 bis 6:38 Uhr Die Spannungen schwanken nachdem Sie über die Nacht relativ konstant waren.
Overall in der Nacht:
totalVOLT von 49,6 auf 46,3 V runter.
minVOLT von 3,28 zu 3,07 V

Sind die Schwankungen im Graphen die automatische Kalibrierung des Akkus?
Obwohl der Zeitraum mit 45 Minuten relativ lang war....

Mein Ladeschema:

Letzte Entladung des Akkus endete 6:43 Uhr, ab 7:13 hat er dann wieder geladen mit PV-Strom, zwischen 7:15 und 7:45 Uhr hat meine Frau wohl noch Heißgetränke gemacht und Energie eingefordert.

Anhand dieses Graphs würde ich die Schwankungen der Voltzahlen eher den Schaltvorgängen zur Unterstützung des Hauses zuordnen, auf unserer Ostseite stehen Bäume und die ersten Stunden schwanken die Solarerträge stark. Ausserdem hat die Ostseite nur 10 Module, das reicht aktuell bei gutem Wetter erst so ab 6:50 Uhr zur Deckung des Grundbedarfs des Hauses.

So wie es aussieht, muss ich bei einem höheren SOC aussteigen als 10% beim Einspeisen, weil die Werte des AC2400 in diesem Bereich wohl eher Schätzungen sind.
Ich werde kommende Nacht mal bei 15% aussteigen und nochmals berichten.

Hi,
ich betreibe einen Zendure Solarflow AC 2400, ein reiner Steckdosen-Akku.
Dieser lässt sich mit der letzten Entwicklungsstufe des Zendure Adapters von @nograx auch gut steuern.

INFO: Aktuell warte ich noch auf meinen EcoTracker, also scripte ich derzeit die Akkusteuerung derzeit per js über den Cloudzugang mit dem Zendure Adapter. Das script steuert Einspeisung und Laden des Akkus je nach PV-Überschuss, blockiert das Laden und speist gezielt ein, wenn ich meine Wärmepumpen/Klimas oder EV-Laden-jetzt brauche. Ansonsten unterstütz es das Haus, so das wir in der Regel Nachts einen durchschnittlichen Netzbezug von ca. 50 W (statt ca. 300W) pro Stunde haben.

Und hier habe ich jede Nacht so gegen 5 Uhr ein eigenartiges Phänomen:

• der Akku ist fast leer (SOC 14% oder niedriger)
• die Einspeisung ins Haus stoppt wie gescripted

Dann fällt der Akku innerhalb von 10 Minuten um ca. 10% SOC ab, als würde er mit 1800-2000 Watt einspeisen.

Danach ist dann alles wieder im Regelbereich und der Akku fängt etwas später mit dem ersten sinnvollen PV-Ertrag an wieder zu Laden.

FRAGE:
Wo ist der Strom(aka SOC) hin, er ist nirgendwo im System protokolliert.
Man kann in der Grafik sehen, wie die Einspeisung um 4:51 Uhr endet
Weder in der Einspeisung noch im Netzbezug bzw. im Hausverbrauch sieht man die Entladung des Akkus zwischen 4:51 Uhr und 5:01 Uhr.

Komisch ist auch, das vor 4:51 Uhr,so ab 3:30 Uhr, der SOC viel langsamer fällt als erwartet, obwohl die Logs (nicht im Bild) einen relativ konstanten Stromverbrauch Nachts im Haus von 310 W/h zeigen und der Akku brav konstante 250-260 W/h davon schiebt.

Man kann sogar sehen, dass der letzte im Haus so gegen 0:20 Uhr schlafen gegangen ist, davor war der Stromverbrauch (und somit der SOC-Abbau) noch etwas steiler.

INFO: Das script steigt eigentlich schon bei einem SOC <= 9% aus der Einspeisung aus.
Vermutung: Ich bekomme eventuell morgens zwischen 3:00 Uhr und 5:00 Uhr nicht die korrekten SOC Werte aus der cloud ?

Hat jemand eine Idee, die dieses Verhalten erklärt ?
Ich sehe dass jede Nacht ziemlich zur gleichen Zeit in den Logs.

Ich bin da derzeit etwas ratlos...danke für Eure Hilfe vorab.

greets...m

Hi,

ich habe gestern Nacht noch ein paar Fortschritte gemacht:

Heute morgen:

Akku lädt mit 2300 Watt, kann nun auch mit 2400 Watt das Haus unterstützen.
Der technisch interessierte Nutzer fragt sich nun, warum 2 unterschiedliche Werte ?

Antwort: Weil die Zendure APP beim Input nur max. 2300 W erlaubt, beim Output aber das eigentlich für beide Werte beworbene 2400 W. Ich hoffe auf ein Update.

Aktuell:

Wie man sieht, habe ich eben noch 5 Minuten in das vis investiert...

Was ich aus dem Datalog heute Nacht gelernt habe:
Das Haus hat Nachts eine durchschnittliche Grundlast von ca. 310 W.
Durch meine träges und konservatives Script war der durchschnittliche Stromverbrauch heute Nacht 49 W.
Der Akku hat mit durchschnittlich 258 W eingespeist.
Und wieder Messungenauigkeiten...sigh.
Um 7.03 Uhr heute morgen hat der Akku wegen SOC <= 9% abgeschaltet.
Seit 9:32 Uhr lädt er wieder, da hatte er aber nur noch einen SOC von 8 % ? Habe nichts am Notstrom dran, ich packe das mal unter Messtoleranzen. (to be monitored)

Script funktioniert, die Klimas/Wärmepumpen waren alle schon am Start als der Akku endlich ran durfte.
Ladeleistungsregelung scheint auch zu funktionieren, um 11:01 Uhr war der Akku voll.

Langsam werde ich zum happy camper.

fyi: Ich habe einen shelly vor dem AC 2400. Die durchschnittlichte Differenz zwischen effektiver Stromaufnahme und effektiver Stromabgabe sind bei mir so ca. 16-18%, schwankt ein bisschen.
Finde ich für einen reinen Stecker-Akku, der muss den Strom ja 2x wechselrichten, ganz OK oder ?