Ich tue sowas normalerweise nicht, aber hier dann doch....

Ich habe bei dem Ersteller dieses threads vor gar nicht all zu langer Zeit eine kostenpflichtige support-Dienstleistung bestellt.

Wir haben dann zusammen 1,5 - 2 h an dem Problem gearbeitet und konnten es aber leider nicht lösen.

Entgegen meiner Erwartung und auch Erfahrung im Support Bereich wollte Matthias KEINE Bezahlung, hat also seine Zeit geopfert und wollte nur bei der Lösung des Problems auch bezahlt werden. Und das hat er auch so ehrlich und offen kommuniziert, seine Enttäuschung nicht helfen zu können hat den kommerziellen Aspekt (und ich hatte es ja aktiv gebucht) völlig überschattet.

Auch wenn wir das Problem bei mir nicht gemeinsam lösen konnten, war er in meinen Augen fachlich versiert, freundlich und hilfsbereit.

Abschliessend.... ich denke Matthias hätte in seinem Starterpost mehr Informationen zum Wesenskern seines Projekts machen sollen. Ich denke aber auch, das er einer der 'guten' ist, mich hat seine selbstlose Hilfedienstleistung beeindruckt.
Deswegen dieser post.

Just my 2 cents.

P.S.: Habe per PP freiwillig gespendet. Ich hoffe es war angemessen.

@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...

@karacho

Der Ecotracker IR Stromzähler Aufsatz wird von Zendure unterstützt und geht mit Zendure + Akkus gut im Automatikmodus über die cloud.
Man kann den Ecotracker zusätzlich per httpGet auslesen im IOBroker und die Daten per script nutzen.

power ist der aktuelle Netzbezug (positives Vorzeichen) oder Einspeisung (negatives Vorzeichen) in Watt.

Über MQTT kann ich meinen AC 2400 nicht steuern aktuell, da ich ihn nicht aus der cloud gelöst bekomme. Das wäre halt die coole Lösung in Verbindung mit dem Ecotracker IR.

@michi-0
Folgendes kann ich berichten:

• Ich bekomme keinen 'Partneraccount' in der aktuellen Zendure App zum Laufen.

Unterm Strich:
Ich kann in der APP zwischen 2 Accounts hin und herschalten, muss aber jedesmal den AC2400 genau auf den Account verbinden und er ist dann im alternativen Account nicht mehr vorhanden -> sinnlos
Fazit: Ich kann entweder die App oder den Adapter mit aktiver Instanz nutzen, nicht beides.

Ich nutze die beta Version (last release im Git) und die funktioniert zur Überwachung gut.
Aktuell, bekomme ich trotz tatkräftiger Unterstützung von @maxclaudi den AC2400 NICHT aus der cloud gepuhlt. Habe dazu auch schon mit @nograx kommuniziert, wir haben einen Lösungsansatz aus terminlichen Gründen erstmal vertagt.

Ich habe mir ein simples script zur Überwachung des AC2400 in mein vis eingebaut, der AC2400 läuft auf Automatikmodus und ist noch mit der cloud verbunden und nutzt die Daten eines EcoTracker IR zum regeln. Das funktioniert erstaunlich gut.
Meine scripte berücksichtigen aber auch Bedürfnisse des Energiemanagements im Haus, was der Automatikmodus des Akkus logischerweise nicht kann. So werden die Klimageräte unnötig lang aktiv gehalten und der Akku läuft dann irgendwann Nachts leer. Natürlich kann ich das alles reinprogrammieren in die Steuerung der jeweiligen Einzelgeräte, aber ich habe schon ein zentrales EMS und würde halt gerne den Akku da mit einbinden anstelle an vielen Stellen Sonderfunktionen zus. einzuprogrammieren, die erkennen, ob der Akku entlädt und die derzeitige Menge an PV-Strom nicht für einen längeren Betrieb reicht weil eh bald Sonnenuntergang ist etc.

Jetzt am Abend sieht das so aus:

Oben ist meine errechnete Netz-Einspeisung (Daten von Wechselrichtern und zug. Smartmeter), ganz unten der EcoTracker IR zur Kontrolle.

Eigentlich geht das alles schon ganz gut....

Akku war schon vor Mitternacht leer (ist derzeit nur ein BX3000 zum Testen und habe gestern Abend lange im Büro gearbeitet), morgens hat sich der Akku den PV-Überschuss geholt, weil es zu warm zum Heizen und zu kalt zum Kühlen des Hauses war, gegen 11 Uhr kamen die Klimas alle kühlend hinzu, aber nur für gut 1 Stunde, dann war das Temperaturfenster schon wieder ausserhalb des Regelbereichs, ich bin gegen 15 Uhr aufgeschlagen nach einer Dienstfahrt, das Energiemanagment hat mit Hilfe des Akkus das 3-phasige Laden des EV ermöglicht bis ca. 19 Uhr trotz echt schlechter PV-Erträge heute, da war dann meine bessere Hälfte auch hier und hat sowohl die Klimas als auch die Ladesäule (99% im Auto...grrr) mit Küchenaktivitäten gecancelt, eben sind die Klimas noch mal kurz angesprungen nach dem Kochen und kühlen aktuell vor allem das Obergeschoss. Der Akku hat sich auch wieder gefüllt mit dem restlichen PV-Strom, ich schätze mal das in ca. 1 Stunde nicht mehr genug PV da ist und dann die Klimas wieder aus gehen. Irgendwann heute im Laufe des Tages hat auch duie Spülmaschine Ihr Startsignal bekommen, ich denke grob da wo meine 11 KW Ladesäule maxed out war.... kann ich am Graph nicht wirklich sehen, aber sie ist definitiv gelaufen heute.

Wie man sieht regelt der Automatikmodus des Akkus manchmal nicht schnell genug, es gint ein paar Verbrauchs Peaks, hier reden wir aber über echt wenig realen Energiebezug. Am Abend haben die 2300 W max. Akku-Entladung die ich derzeit nutze nicht mit PV zusammen Ladesäule, Herd und Klimas deckeln können, deswegen sind 2 der 3 Verbraucher abgeschaltet worden. Ich würde nie wagen, meiner Frau beim Kochen den Strom zu mopsen...

Das Ansteuern des AC2400 per script über den Adapter mit Hilfe der cloud ist mir aber zu träge.

Wie gesagt, eigentlich bin ich mit der Steuerung sehr zufrieden, gerne hätte ich den AC2400 aber nicht in der cloud sondern direkt per script/mqtt gesteuert. Alle Skripte zum selber steuern sind schon da und ich bin kein wirklicher Fan von Geräten die permanent nach Hause telefonieren.

Nachtrag @michi-0 die 2.: Falls Du den AC2400 sauber aus der cloud bekommst und per mqtt steuern kannt, dann würde mich die Vorgehensweise sehr interessieren. Sei so nett und schreib mir dann eine PM ok ?

@karacho

Der Ecotracker IR Stromzähler Aufsatz wird von Zendure unterstützt und geht mit Zendure + Akkus gut im Automatikmodus über die cloud.
Man kann den Ecotracker zusätzlich per httpGet auslesen im IOBroker und die Daten per script nutzen.

power ist der aktuelle Netzbezug (positives Vorzeichen) oder Einspeisung (negatives Vorzeichen) in Watt.

Über MQTT kann ich meinen AC 2400 nicht steuern aktuell, da ich ihn nicht aus der cloud gelöst bekomme. Das wäre halt die coole Lösung in Verbindung mit dem Ecotracker IR.

Ich tue sowas normalerweise nicht, aber hier dann doch....

Ich habe bei dem Ersteller dieses threads vor gar nicht all zu langer Zeit eine kostenpflichtige support-Dienstleistung bestellt.

Wir haben dann zusammen 1,5 - 2 h an dem Problem gearbeitet und konnten es aber leider nicht lösen.

Entgegen meiner Erwartung und auch Erfahrung im Support Bereich wollte Matthias KEINE Bezahlung, hat also seine Zeit geopfert und wollte nur bei der Lösung des Problems auch bezahlt werden. Und das hat er auch so ehrlich und offen kommuniziert, seine Enttäuschung nicht helfen zu können hat den kommerziellen Aspekt (und ich hatte es ja aktiv gebucht) völlig überschattet.

Auch wenn wir das Problem bei mir nicht gemeinsam lösen konnten, war er in meinen Augen fachlich versiert, freundlich und hilfsbereit.

Abschliessend.... ich denke Matthias hätte in seinem Starterpost mehr Informationen zum Wesenskern seines Projekts machen sollen. Ich denke aber auch, das er einer der 'guten' ist, mich hat seine selbstlose Hilfedienstleistung beeindruckt.
Deswegen dieser post.

Just my 2 cents.

P.S.: Habe per PP freiwillig gespendet. Ich hoffe es war angemessen.

@rtwl Darf ich mal fragen, was das für ein device ist.
Ich habe ähnliche Probleme mit einem modbus-fähigen device und der Hersteller hat mir schon overtheair updates zugesagt, defakto ändert sich aber bis dato nichts am Verhalten. Falls Du es hier nicht öffentlich sagen willst, schreib mir bitte ein Chatnachricht. Danke.

Sieht sehr ähnlich aus wie bei Dir würde ich sagen:

Hi,

sorry für meine späte Rückmeldung.
ich habe auf der Suche nach den fehlenden Protokollen meinen Debian-Server bzw. IOB-Docker gegrillt und letzte Woche 3 Nächte gebraucht bis alles wieder passabel lief.
Zum Glück hatte ich eine sehr aktuelle Datensicherung und mit externer Hilfe meines Linux-Spezies (Danke J für Deine selbstlose Hilfe bis spät in die Nacht nach dem schon eh extrem langen Arbeitstag) auch auf dem docker den Fehler eingegrenzt und dann manuell im .json behoben.

Erstaunlicherweise ist nach der Korrektur nun auch wieder das Protokoll da und ich habe eine sinnvolle Log-filesize.

user/appdata/iobroker/data/iobroker-data/iobroker.json

Hier waren einige andere log-Typen eingetragen (ja...ich habe rumgeclickt im admin/hosts) und habe damit meinen Docker einfach mal rasiert.
Der iob starte zwar noch, aber der Start dauerte locker 5 Minuten, dann konnte man mit Glück noch irgendwo draufclicken (wieder lange Pause) und probieren etwas zu verändern, meistens war der IOB an dieser Stelle aber schon wieder frozen/abgestürzt.
Und der Docker blockiert ja leider die ganzen mini hacks wie fix, restore etc.
Für mich ist schonmal klar, einfach wegen des Zugangs fliegt der docker demnächst weg und ich mach eine VM mit einem iob auf dem Server auf.

Abschliessend:
Danke für Eure Tipps
Warum nun das Protokoll nach der Rettung meiner geschrotteten iob Version nun wieder funktional ist kann ich leider auch nicht sagen.
Ich habe am Ende nur mein letzten save in einen neuen Docker zurückgespielt und dort die .json manuell editiert.
Dann lief er. Dann habe ich das gleiche in meiner Produktiv-Umgebung gemacht und der lief dann auch wieder.
Waren 3 ziemlich uncoole Nächte....
Habe dann noch 3 Tage Ostsee drangehängt(wenn jemand den Molli kennt...ich bin zum 1. mal in meinem Leben mit einer Dampflock gefahren...cool) ...nun ist alles wieder im Lot.

@nograx said in Test Adapter Zendure Solarflow:

Es scheint als würde Zendure mit Start des Solarflow 2400 AC und Solarflow 800 das Teilen einzelner Geräte nicht mehr zu unterstützen.

Das kann ich bestätigen, in der App kann man das Energiesystem(? kann grade nicht gucken) immer nur genau einem Satz Anmeldedaten zuordnen. Sobald man mit dem 2. Account in der App ist und das Gerät zuweist ist es im 1. Account weg.

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.