MatzeTF

Wenn du per MQTT auf die API schreiben möchtest, musst du üblicherweise "_update" anhängen. Wenn du bei der API-Dokumentation oben rechts auf „MQTT“ stellst, wird der Teil des Pfades zur Erinnerung auch fettgedruckt angezeigt. Ansonsten scheint niemand außer dir den Watchdog zu benutzen. Es hat sich nämlich noch niemand beschwert, dass der inzwischen gar nicht mehr funktioniert, selbst wenn man die API korrekt benutzt. 🙈 Bitte installiere mal diese Firmware. Damit sollte der Watchdog wieder korrekt funktionieren. Ohne ladendes Fahrzeug wirst du das noch nicht bemerken, aber schon mal vorweg: Wenn du den Strom über die API setzt oder der Watchdog auslöst, dauert bis zu zehn Sekunden, bis das Lastmanagement den neuen Stromwert übernimmt. Das ist kein Bug und kein Anlass zur Sorge. 😉 Ohne ladendes Fahrzeug wirst du die Änderung auch nicht in evse/slots sehen. Der dort enthaltene Wert des Lastmanagements ändert sich nur mit einem angeschlossenem Fahrzeug. Wenn du sehen willst, welchen "available_current" das Lastmanagement gerade verarbeitet hat, kannst du Energiemanagement → Lastmanagement → Details ausklappen und dort bei den Limits nachsehen. Edit: Veraltete Firmware entfernt.

Der EM 2.0 kann bereits bei der GX-Serie die Batterie auslesen. Sag bitte Bescheid, falls das nicht funktioniert, und hänge einen Debug-Report vom EM an.

Über die API kann man das Limit neu starten, also genau das, was du willst. Ich bin mir aber gerade nicht sicher, ob es dafür keine Schaltfläche in der Web-Oberfläche gibt oder ich sie nicht finde. Auch wenn es etwas umständlich ist, kannst du zumindest über einen direkten Aufruf von http://warp2-abc/charge_limits/restart im Browser das Limit neu starten. Es wird dann nur eine leere Seite ohne irgendeine Meldung angezeigt. Das heißt dann, dass alles ok ist.

Anscheinend hast du versehentlich oder fälschlicherweise die Zählerüberwachung aktiviert. Die überprüft bei einer WARP Pro, ob der interne Zähler vorhanden und funktionsfähig ist. Bei einer WARP Smart ist die Überwachung standardmäßig aus, da sie ja keinen Zähler hat. Geh mal zu Wallbox → Einstellungen und deaktiviere die Zählerüberwachung.

Danke, aber ein langes Wochenende haben wir diesmal nicht. Wir machen nur nach Möglichkeit nie Freitags-Releases, weil wir dann zwei Tage lang nicht auf mögliche Bugs im Release reagieren können.

Wahrscheinlich machen wir das Release erst Montag. Wenn du dich bis dahin nicht gemeldet hast, gehen wir davon aus, dass erstmal alles ok ist.

Danke für das Angebot. Wenn es was zum Testen gibt, werden wir hier eine Beta-Firmware posten oder dich mit weiteren Fragen löchern. Ansonsten kannst du uns gerade nur helfen, wenn du zufällig C++-Programmierer bist und die Wallbox-Firmware selber hacken möchtest. 😉

Kostal nimmt es mit der Sunspec-Konformität an mehreren Stellen nicht so genau. Praktisch alle anderen Geräte, die Kostal-Geräte per Sunspec abfragen, haben sich auf die Fehler in Kostal-Geräten eingestellt und erwarten die jetzt auch. Ich vermute, dass sie deswegen auch das Update zurückgezogen haben: Die erwarteten Fehler waren auf einmal nicht mehr da und die Abfragen funktionierten nicht mehr. Ich vermute, dass sie dabei auch irgendwas anderes geändert haben, was wir aktuell so nicht erwarten. Ich fürchte, das müssen wir uns ansehen und du kannst da aktuell nichts machen, außer vielleicht über Kostal zu schimpfen.

Auf unserer Todo-Liste steht, dass das Lastmanagement gesprächiger werden soll. Aus der Anzeige soll dann klar werden, dass die Wallbox wegen nicht angeschlossenem Fahrzeug blockiert ist.

Die Option für die externe Steuerung gibt es nicht mehr, da die externe Steuerung jetzt immer aktiv ist. Wenn du evcc am Laufen hast, setzt das den Wert für die externe Steuerung. Du kannst das zwar zurücksetzen, aber nach wenigen Sekunden wird es wieder durch evcc blockiert. Warum evcc gerade bei dir blockieren will, weiß ich nicht. Stell doch einfach mal den Lademodus in evcc auf „Schnell“, dann sollte eigentlich zeitnah eine Ladung freigegeben werden.

Danke für dein Durchhaltevermögen. 😉 Jetzt sollte es aber wirklich funktionieren. Edit: Veraltete Firmware entfernt.

Da können wir leider nichts machen. Die Wallbox macht das, was das Fahrzeug verlangt. Wenn es nur darum geht, wann du deinen WR abregelst und wann nicht, musst du wohl diese kurzen angeblichen Ladephasen rausfiltern und erst ab einer Ladedauer über einer Minute von einem tatsächlichen Ladevorgang ausgehen. Wie eine konkrete Implementierung zum Abfragen des Fahrzugzustands aussehen würde, kann ich noch nicht sagen, aber spontan fallen mir dazu zwei Zustände ein: Das Fahrzeug wird angeschlossen und einmal abgefragt. Lädt es dann nicht, wird sich der SOC nicht relevant von alleine ändern und es brauch nicht permanent abgefragt zu werden. Dementsprechend wird die Ladeelektronik nicht immer wieder aufgeweckt. Das Fahrzeug lädt und wird regelmäßig abgefragt. In diesem Fall ist die Ladeelektronik sowieso aktiv. Wir haben schon Gerüchte gehört von Fahrzeugen, die sich an einer einfachen AC-Wallbox leerstehen, weil die 12 V-Boardbatterie permanent durch die ineffiziente Ladeelektronik geleert wird, selbst wenn der Ladevorgang beendet wurde, weil die Traktionsbatterie voll ist. In dem Fall war das Fahrzeug Schuld und nicht die Wallbox, aber sowas wollen wir unseren Kunden definitiv nicht verursacht durch unsere Wallboxen zumuten.

Speedwire sorgt immer wieder dafür, dass mir bestimmt nicht langweilig wird. 🤪 Schaue ich mir nächste Woche an. Übrigens brauchst du die Meldung vom Auto nicht zu posten, wenn die Wallbox keinen Strom freigibt. Die Auto-Meldungen brauchen wir nur, wenn die Wallbox Strom freigibt, das Auto aber trotzdem nicht laden will.

DC-Ladesäulen sprechen ISO 15118 mit dem Fahrzeug, was eine recht aufwändige digitale Kommunikationsschnittstelle ist. Darüber wird auch der SOC ausgetauscht. AC-Wallboxen sprechen IEC 62196 Mode 3 mit dem Fahrzeug, was eine recht einfache Signalisierung ist, über die kein SOC ausgetauscht werden kann. Wir arbeiten an einer ISO 15118-Unterstützung für unsere Wallboxen und testen, wie gut man darüber im AC-Lademodus den SOC auslesen kann. Genaueres kann ich dazu aktuell allerdings noch nicht sagen.

In deinem Fall hängt das sogar komplett vom Fahrzeug ab. Kannst du in deiner Grafik auch Balken mit drei Zuständen plotten? Falls ja, bau da doch mal den Zustand „ladebereit“ mit ein. Im Log ist zu sehen, dass die Wallbox häufig zwischen „ladebereit“ und „lädt“ wechselt. „Ladebereit“ bedeutet, dass die Wallbox dem Fahrzeug signalisiert, dass Strom freigegeben ist. „Lädt“ heißt, dass das Fahrzeug dann auch Strom angefordert hat. Die Wallbox hat also fast den ganzen Tag Strom freigegeben, aber das Fahrzeug wollte mal welchen haben und man nicht. Sofern du jetzt nicht einen seltsamen Wackelkontakt oder Dreck im Stecker hast, wüsste ich nicht, was man da seitens der Wallbox machen könnte. Wenn du mitbekommst, dass sich der Ladezustand wieder alle paar Sekunden ändert, nimm mal ein Ladeprotokoll auf (unter Wallbox → Ladestatus → Ladeprotokoll) und hänge es hier an. Zwischen Start und Stopp sollten mindestens ein Übergang zu „lädt“ und ein Übergang zurück zu „ladebereit“ liegen. Wenn dich die technischen Details der Signalisierung zwischen Fahrzeug und Wallbox interessieren, kannst du dir den entsprechenden Absatz auf Wikipedia durchlesen.

Die Datenblätter beider Geräte findest du bei den Downloads auf warp-charger.com. Ansonsten habe ich die Frage in Kürze auch schon hier beantwortet. Die einzigen zusätzliche Features vom v1.0 sind die Phasenumschaltung für WARP2 und die RGB-Statusanzeige statt Display mit RG-LED.

Zwischen Version 1.0 und 2.0 hat sich fast die gesamte Hardware geändert. Da ist es nicht mit etwas Lötarbeit getan. Der Energy Manager wird auch immer nur komplett getestet, sodass man die Komponenten einzeln bestenfalls ungetestet und ohne Garantie bekommen könnte.

Wie fragst du eigentlich die Temperatur vom Temperature Bricklet ab? tf_temperature_v2_get_temperature oder tf_temperature_v2_get_chip_temperature? Ansonsten fällt mir gerade auf, dass du ja sagtest, dass PTC und Temperature Bricklet ungefähr die gleiche Temperatur messen. An welcher Stelle misst der PTC?

Ja, das ist ein bekanntes Problem. Der Zeitpunkt wird relativ zur Systemzeit der Wallbox angegeben, aber angezeigt relativ zur Systemzeit des PCs oder Smartphones, auf dem die Seite geöffnet ist. Dementsprechend muss der Wert jede Sekunde aktualisiert werden, wobei es zu Rundungsfehlern kommen kann.

Danke für den Hinweis. Die Aktion wurde tatsächlich nicht korrekt aktiviert. Bitte teste mal diese Firmware. Mit fiel dabei auch auf, dass im Tutorial die zweite notwendige Regel fehlte, die die §14a-Beschränkung wieder aufhebt. Die steht nun auch mit drin. Edit: Veraltete Firmware entfernt.

Ja, genau das meinte ich. Ja, bitte lade einen Debug-Report runter und hänge ihn hier an. Der EM muss dabei in dem Zustand ein, dass „Deaktiviert“ angezeigt wird und PV-Überschussladen und dynamisches Lastmanagement aus sind.

Hm, ich sehe jetzt das Problem. Da hier fast alle Fragen von Leuten mit PV-Überschussladen oder dynamischem Lastmanagement kommen, hatte ich nicht bedacht, dass du möglicherweise nur den reinen §14a-Modus nutzen willst. Es reicht, wenn du eine Regel mit der Aktion „Begrenze maximalen Gesamtstrom“ anlegst und natürlich die Wallbox(en?) im Lastmanagement eingetragen hast. Nach einem Neustart verschwindet dann das „Deaktiviert“, da dann der §14a-Modus aktiv ist. PV-Überschussladen und dynamisches Lastmanagement müssen dafür nicht aktiviert werden. Bitte schalte PV-Überschussladen und dynamisches Lastmanagement ab und sieh nach, ob nach einem Neustart „Deaktiviert“ hinter der Aktion steht oder nicht.

Die Option ist üblicherweise dann deaktiviert, wenn PV-Überschussladen und Dynamisches Lastmanagement auch deaktiviert sind. Das bezieht sich auf das Gerät, das du gerade konfigurierst. Wenn du PV-Überschussladen auf dem EM aktiviert hast, sollte die Option dort nutzbar sein. Die Wallbox, die vom EM gesteuert wird, hat selbst PV-Überschussladen aus. Dementsprechend ist dort die Option deaktiviert. Hast du auf dem EM eins von beidem aktiviert aber die Option wird trotzdem als deaktiviert angezeigt, lade bitte einen Debug-Report runter (unter System → Ereignisprotokoll) und hänge ihn hier an.

Es war vier Minuten lang ununterbrochen weniger Überschuss verfügbar, als für dreiphasiges Laden mit Minimalstrom benötigt wird. Dementsprechend hat die Wallbox korrekt auf einphasig geschaltet. Wenige Sekunden später stand dann mehr Leistung zur Verfügung und dreiphasiges Laden wäre knapp möglich gewesen, aber das kann die Wallbox leider nicht vorhersagen. Bei wechselnd bewölktem Wetter wird es immer derartige suboptimale Umschaltvorgänge geben. Selbst die Wolkenfilteroption „stark“ wird das nicht verhindern können, nur seltener machen. Schließlich kann eine Wolke auch genau acht Minuten und eine Sekunde lang deine PV-Anlage verschatten. Das Log wurde zu spät runtergeladen und enthält den fraglichen Zeitraum nicht mehr. Dementsprechend weiß ich auch nicht, ob und wann da Phasenumschaltungen waren. Ich kann nur sehen, dass das Auto ab 16:47:40 keinen Strom mehr angefordert hat, obwohl die Wallbox welchen freigegeben hat.

Die vorige Testfirmware hatte bereits anstehende Änderungen für Netzwerkverbindungen mit drin, die anscheinend Probleme mit Speedwire verursachen können. Bitte teste mal diese Firmware. Das ist 2.8.2 plus die Netzwerk-Änderungen plus eine Verbesserung für Speedwire. Falls der SHM 2.0 damit nicht funktioniert, kannst du wieder auf die reguläre Version 2.8.2 wechseln, in der die Netzwerk-Änderungen nicht enthalten sind. Edit: Veraltete Firmware entfernt.