MatzeTF

Auf Seite 7 (PDF-Seite 8) wurde das Foto der DIP-Schalter etwas verkleinert, um die fast leere Seite 10 zu beseitigen. Da der Inhalt – bis auf die Größe des Fotos – identisch geblieben ist, hat das Dokument keine neue Version bekommen. Das Datum auf der Webseite ist da zugegebenermaßen etwas verwirrend, da es sich um das Datum handelt, wann das Dokument hochgeladen wurde.

Die Firmware deiner Wallbox ist über ein Jahr alt. Seitdem wurden einige Probleme bereits beseitigt. Bitte aktualisiere deine Firmware (unter System → Firmware-Aktualisierung) und melde dich wieder, falls das Problem weiterhin auftritt.

Der WARP Energy Manager (WEM) kann aktuell nur einen Speicher steuern. Es ist geplant, dass zukünftig auch mehr als ein Speicher gesteuert werden können soll. Aktuell ist geplant, dass auf alle Speicher die gleichen Regeln angewendet werden. Entweder werden alle Speicher gleich gesteuert, oder wenn z.B. eine Regel bei < 20 % SoC greift und ein Speicher bei 10 % und einer bei 30 % ist, würde nur einer blockiert. Das steht aber noch nicht fest. Das lässt sich nur mit einer zentralen Regelung umsetzen. Zwei eigenständige Speicherregelungen (mit gleichem Regelintervall) werden immer gegeneinander arbeiten, sofern nicht immer ein Speicher komplett blockiert wird. Eine Speicherregelung ist für den WEM nicht geplant.

Was ist unter Energiemanagement → PV-Überschussladen beim Standardlademodus ausgewählt? Wenn da Min+PV ausgewählt ist, wird nach dem Abstecken immer zurück in Min+PV gewechselt. Wenn du das nicht möchtest, ändere das mal auf „Unverändert“. Ab dem nächsten Firmware-Release wird „Unverändert“ auch der Normalfall, da die Einstellung oft zu Verwirrung führt. Ansonsten ist dein Debug-Report leider zu spät runtergeladen worden. Die detaillierten Ladeinformationen reichen nur ca. 45 Minuten in die Vergangenheit und somit war der Ladevorgang von gestern Abend heute morgen nicht mehr verfügbar. Im groben Protokoll sieht es allerdings so aus, als wäre gestern Abend das Auto noch während der Willkommensladung wieder abgesteckt worden. Du lässt dich nicht zufällig gerade von den drei Minuten Willkommensladung verwirren? Im PV-Modus wird auch ohne PV-Überschuss drei Minuten lang geladen, um dein Auto davon abzuhalten, über Nacht einzuschlafen und morgens nicht mehr geweckt werden zu können.

Bitte lade einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

Ja, einerseits den und andererseits den, der nach dem Abstecken des Autos gewählt wird. Du kannst temporär während eines Ladevorgangs den Modus wechseln, aber nach dem Abstecken wird wieder auf den permanenten Modus gewechselt.

Steht in beiden Fällen der Status auf Ladebereit? Falls ja, sollte das Auto die beiden Fälle eigentlich nicht unterscheiden können. Du hast nicht zufällig in EVCC die Autodaten per Cloudzugang des Herstellers eingetragen?

Falls du die MQTT-API meinst, findest du den Endpunkt für den persistenten Lademodus hier. Die API zum temporären Wechseln des Lademodus ist noch nicht dokumentiert. Du kannst die gleichen Modi wie in der obigen API hierhin senden, wobei die letzte Nummer die Nummer der Wallbox ist, falls du mehrere hast. ...Präfix.../charge_manager/charge_modes_update/0Falls du wissen wolltest, wie du dir das im HA baust, gibt es genug Anleitungen online. Frag die Suchmaschine deines geringsten Misstrauens.

Welchen Ladestatus zeigt das Webinterface der Wallbox an, nachdem du den Knopf am Auto gedrückt hast? Ich vermute, dass der Status dann auf „Ladebereit“ wechselt, was bedeutet, dass die Wallbox Strom freigibt, das Auto aber keinen haben will, obwohl es weiterhin signalisiert, verbunden zu sein. Wenn du den Knopf an der Wallbox drückst, gibt die Wallbox keinen Strom mehr frei, was das Auto wahrscheinlich dazu veranlasst, den Stecker zu entriegeln. Das Gleiche trifft auch zu, wenn gerade kein PV-Strom verfügbar ist; dann gibt die Wallbox auch gerade keinen Strom frei. Das Entriegeln des Steckers kann die Wallbox also nicht steuern, das macht das Auto. Warum es also den Stecker nicht entriegelt, wenn du den Knopf während einer Ladung drückst, musst du den Autohersteller fragen. Alle Autos, die wir bisher getestet haben, haben damit kein Problem.

Du erwähntest in deinem ersten Post einen Batteriespeicher, allerdings ist der bei der Wallbox nicht konfiguriert. Die Wallbox hat nur den Netzbezugszähler. Wenn es einen Batteriespeicher gibt, denn die Wallbox nicht kennt, arbeiten beide gegeneinander. Diesen Fall triffst du hier. Wenn dein Batteriespeicher auf der Liste der kompatiblen Geräte steht, richte ihn bei der Wallbox entsprechend ein.

Die API für den Lademodus ist auch über MQTT erreichbar. Demnächst™ gibt es irgendwann ein Update für mehr automatisch verfügbare Sensoren und Aktionen. Ich weiß allerdings gerade nicht, ob der Lademodus da mit drin sein wird. Aktuell musst du dir das so oder so selber bauen.

Man kann ja rotieren… Erwarte vormittags keine Antworten von mir. 😉 Hast du den Hinweis zur $14a-Option gesehen? Den hatte ich gerade eben noch in meinen vorigen Post editiert.

Die Signalquelle ist EEBUS. Die Kommunikation zwischen WEM und Wallbox erfolgt nicht über EEBUS. Steuerbox ↔ EEBUS ↔ WEM ↔ WARP-Lastmanagement ↔ Wallbox Du musst allerdings im obigen Screenshot die Option für die kontrollierten Wallboxen aktivieren, damit das funktioniert.

Hast du schon wokelnschauflers Tipp ausprobiert? Unter Schnittstellen → Modbus/TCP den Keba-Modus aktivieren und dann bei FENECON eine Keba-Wallbox hinzufügen.

Was genau möchtest du damit erreichen? Der WEM steuert Wallboxen nicht über EEBUS, sondern nur über das WARP-Lastmanagement. Wenn ich das richtig sehe, ist die Wallbox bereits im Lastmanagement eingetragen.

Wie viel ist „über 6A“? Mehr so 7A oder 16A? Starte mal eine Ladung im PV-Modus und wenn dein Auto nach ein paar Minuten immer noch nicht so schnell lädt, wie du es erwartest, lade einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

Was heißt „deaktiviert“? Hast du die Sicherung vom Speicher rausgeworfen?

Das Sichtfenster ist nur für die noch nicht verfügbare Eichrechts-Variante relevant, da es dort vorgeschrieben ist, dass der Zähler von außen ablesbar sein muss. Bei der MID-geeichten Pro-Variante ist das Fenster nur vorhanden, damit sich niemand beschwert, den Zähler nicht ablesen zu können. Im Gehäuse ist nämlich nicht genug Platz, um den Zähler so einzubauen, dass man ihn bei abgenommener Frontplatte ablesen könnte. Außer, dass du den Zähler nicht direkt ablesen kannst, hat das keine anderen Konsequenzen für dich.

In nicht luftdichten Verteilerdosen sammelt sich doch auch kein Kondenswasser, oder? Ansonsten: Vielleicht tut’s auch eine Ladung Fugensilikon aus dem Baumarkt, wenn man nichts anderes hat. 🤷

Laut Debug-Report hast du eine Pro. Anscheinend fehlt einfach nur das Fenster, sodass du den Zähler nicht direkt ablesen kannst und die Werte nur im Webinterface der Wallbox siehst. Ist das für dich okay? Ich leite das mal an die Mitarbeiter in der Produktion weiter, damit deine Wallbox ein Einzelstück bleibt. 😉

Lade bitte einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

Für die Wallbox gibt es bei den Downloads eine Bohrschablone mit Maßen.

Dann weiß ich leider auch nicht, wo das Problem liegen könnte.

Die Einstellungen sehen erstmal korrekt aus. Kannst du mal mit mosquitto_sub nachsehen, ob unter warp3/2i5B/# Nachrichten reinkommen und ob unter homeassistant/# irgendwas mit 2i5B im Namen steht?

20 A ist richtig für ein 2,5 mm²-Kabel. Die Beschriftung auf der Platine ist falsch; da hätten 20A und 32A stehen sollen.