universal-dilettant

Das war es. Danke dir. War ein Überbleibsel aus der Zeit, als ich versucht habe, nur mit der WARP3 und deren Lastmanager zu laden (v2.6.0 und v2.6.1). Hatte mir leider 2x die Hausbatterie leergezogen, weswegen ich jetzt dabei bin, auf evcc umzusteigen. Die Beta, die ihr letzte Woche rausgebracht habt und die die Hausbatterie schonen soll, werde ich dann nicht mehr testen, wenn evcc zufriedenstellend läuft ;-).

Und die zugehörigen Files (evcc.yaml anonymisiert, of course). Danke dir. evcc.yaml warp3-2bB4-Debug-Report-2024-10-09T16-53-58-481.txt

Ich stehe vor dem selben Problem. evcc 0.130.13 läuft als Docker Container, die Warp3 hat 2.6.1 Egal, was ich mache (und so langsam bin ich mit meinem Latein am Ende): es wird keine automatische Phasenumschaltung in evcc angezeigt: - evcc.db gelöscht - evcc.yaml mit oder ohne phases: 0 - Container gestartet, gestoppt. - usw. In einem anderen Thread kam der Hinweis, dass man non-persistant volumes des Containers löschen möge (docker volume prune), hat auch nix gebracht. Falls sonst noch Jemand eine Idee hat, her damit. Danke.

@exponential Etwas off-topic, aber wie hast du das genau gemacht? Ich habe hier das gleiche Problem... Danke

Ich habe das jetzt in node-red mit 2 Flows und paar Zeilen Javascript gelöst. mqtt Output fehlt noch. Erzeuge damit ein neues Topic... Vielleicht hilft es dem einen oder anderen. Funktion: find index for ... for (let i= 0; i<msg.payload.length; i++) { if ( msg.payload[i] == 209 ) { global.set('warp_energy_index', i) } } return null; Funktion: get value of ... var i= null; if ( (i= global.get("warp_energy_index")) != null) { var newMsg = { payload: msg.payload[i] }; return newMsg; } return null;

Danke für die Links. Ich verstehe auch deine Argumente. Erlaube mir trotzdem einen Hinweis: neben der semantischen Abhängigkeit gibt es auch eine temporale Kontextabhängigkeit in der MQTT API. Du unterstellst, dass der mqtt Consumer Prozess (egal ob telegraf oder ein Python Script) ständig läuft. Insbesondere, dass er vor dem letzten Reset der WB bereits gestartet wurde und selbst keinen Restart benötigt (warum auch immer der Restart notwendig wurde: sei es, weil sich eine Konfiguration geändert hat, sei es, weil der Rechner, auf dem er läuft gebootet wurde, sei es ...). Würde also bedeuten, dass nach einem Neustart des mqtt Consumers auch die WB neu gestartet werden muss, damit sie zuverlässig die value_ids produziert. Das ist in meiner kleinen Umgebung sicherlich irgendwie leistbar - und verschmerzbar, wenn ich es vergessen würde. In einer größeren produktiven Umgebung würde ich sowas als kritsich ansehen. [Oder habe ich dich falsch verstanden???] Ich habe mich nicht mit der Architektur der WB Software befasst und kenne die Abhängigkeiten nicht. Eine Möglichkeit, breaking changes zu mitigieren wäre jedoch sicherlich, den meters output (und ggf. anderen) konfigurierbar zu machen. Man taggt in der WEB UI diejenigen Felder, die man gerne im Output hätte, und es werden die entsprechenden mqtt messages, die für sich eineindeutig sind, generiert. Meinethalben auch noch mit einem Intervall, so dass nicht jede Sekunde, sondern nur alle x sec dieser zusätzliche Output erzeugt wird. Und wenn du es richtig geil machen willst, machst du auch die Namen der topics konfigurierbar :-) Davon unabhängig ist es zwar ehrenwert, die alte HW weiter voll zu unterstützen. Irgendwann werdet ihr euch jedoch davon trennen müssen, eben weil die Funktionalitäten und Features mit jeder Version wachsen und dann nicht mehr in die veraltete HW passen.

Das lässt sich doch bestimmt mit einem #IFDEF WARP3 schon zur Compiletime lösen, oder auch dynamisch während der Laufzeit?

Soviel zu semantischer Abhängigkeit 😁 Was spräche dagegen, die Werte so warp3/2bB4/meters/value = {"1":243.999, "2":244.888, "3":236.777, "4":0, "209":5.39, "211":0.0} , gerne auch zusätzlich, auszugeben?

Ich sehe gerade, dass unter dem topic .../meter/values eine "energy_rel" und eine "energy_abs" existiert. Würde mir das weiterhelfen?

Hallo, ich stehe vor der Aufgabe, die über die WB geladenen kWh in eine InfluxDB zu importieren (so wie ich das mit vielen anderen Daten der PV etc. bereits mache). Dazu nutze ich die Influx-Komponente telegraf, die auch JSON parsen kann. Spannend sind für mich die IDs 209 und 211, die die Absolut-kWh seit Produktion speichern. Die Schwierigkeit, die ich habe: telegraf arbeitet mqtt topic by topic; um an die Werte der oa IDs zu kommen, müsste ich aber 2 topics (value_ids und values )in ein Array speichern und dann daraus die Importzeilen für InfluxDB generieren. Die würden etwa so aussehen: measurement,topic=…/meters/0/209 value=5.39 measurement,topic=…/meters/0/211 value=0 Da fehlt mir aber schlicht die Erfahrung, wie man das in telegraf angehen könnte. Hat das schonmal Jemand gemacht und kann mir evtl. einen Ausschnitt aus seiner Konfig geben? Anmerkung: wenn die beiden topics value_ids und values in einem kombiniert wären, etwa so warp3/2bB4/meters/0/1 = 243.999 ... warp3/2bB4/meters/value/209 = 5.39 oder auch so warp3/2bB4/meters/value = {"1":243.999, "2":244.888, "3":236.777, "4":0, "209":5.39, "211":0.0} dann wäre die Aufgabe trivial und die Werte konsistent. (So wie es heute ist, müsste ich mich ja 100% drauf verlassen, dass beide topics hintereinander kommen?!) Danke und Gruß PS: cross-post im InfluxData Forum

Erste Rückmeldung: heute war ein sonniger Tag, um 11:00 war der Hausakku voll und es gab solaren Überschuss. Der Corsa war an die WB angeschlossen und die WB auf PV / 32A / einphasig eingestellt. Und siehe da, er begann zu laden und ist mit einem anfänglichen Über- und Unterschwinger sehr schön der solaren Kurve gefolgt. Zwischendrin, als die 7,2kW erreicht wurden, habe ich auf 3-phasig umgeschaltet. Auch das war ohne Probleme, bis der Fahrzeugakku voll war. Keine Ahnung, was gestern nicht funktioniert hat - vielleicht hat mir die Geduld gefehlt. Ich werde es demnächst nochmal mit 3-phasig als Startzustand probieren und berichten.

Ich werde das nochmals genau versuchen, nachzustellen und zu dokumentieren. Mit „Beschränkung rausnehmen“ meine ich „Lademodus schnell“. Deswegen auch die Frage nach dem Vorzeichen. Da der Zähler Bezug und Einspeisung vertauscht, könnte es ja auch sein, dass er beim Vorzeichen Unfug verzapft. Oder es ist was anders: Wallbox neu, Auto neu, wo zuerst hingreifen? Ist ja schonmal ein guter Hinweis, dass „Ladebereit“ heißt, dass das Auto nichts abnimmt (SoC war bei 30%). Weiss Jemand, wie lange der Corsa getrennt sein muss, bevor er mit dem Laden wieder beginnt? (grasping at straws) Oder simuliert die Warp das?

Welches Vorzeichen müsste denn die Überschusseinspeisung im Zähler haben? Positiv oder negativ? Der Ladevorgang läuft nämlich bei PV oder auch bei min+PV nicht los, Status ist ladebereit. Erst wenn ich alle Beschränkungen rausnehme, fängt das Fahrzeuig (ein Corsa E von 01/2022 mit 11kW OBC) an zu laden. Dann je nach Einstellung ein- oder 3-phasig und er folgt auch den manuelle Amperevorgaben zwischen 6 und 16A.

Cross-Posting zu dem enhancement request in github. Gruß PS: wenn ihr cross-postings kritisch gegenübersteht, löscht einfach den Beitrag.

Wie die Überschrift schon sagt: ich suche nach einer Referenz zur Bedeutung des Arrays mit den value_ids des meters/0 (WARP Charger). Die IDs 1,2,3 konnte ich mir erschließen, das sind anscheinend die Spannungen der Phasen L1-3. In der SunSpec Doc bin ich erstmal nicht fündig geworden - oder ich habe falsch gesucht. Hintergrund: ich möchte identifizierte Werte nach InfluxDB schieben, zB die Temperaturen, aber auch die "Verbrauchswerte" der Wallbox und vermute diese in dem meters/0/values array. Danke und Gruß