MatzeTF

Das Abfrageintervall der WARP ist eine Sekunde. Das längstmögliche Update-Intervall ist zwei Sekunden. Wenn du deinen Huawei maximal alle 30 Sekunden abfragen kannst, ist der als Datenquelle für die Warp nicht geeignet. Solltest du versuchen, irgendwie 30 Sekunden lang den gleichen alten Wert als neu vorzutäuschen, wird das auch nicht funktionieren. Du kannst versuchen, deinen Modbus Proxy zum Laufen zu bringen, aber wenn der auch nichts anderes macht, als 30 Sekunden lang den selben Wert auszuliefern, kannst du dir die Mühe auch sparen. In welcher Konstellation bekommst du alle zwei Sekunden Fehler? Ist das beim direkten Zugriff auf den Huawei? Da die Daten im Sekundentakt angefragt werden, würde das bedeuten, dass die Werte alle zwei Sekunden geliefert werden und dazwischen immer ein Fehler liegt. Wenn du dir die Huawei-Linie im Graphen mit den Leistungsdaten ansiehst, ist sie größtenteils durchgängig mit vielleicht gelegentlichen kleinen Unterbrechungen oder hast du viele oder gar große Lücken?

Hast du die PT100 testweise mal direkt an den Bricklets angeschlossen? Werden sie da erkannt? Ansonsten sollten bei vieradriger Beschaltung 30 m Kabellänge kein Problem sein. Falls du Probleme mit der Kabellänge hast, hätte ich noch diese beiden Alternativvorschläge für dich: Wenn die PTC Bricklets an einem Master Brick angeschlossen sind, kannst du die RS485 Master Extension nutzen. Du schließt einen Master mit Extension an deinen PC an und die PTC Bricklets schließt du an einen weiteren Master mit Extension an und platzierst den Stapel dann nah an den PTCs. Wenn die PTCs weit auseinander liegen, kannst du auch mehrere Master mit Extension verteilen. Zwischen den Extensions kannst du dann einen RS485-Bus legen und alle PTC Bricklets so benutzen, als wären sie direkt an deinen PC angeschlossen. Alternativ kannst du die PTC Bricklets auch an einen ESP32 (Ethernet) Brick anschließen und den bei den PTCs platzieren. Von deinem PC aus verbindest du dich dann nicht mit dem lokalen Brick Daemon, sondern mit dem ESP32 Brick. Dafür muss bei den PTCs aber eine Netzwerkverbindung möglich sein, entweder LAN oder WLAN.

Ein nachträglicher Debug-Report hilft uns leider nicht. Der Report muss in dem Moment, in dem der Fehlerzustand besteht, runtergeladen werden, damit die entsprechenden Zustandsinformationen drin sind. Nächstes Mal bitte als Dateianhang anhängen und nicht komplett reinkopieren. Das ist so sehr unübersichtlich.

Das hört sich erstmal unerwartet an, da die selbe Logik Updates ans Webinterface und über MQTT schickt. Um das genauer einzugrenzen, brauchen wir einen Debug-Report vom Fehlerfall. Wenn das Problem wieder auftritt, also das Webinterface verbunden meldet, MQTT aber nicht, bitte einen Debug-Report von der Ereignisprotokollseite runterladen und hier anhängen. Möglichst auch zusätzlich die aktuellen MQTT-Daten, in denen zu sehen ist, dass MQTT „nicht verbunden“ meldet.

Die Bohrschablone mit eingezeichneten Befestigungslöchern und Zuleitungen findest du hier. Die Zuleitung ist von unten oder von hinten möglich. Bei Zuleitung von hinten werden die unten eingezeichneten Kabeldurchführungen rausgeschraubt und stattdessen von hinten eingeschraubt. Die Löcher hinten haben im Auslieferungszustand Blindstopfen, die dann stattdessen unten reinkommen.

Das siehst du genau richtig. Im Moment sind das deine Optionen. Der Energy Manager bekommt aber in hoffentlich nicht allzu ferner Zukunft ein Update, mit dem er von außen gesteuert die Phasenumschaltung für eine Wallbox durchführen kann. Du könntest dann einen zweiten Energy Manager für die Phasenumschaltung in die Unterverteilung der Wallbox setzen und die Steuerung übernimmt dein bereits vorhandener Energy Manager. Das ist wahrscheinlich die einfachste Lösung, wenn auch nicht die günstigste. Eine günstigere Variante wäre den SDM-Stromzähler durch einen Stromzähler mit Netzwerkanschluss zu ersetzen, wie z. B. einen Shelly Pro 3EM, und den Energy Manager in die Unterverteilung der Wallbox zu versetzen und per Netzwerk mit dem Stromzähler zu verbinden.

Wenn wir in Zukunft OCPP 2.0 unterstützen, wird das wahrscheinlich auch für die älteren Wallboxen nachgelegt (kann ich aber nicht versprechen), aber anscheinend hast du für OCPP 2.0 selbst ja gar keinen konkreten Anwendungsfall. ISO15118 unterstützen die WARP Charger aktuell noch nicht und für bestehende Wallboxen kann das auch nicht per Softwareupdate nachgelegt werden, da dafür zusätzliche Hardware nötig ist. Die zusätzliche Hardware ist auch der Grund, warum wir das noch nicht anbieten, da sie aktuell nur für einen unrealistisch hohen Preis zu haben ist. Wir sind aber auch sehr an dem Thema interessiert und wollen ISO15118 integrieren, sobald wir eine Möglichkeit finden, das für einen akzeptablen Preis zu machen.

Wenn du den Betreff nicht selbst editieren darfst, kann ich das machen. Allerdings ist das in unserem Forum unüblich.

Die 0 steht für 10^0, also ein Skalierfaktor von 1. Das passt zum falschen Wert. Ich hoffe, du hast Verständnis dafür, dass wir nicht allen Bugs anderer Hersteller hinterherlaufen können, insbesondere wenn es sich um ein eher kosmetisches Problem handelt. Wir haben aktuell eine Anfrage bei einem anderen Hersteller am laufen, dessen SunSpec-Daten noch viel schlimmer verbuggt sind, und das entwickelt sich zum reinsten Zeitgrab. Da du selbst das KOSTAL-Gerät im Einsatz hast, kannst du dich an KOSTAL wenden und ihnen deine Erkenntnisse von den selbst ausgelesenen Registern mitteilen, damit sie nicht versuchen, die Schuld auf uns abzuwälzen. Hast du ansonsten schon mal nach einem Firmware-Update für den KOSTAL-Zähler geschaut? Ich glaube es zwar nicht, aber vielleicht ist das Problem schon repariert?

Die Software von WARP 1 bis 3 unterscheidet sich fast nur aufgrund der verbauten Hardware. Wenn man nur die reine Software-Funktionalität betrachtet, fallen mir gerade diese beiden Unterschiede ein: WARP 2/3 unterstützen OCPP, WARP 1 nicht. Vielleicht kommt das irgendwann noch, vielleicht auch nicht. WARP 2/3 unterstützen 32 Benutzer, 32 NFC-Tags und 32 Wallboxen im Lastmanagement, die WARP 1 jeweils nur 10. Das Problem ist in beiden Fällen, wie mattsches schon sagte, der viel kleinere Arbeitsspeicher der WARP 1. OCPP könnten wir inzwischen vielleicht noch reinbekommen, aber wahrscheinlich wartet da niemand drauf, weil es bisher bei allen WARP 1 Nutzern auch ohne ging. @mattsches Tut mir Leid, dass du unter unseren häufigen Umbauten leidest. Die API nach außen ist uns fast schon heilig, aber intern reißen wir öfter was um, wenn sich herausstellt, dass wieder irgendwas aktualisiert oder aufgeräumt werden muss. Wahrscheinlich fällt dir insbesondere der leider notwendige Preact-Umbau im Frontend auf die Füße. Mit dem angehängten Patch compiliert zumindest das Phase Switcher Backend-Modul wieder. Ob es auch funktioniert, weiß ich natürlich nicht. 😉 Die notwendigen Änderungen im Frontend habe ich leider nicht im Kopf, um das gerade für dich zu machen. phase_switcher.patch

Ich weiß nicht, wie das SMA-System funktioniert, aber man wird auf irgendeine Weise damit kommunizieren müssen, wozu eine SMA-spezifische Lösung notwendig ist. Mit einem herstellerübergreifenden Standard wäre das einfacher, aber aktuell haben wir leider keine Sonderlösungen für verschiedene herstellerspezifische Systeme. Das mit den Wandlerverlusten habe ich schon öfters gehört, kann es aber nicht recht nachvollziehen. Wenn ich 10 kWh in mein Auto lade und 5 % Wandlerverluste habe, verliere ich 0,5 kWh. Beziehe ich den Strom dafür aus einem Batteriespeicher, der auch 5 % Wandlerverluste habe, verliere ich insgesamt 1 kWh. Dann ist vielleicht die Batterie leer und mein Haus bezieht in der Nacht Strom aus dem Netz ohne Wandlerverluste. Lade ich stattdessen das Auto aus dem Netz, habe ich dort nur 0,5 kWh Verlust. Allerdings bezieht mein Haus dann in der Nacht 10 kWh aus der Batterie und dabei entstehen 0,5 kWh Verlust, also unterm Strich auch insgesamt 1 kWh, nur zu anderen Zeiten. Ich sehe da keinen Unterschied. Vielmehr sehe ich den Nachteil, dass mein Haus den Speicher vielleicht gar nicht komplett leert und ich Strom fürs Auto gekauft habe und dafür einen Teil der Energie ungenutzt im Speicher gelassen habe, der dann am nächsten Tag nicht mal mit voller Kapazität geladen werden kann. Die Batteriezyklen schont es wahrscheinlich schon, aber noch mehr schont es die Batteriezyklen, wenn man die Batterie nie verwendet. Allerdings ist sie dann auch nutzlos. 😉 Die Batterie amortisiert sich ja nur, wenn man sie tatsächlich nutzt. Da ich auch keinen dynamischen Stromtarif habe, nehme ich daher nie Rücksicht auf die Batterie und lade bei Bedarf das Auto damit. Dann ist sie am nächsten Morgen auch schön leer, damit wieder viel PV-Energie reinpasst. Wenn ich mein Auto mittags bei schlechtem Wetter laden muss, kann am Nachmittag die Batterie sogar ein zweites Mal am Tag geladen werden und der Speicher hat mir dann sogar doppelt geholfen. Mit einem dynamischen Stromtarif sieht das natürlich anders aus. Da ist es sinnvoller, das Auto möglichst mit billigem Netzstrom zu laden und das Haus in Zeiten mit teurem Netzstrom aus der Batterie zu versorgen.

Nein, die WARP3 kann aktuell keine Batteriespeicher ansteuern. Leider gibt es auch keinen Standard bzw. irgendeine herstellerunabhängige Lösung dafür, sodass diese Funktion auch nicht ganz einfach wäre. Hast du eigentlich einen Stromtarif mit dynamischen Preisen? Falls nicht, ist es im Allgemeinen sinnvoller, das Auto aus dem Batteriespeicher zu laden statt Netzstrom zu kaufen.

Wenn du die Position von einem neueren Arduino berechnen lassen und an ein Bricklet weitergeben lassen möchtest, empfehle ich dir das RS232 Bricklet 2.0, damit du die Daten digital übertragen kannst. Bei einem 3,3 V Arduino kannst du die Pins direkt verbinden, bei einem 5 V Arduino brauchst du einen Widerstand. Das klappt allerdings nicht mit alten Arduinos, die nur eine serielle Schnittstelle haben, die fest mit dem USB-Port verbunden ist.

Wir haben hier ein KOSTAL Smart Energy Meter im Einsatz. Das verwendet auch das SunSpec Model 203 und zeigt Energiebezug und -einspeisung korrekt an, dementsprechend ist is kein Problem auf Wallboxseite. Bei KOSTAL haben nicht nur wir sondern auch andere Anbieter festgestellt, dass sie es mit der SunSpec-Spezifikation nicht so genau nehmen. Beispielsweise sind alle Energiewerte, die laut Spezifikation vorzeichenlos sein sollten, bei allen KOSTAL-Geräten vorzeichenbehaftet. Es würde mich nicht wundern, wenn die Energiewerte, die laut Spezifikation in Wattstunden angegeben werden sollen, beim PLENTICORE einfach mal als Kilowattstunden ausgegeben werden und somit um den Faktor 1000 zu klein sind. Wenn du weißt, wie du bei deinem Router eine Portweiterleitung für den Modbus-Port deines Wechselrichters anlegst, kannst du das mal machen und mir vormittags deine IP des Tages™ per privater Nachricht schicken. Dann kann ich mir mal die Rohwerte deines Wechselrichters ansehen. Ich vermute ganz stark, dass die einfach falsch sind.

Die Warp3 spricht Modbus TCP (also über Ethernet) und SunSpec (per Modbus TCP). SolarEdge Wechselrichter sollten alle SunSpec unterstützen und somit ohne Aufwand auslesbar sein. Steht SunSpec nicht zur Verfügung, kann man Modbus TCP händisch eintragen und die gewünschten Werte eintragen. Von anderen SolarEdge-Kunden haben wir das Feedback bekommen, dass SunSpec oft erst aktiviert werden muss und das mangeln Einstellmöglichkeiten für Kunden nur von SolarEdge selbst aktiviert werden kann und dafür ein Anfrage beim SolarEdge-Support gestellt werden muss. Sollte SunSpec nicht verfügbar sein, obwohl die Werte per Modbus TCP lesbar sind, kannst du dich auch nochmal melden und wir erstellen eine Modbus TCP-Vorlage dafür, die du dann einfach auswählen kannst, statt dich selbst durch die Modbus-Spezifikation von SolarEdge zu kämpfen. Da nicht jeder Wechselrichter-Hersteller SunSpec anbietet, haben wir das schon für ein paar andere Hersteller gemacht. Sobald der Wechselrichter in der Wallbox eingetragen ist, funktioniert PV-Überschussladen automatisch.

Die Gehäusetiefe ist weniger das Problem. Eine Ladedose passt in die Frontplatte, allerdings muss dahinter dann Platz bis zur Gehäuserückseite sein, was aktuell einfach nicht der Fall ist. Wir haben übrigens schon WARP Charger mit 10m Kabel oder Teslaknopf gebaut, indem sich die Kunden die Kabel selbst gekauft und uns zugeschickt haben. Die Kollegen in der Fertigung haben die dann einfach statt der Standardkabel angeschlossen.

in der aktuellen Version kann den Energy Manager mit einem eigenen Schütz die Phasenumschaltung für eine WARP2 durchführen, da die das nicht selber kann. Eine WARP3 kann die Phasenumschaltung selbst durchführen, allerdings kann der Energy Manager das noch nicht ansteuern. Daran arbeiten wir noch. In Firmware 2.6.0 erwartet die WARP3 entsprechende Phaseninformationen, die der Energy Manager nicht sendet, weshalb sie im einphasigen Modus hängen bleibt. In Firmware 2.5.0 erwartet die WARP3 keine Phaseninformationen per Fremdsteuerung, weshalb du sie unabhängig von Hand umschalten kannst. Die Konfigurationsversion 2.5.0 ist richtig, da sich diese Versionsnummer nur bei relevanten Konfigurationsänderungen erhöht. Die Firmware 2.6.0 bringt neue Funktionen mit, ändert aber nichts an der bestehenden Konfiguration, weshalb deren Versionsnummer bei 2.5.0 bleibt. Die vorige Konfiguration war übrigens 2.2.0. Zwischen 2.2.0 und 2.5.0 gab es auch keine Änderungen.

Wenn du dir einen WARP3 Charger anschließen lässt und der Elektroinstallateur die Installation nach Anleitung durchführt, ist die Wallbox sofort betriebsbereit. Stecker ins Auto und los geht’s mit 11 kW. Wenn du die Leistung der Wallbox begrenzen willst und sie noch keine Netzwerkverbindung hat, kannst du dich per Laptop oder Smartphone mit dem WLAN der Wallbox verbinden und einfach über das Webinterface den Ladestrom auf einen beliebigen Ampere-Wert zwischen 6 A und 16 A einstellen. Hat sie bereits eine Netzwerkverbindung, ist das Webinterface natürlich auch darüber erreichbar und du musst dich nicht erst mit dem Wallbox-WLAN verbinden. Wenn du keine Zeit hast, dich umfangreich mit PV-Überschussladen zu beschäftigen, kann der WARP3 Charger das wahrscheinlich einfach für dich übernehmen, sofern er eine Netzwerkverbindung hat und darüber den SolarEdge-Wechselrichter mit dem Hausanschlusszähler erreichen kann. Dann kannst du den Zähler einfach in der Wallbox eintragen und PV-Überschussladen aktivieren. Phasenumschaltung (1- oder 3-phasig) funktioniert dann auch gleich automatisch. Für die Netzwerkverbindung empfehlen wir ein LAN-Kabel, aber notfalls tut’s auch WLAN, wenn der Empfang gut genug ist. Mindestausstattung für deine Anforderungen: einfach nur ein WARP3 Charger. Meine Empfehlung: WARP3 Charger mit LAN-Kabel.

Das Ladekabel kann bei WARP Chargern problemlos getauscht werden. Das Einziehen des Kabels ist zugegebenermaßen etwas fummelig, aber alle entsprechenden Anschlüsse in der Wallbox sind gut erreichbare Schraub- oder Klemmverbindungen. Falls du selbst nicht die nötige Qualifikation hast, kann prinzipiell jede Elektrofachkraft das Kabel tauschen. Stichwort Reparierbarkeit: Nicht nur das Kabel, sondern auch alle anderen Komponenten der WARP Charger lassen sich einzeln tauschen. Falls die Reparatur nicht bei uns durchgeführt werden soll, können alle Teile auch einzeln über unseren Shop nachbestellt werden. Stromlaufpläne zur Verkabelung der Komponenten sind frei verfügbar. Hier im Forum haben einige Nutzer sogar ihre alten WARP Charger mit Ersatzteilen der neueren Generationen aufgerüstet und haben jetzt vollwertige Wallboxen der neuesten Generation und dabei nur minimal Elektroschrott produziert. Den EU-Plänen zu Reparierbarkeit und Nachhaltigkeit sind wir damit weit voraus. 😉

Die Wallbox schickt alle MQTT-Nachrichten mit gesetztem „retain“-Flag raus, was bedeutet, dass der MQTT-Server sie vorhalten soll. Startet der MQTT-Consumer neu, bekommt er direkt nach dem Verbindungsaufbau und Subscribe auf die Topics die jeweils letzte Nachricht auf dem jeweiligen Topic geschickt. Machst du erst ein Subscribe auf die value_ids und dann ein Subcribe auf die values, bekommst du erst die value_ids und dann die values zugeschickt, ganz unabhängig von einem Neustart der Wallbox oder des Consumers. Das funktioniert auch bei einem Neustart des MQTT-Servers, selbst wenn der die Nachrichten mit „retain“-Flag über einen Neustart vergisst, da sich die Wallbox neu mit dem MQTT-Server verbinden muss und dann wieder zuerst die value_ids rausschickt.

Wirf mal einen Blick in die API-Dokumentation.

.../meter/values ist die veraltete API, die aktuell noch zur Rückwärtskompatibilität mit aktualisiert wird, in Zukunft aber irgendwann entfernt werden kann. Das ist auch so. value_ids wird aktualisiert, bevor Werte auf values rausgehen. Die Anzahl und Reihenfolge der Werte in values bleibt so lange unverändert, bis ein Update per value_ids rausgeht. Anschließend entsprechen Anzahl und Reihenfolge der Werte den neuen value_ids. In der Praxis wirst du allerdings nur Änderungen von einer leeren Liste zu Werten bekommen und wieder zurück zur leeren Liste, wenn die Wallbox neugestartet wird und sie ihren Zähler noch nicht initialisiert hat. Dass sich Anzahl oder Reihenfolge ändern, ohne den Umweg über die leere Liste zu nehmen, gibt es aktuell nicht. Anzahl und Reihenfolge der Werte sind auch über Neustarts hinweg konstant und können sich nur durch ein Firmware-Update ändern. Wir lesen bei uns auch die Werte für verschiedene Aufgaben aus und das Pattern ist immer so, dass auf Updates von value_ids gelauscht wird und der Datensatz dann festlegt, wie folgende Updates auf values interpretiert werden. Alles andere wäre in der Praxis auch einfach unbrauchbar. Falls du ein Python-Freund bist, hier ein Beispiel aus einem meiner Datenlogger, der die drei Phasenströme sammelt: def cb_mqtt_grid_value_ids(client, userdata, msg): global grid_current_values_length global grid_current_value_indices grid_current_value_indices = 3 * [None] grid_currents_found = 0 value_ids = json.loads(msg.payload) for idx, value_id in enumerate(value_ids): if value_id == 13: grid_current_value_indices[0] = idx grid_currents_found += 1 elif value_id == 17: grid_current_value_indices[1] = idx grid_currents_found += 1 elif value_id == 21: grid_current_value_indices[2] = idx grid_currents_found += 1 if grid_currents_found != 3: print("Received value ID data doesn't contain phase currents", file=sys.stderr) return grid_current_values_length = len(value_ids) print(f"Grid phase currents' value IDs found", file=sys.stderr) def cb_mqtt_grid_values(client, userdata, msg): global grid_current_values_length global grid_current_value_indices global grid_currents values = json.loads(msg.payload) if len(values) != grid_current_values_length: print(f"Values length mismatch for grid: expected {grid_current_values_length}, got {len(values)}", file=sys.stderr) return for i in range(len(grid_current_value_indices)): current_index = grid_current_value_indices[i] if current_index == None: print("Received values but don't know grid's phase current value index yet", file=sys.stderr) return grid_currents[i] = values[current_index] Die Phasenströme haben die Value IDs 13, 17 und 21. Wenn ein Update auf value_ids reinkommt, werden die Indizes in grid_current_value_indices gespeichert. Wenn dann ein Update auf values reinkommt, werden die Werte an den Stellen der grid_current_value_indices ausgelesen. Zur Sicherheit wird auch die Anzahl der Value IDs gespeichert und mit der Anzahl der Werte in values verglichen.

Genau wie cwen schon sagte, haben wir einfach nicht genug Platz in der Wallbox. Die abgebildete ABL-Wallbox ist grob geschätzt anderthalb bis doppelt so groß. Eine Typ 2-Steckdose neben der Wallbox ist prinzipiell möglich, allerdings ist dann das Problem, dass die Wallbox den Stecker nicht verriegeln kann und es somit möglich ist, den Stecker während eines Ladevorganges unter Strom rauszuziehen.

Dazu kommt noch, dass die Warp Wallboxen eine Erdungsprüfung für TT- und TN-Systeme haben, die eine nicht angeschlossene Erdung erkennen soll. Das funktioniert aber nur, weil ein TT- oder TN-Netz an irgendeinem Punkt geerdet ist, was bei einem IT-System nicht der Fall ist. Selbst wenn du ein 400V-Drehstromnetz mit Neutralleiter hast, an dem du eine Warp anschließen kannst, würde sie wegen angeblich nicht angeschlossener Erdung eine Ladung verweigern.

Der e-Corsa mit dem einphasigen Lader nimmt die Ladeleistung der Wallbox nur sehr langsam an, was bei starken Änderungen des PV-Überschusses immer zu starkem Überschwingen führt. Ich vermute, dass der dreiphasige Lader sich ähnlich verhält. Installier mal die Firmware 2.6.0 mit dem neuen Lastmanagement. Damit sollte das Überschwingen zumindest schwächer sein.