alestrix

vor 27 Minuten schrieb kmfrank:

festgestellt das die WARP nur auf einer bestimmten Phase startet.

Einphasiges Laden geschieht immer über den L1 Kontakt des Typ 2 Steckers: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Ladebereiche

Der Kontakt ist wiederum mit genau einer Phase Deiner Hausinstallation verbunden.

Was den Ethernet-Blitzschutz angeht, hab ich das bei mir hinterm DSL Modem eingebaut, d.h. es trennt das Modem, das direkt am APL hängt, von der restlichen LAN-Installation wie Router, Switche, etc.:

https://www.omg.de/ubiquiti-networks/ethernet-surge-protector/ubiquiti-ethernet-surge-protector/a-13479

Ob's was bringt, kann ich mangels Notwendigkeit nicht sagen (und bin ehrlich gesagt auch nicht scharf drauf 😉).

vor 15 Stunden schrieb kmfrank:

Möchte eine 32A Sicherung auf Phase 1 einbauen und die Sicherungen Phase 2 und 3 ausschalten. Die WARP stelle ich auf 22kW um.

Ich bin kein Elektriker, aber meines Wissens müssen bei 3-phasigen Verbrauchern die Sicherungsautomaten der drei Phasen gekoppelt sein. D.h. wenn eine fliegt, müssen die anderen auch unterbrechen.

Ich würde eher Phasen 2 & 3 per zusätzlichem Lasttrennschalter oder Schütz zu- und wegschalten.

Wenn ich mal ein bisschen träumen dürfte wären das meine Weihnachtswünsche:

- Es wird in der Firmware ein Relais-Bricklet als weitere Möglichkeit der CP-Trennung unterstützt (für die WARP1 Besitzer)

- Die CP-Trennung wird über die API zugänglich gemacht

Eine entsprechende Steuersoftware vorausgesetzt, könnten damit all jene, die sich schon früh eine WARP gekauft und einen Schütz im Schaltschrank haben, ebenfalls eine 1p3p Umschaltung nutzen.

vor 1 Stunde schrieb dg3fbl:

Dort wird bei der Umschaltung geprüft (per MQTT) ob gerade ein Ladevorgang läuft. Wenn ja, wird dieser gestoppt, dann umgeschaltet, und dann geht das Laden weiter. Das nutze ich jetzt seit über zwei Monaten ohne irgendwelche Probleme. Das Auto ziehe ich bei der Umschaltung nicht ab, klappt zumindest hier bei mir ohne Probleme

Darf ich fragen, welches Fahrzeug Du hast? Angeblich soll z.B. die Zoe auf so etwas recht empfindlich reagieren (daher mein Kommentar zur CP Trennung).

Aus dem Firmware v2 Changelog:

> Repariert, dass Passphrase bei Verbindung zu anderem Access Point mit selber SSID nicht verlangt wird

Bedeutet das, dass ein Roaming zu einem anderen AP des selben Netzes (Site mit mehreren APs und Controller) nur noch mit erneuerter Eingabe des Passworts möglich ist?

EDIT: Bevor die Fragen kommen, ob ich eine mobile Wallbox betreibe :-) - nein, es geht darum, dass die Wallbox über einen anderen AP in Reichweite verbunden bleibt, wenn der erste aufgrund von Konfigurationsänderungen oder Firmware-Updates über einen kurzen (oder manchmal auch nicht so kurzen) Zeitraum nicht erreichbar ist. 

vor 22 Stunden schrieb whisky2k2:

Wenn ich die Ausführung für 22KW wähle, könnte ich auch zwischen "bis zu 20A einphasig" und "16A dreiphasig" wählen?

Ich habe die WARP 1 Smart und kann genau diese Fälle (per externem Schütz) abbilden. Die Logik, wann man umschalten darf, wird aber natürlich nicht von der WARP selbst abgedeckt. Ob und wie der Energy Manager das über einen (Fremd)Schütz übernehmen kann, weiß ich nicht.

Ich nehme mal an, dass die WARP 2 einen API Endpunkt für die CP Trennung anbieten wird. Wobei Du bei einer "kleinen PV Anlage" wahrscheinlich gar keine 1p3p Umschaltung während des Ladens benötigen wirst.

Am 25.3.2022 um 15:32 schrieb Witto:

Heißt das, die MEGA bekommt gar nicht mit, ob die WARP 2 Smart OCPP kann? Ich könnte die also anschließen und im Verlauf des Jahres mit nem Update und OCPP bin ich dann ja fein raus.

Je nachdem, was sie sich alles zur Anmeldung vorlegen lassen, bekommen sie das schon mit. Ich würde auch nicht empfehlen, dem Netzbetreiber etwas vorzulügen, da zieht man im Konfliktfall nur den Kürzeren. Aber vielleicht lassen sie sich ja darauf ein, dass OCPP vorhanden sein wird, sobald sie ihr Zugangsgateway (oder wie auch immer man das dann nennt) bei Dir installiert haben. Sollte die Box bis dahin kein OCPP unterstützen, würde sie die Betriebserlaubnis am MEGA Anschluß verlieren. 

Viele Grüße

Alex

PS: Ich bin kein Elektriker, sondern nur interessierter PV- und Wallbox-Nutzer. Daher alles was ich hier schreibe bitte immer gut hinterfragen und mit einer Prise Salz genießen.  :-)

Ach ja:

warp/charge_tracker/current_charge {"user_id":2,"meter_start":null,"evse_uptime_start":482012286,"timestamp_minutes":27466259,"authorization_type":3,"authorization_info":{"tag_type":0,"tag_id":"CA:FE:AF:FE"}}

Soll die user_id wirklich der numerische Index sein oder sollte hier nicht eher der Benutzername rein?

Am 21.3.2022 um 13:49 schrieb rtrbt:

Du bekommst im Ereignislog vermutlich

MQTT: Ignoring message with payload length 40 for topic warp2/X8A/nfc/inject_tag. Maximum length allowed is 32.

(oder ähnlich)?

Moin!

Nein, das habe ich im Log nicht gesehen.

Als ich mit der neuen Beta das gleiche Verhalten gesehen habe, bin ich stutzig geworden. Dann ist mir bewusst geworden, dass das ja nur mit angestecktem Fahrzeug funktioniert. Nach Beseitigung des Layer 8 Fehlers lief es dann wie es soll. Ich möchte es jetzt allerdings mit der alten Beta nicht nochmal nachtesten.

Mir ist noch folgendes Verhalten aufgefallen: In meiner WARP sind zwei Tags mit unterschiedlichen Stromgrenzen hinterlegt. Ein inject_tag mit dem ersten setzt die Benutzergrenze auf den konfigurierten Wert. Ein nachfolgendes inject_tag mit dem anderen Tag ändert nichts mehr an der Benutzergrenze. Ich muss erst die Benutzerauthorisierung aus- und wieder anschalten, dann nimmt die WARP das zweite Tag an. Ich nehme an, ein Ab- und Anstecken des Fahrzeugs hätte wahrscheinlich den gleichen Effekt gehabt. Ob es sich mit echten Tags am RFID Leser genauso verhält, konnte ich nicht testen.

Grüße
Alex

vor 5 Stunden schrieb E-t-h:

Hast Du mal was zum nachlesen?

Schau Dir mal die Erklärung oben zu den einzelnen Ladegrenzen an. Der Slot mit Index 6 ist die Benutzer-Grenze, also die durch RFID gesetzte und 0A= blockiert, weil kein Tag rangehalten wurde.

Ich hoffe, ich spamme nicht zu viel ins Forum (einfach Bescheid geben), aber ich bin möglicherweise über einen Fehler gestolpert.

Ich habe in der WARP (WARP 1 Smart mit NFC Bricklet) drei Tags händisch über die Weboberfläche eingetragen und die "Benutzerautorisierung" aktiviert. Unter Laststromgrenzen stehen sowohl "Benutzer" als auch "externe Steuerung" auf blockiert. Soweit ok.

Wenn ich nun per

mosquitto_pub -t warp/nfc/inject_tag -m '{"tag_type": 0, "tag_id": "DE:AD:BE:EF"}'

eine Aktivierung per RFID simuliere, bleiben aber weiterhin beide Werte unverändert auf "blockiert" stehen. Der Tag findet sich nach Aufruf des mosquitto Befehls im seen_tags Topic und die Tag-ID habe ich per copy-and-paste aus dem NFC Menüpunkt der WARP kopiert, ein Tippfehler ist also ausgeschlossen.

Ich hätte erwartet, dass ein inject_tag die Begrenzung bei "Benutzer" beeinflusst.

vor 1 Stunde schrieb gintonicgamer:

Ja, ich habe alle 3 probiert. 
der mit dem starken signal ist der fritz repeater im mesh.

Probier's mal ohne BSSID Sperre. Wenn man mit Repeatern oder mehreren APs arbeitet, ist das IMHO die bessere Variante.

EDIT: Und am besten das Passwort auch nochmal neu eingeben, obwohl es sich nicht geändert hat.

vor 1 Stunde schrieb rtrbt:

Es gibt pro Ladestromgrenze einen Strom und ein Flag das angibt, ob die Grenze aktiv ist. Der Ladecontroller berechnet dann das Minimum aus allen aktiven Grenzen und das ist der Strom mit dem geladen werden kann.

[...]

Die Ladestromgrenze "Konfiguration" ist der Wert, den du auf der Statusseite einstellen kannst. Da ist es aber auf der Statusseite so, dass du maximal das Minimum aus Zuleitungs- und Typ-2-Kabel-Grenze setzen kannst

Danke für die ausführliche Beschreibung!

Kurz zum Verständnis: Bisher konnte man in der GUI beim konfigurierten maximalen Ladestrom sehen, wie die externe Regelung den Ladestrom immer wieder nachregelt. Mit der nun kommenden Trennung von "externer Ladegrenze" und (intern) konfigurierter Ladegrenze kann mit der neuen Firmware eine externe Ladesteuerung nun also nicht mehr über den in der GUI im Status konfigurierten maximalen Ladestrom hinausregeln (sofern nicht explizit freigegeben), korrekt?

vor 6 Stunden schrieb Witto:

Gibt es schon was neues zu OCPP? Mein Netzbetreiber fordert dies leider zwingend

Ich frage mich, wie sich die MEGA an die OCPP Schnittstelle anbinden will. Mit dem reinen Vorhandensein einer solchen Schnittstelle ist es ja nicht getan, es muss auch einen (gesicherten!) Kommunikationsweg dorthin geben.

Moin!

Was hat es denn mit den verschiedenen Freigaben unter Ladecontroller -> Ladestromgrenzen auf sich?

Autostart, Benutzer und Lastmanagement kann ich mir so weit vorstellen, aber was macht z.B. der "Freigeben" Knopf bei "Externe Steuerung" anders als der an/aus Knopf der Externen Steuerung weiter oben bei den Einstellungen? Und was bedeutet "Konfiguration" (und wozu dient der Freigeben Knopf dort)?

Grüße
 Alex

vor einer Stunde schrieb mattsches:

Was meinst du mit vertikaler Hutschienenbefestigung?

Moin!

Ich muss das Relais in der Box ja irgendwie befestigen und im Shop gibt es für Bricklets verschiedene Hutschienenhalterungen. Eine davon nennt sich „vertikale Hutschienenbefestigung“ und braucht am wenigsten TE. Ich weiß aber nicht, ob die dann nicht zu weit vorsteht, um noch den WARP Deckel wieder zuzukriegen.

Wäre toll, wenn Du Deinen Code freigibst, wenn er soweit nutzbar ist. Ich schaue derweil mal in den WARP2 Code rein, vielleicht ist da ja schon eine API für die CP Ansteuerung von außen durch den Energy Manager (hatte das letzte mal nichts dazu in der offiziellen Doku gesehen), dann macht es sicherlich Sinn, das in der WARP1 entsprechend kompatibel nachzubauen.

Gruß

Alex

vor einer Stunde schrieb batti:

WARP1 unterstützt leider keine CP Trennung. Der EVSE besitzt dafür nicht die technischen Möglichkeiten. Dies könnte man nur über ein Relais oder ähnliches nachrüsten (Industrial Dual Relay Bricklet). Das müsste dann natürlich selbst implementiert werden.

Danke für die Info - schade eigentlich. Als ich im Stromlaufplan der WARP1 die “CP Steuerung“ gesehen habe, hatte ich gehofft, dass damit auch eine Trennung möglich wäre.

Dann muss ich mich wohl mal in die ESP32 Programmierung einarbeiten...

Ist in der WARP 1 Smart genug Platz für die vertikale Hutschienenbefestigung?

Am 7.12.2021 um 10:39 schrieb batti:

Damit kann er dann regeln wie viel Leistung den angeschlossenen Wallboxen zur Verfügung steht.

Moin!

Wie flexibel ist der Manager? Kann man auch Messgeräte per MQTT einbinden? Unterstützt er ein Lastmanagement, um den Hausanschluss nicht zu überlasten? Kann sich der Manager auch einer andren Regelung (EVCC) unterordnen?

Und kann die CP Trennung der Wallbox auch durch andere Manager (EVCC😉) getriggert werden?

Unterstützt WARP1 eigentlich die CP Trennung und wenn nicht, kann die leicht nachgerüstet werden?

Viele Grüße

Alex

Ich möchte jetzt noch mehr Löcher ins Forum fragen, aber verbleibe einfach mal gespannt, wie die Architektur aussehen wird und wie das noch mit EVCC zusammen spielen wird, wenn der Energy Manager dann die WARP steuert... 😀

Werdet ihr das Protokoll zwischen WARP und Energy Manager so dokumentieren, dass man sich da ggf Adapter für die eigene, schon vorhandene Infrastruktur programmieren kann?

Am 4.11.2021 um 15:27 schrieb Doncarlos:

Ich wollte hier noch Rückmelden, dass das letzte Firmwareupdate 1.3.0-617bc859 tatsächlich die WLAN Verbindung verbessert hat.

Kann ich auch bestätigen. Am Abend des 3. November hatte ich die Firmware aktualisiert:

Die Tx Rate (aus Sicht AP), mit der sich die Box mit dem AP verbunden hat, hat sich deutlich verbessert, die Retries sind dadurch aber nur ganz geringfügig angestiegen.

Viele Grüße
 Alex

Bis das nativ von der WARP unterstützt wird, wäre auch das eine Variante:

https://gist.github.com/Alestrix/8a6da35ce07d2bf4fb22aec759f5dcc3

Ist noch komplett unausgereift, muss natürlich an das eigene Setup angepasst werden und statt an das evcc Topic zu senden müsste man an die WARP senden. Aber es ist ein Anfang.

Was das sekündliche Schreiben auf Flash-Speicher (ich nehme einfach mal an, FHEM läuft auf einem Minicomputer mit SD-Karte) angeht, kann ich das gut nachvollziehen - lange macht die Karte das wahrscheinlich nicht mit...

Aber was die "Netzverseuchung" angeht - ich weiß nicht so recht... Bei mir werden pro Sekunde etwa 480 Byte (keys+payload) per MQTT von der WARP versendet. Selbst wenn das mit MQTT-, TCP- und IP-Protokolloverhead auf den Faktor 3 ansteigen würde, ist man bei etwa 12kbps. Ist das für heutige Haus-LANs tatsächlich ein Problem?

Was ich damit sagen will: Nicht alles, was auf den ersten Blick wie ein Problem aussieht, ist auch eines :)

Am 5.11.2021 um 11:58 schrieb rtrbt:

Es scheint da ein Problem mit der Initialisierungsreihenfolge zu geben, sodass manchmal der Standard-Hostname des ESPs nicht sauber überschrieben wird.

Bin nicht OP, aber ich sehe das Verhalten auch. Was heißt denn „manchmal“, müsste der Name nach mehreren Konfigurationsversuchen korrekt im Controller erscheinen?

Bei mir geht es mit <hostname>.local übrigens nicht, evtl habe ich aber auch ein Problem mit meinem mDNS Reflector auf dem Router (Box ist in anderem Subnetz).