Jump to content

rtrbt

Administrators
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    1.403

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

 Inhaltstyp 

Posts erstellt von rtrbt

    Lastmanagement - Frage

    in WARP Charger

    Geschrieben

    Für den maximal verfügbaren Strom ist nicht nur der Strom an den Wallboxen relevant, sondern auch wie die Zuleitungen angeschlossen sind  D.h. wenn du z.b. jede Wallbox mit 16 A abgesichert hast, und dein Hausanschluss aber nur mit 3x40A abgesichert ist, dann darfst du den maximalen Ladestrom höchstens auf 40A (eher weniger, du hast ja eventuell noch andere Verbraucher) einstellen. 64 A sind nur dann sicher, wenn deine Verkabelung (bis zu dem Punkt wo sich die einzelnen Wallbox-Zuleitungen auftrennen) das erlaubt.

    On 11/16/2022 at 7:44 PM, thesaintbev said:

    was passiert wenn nur eine Box lädt?

    Dann lädt sie nur mit 16 Ampere. Alle aktiven Stromgrenzen (die der Dip Schalter, die des Typ-2-Kabels, des Lastmanagements usw.) werden von der Wallbox nie überschritten.

    Zeitsteuerung?

    in WARP Charger

    Geschrieben

    1 hour ago, wuesten_fuchs said:

    Aber es reicht aus, wenn ich den Debug-Report unmittelbar danach herunterlade?

    Ja. Im Idealfall ziehst du, wenn der Ladevorgang anfängt einen Debug-Report, machst dann

    On 11/13/2022 at 9:15 PM, wuesten_fuchs said:

    dieselbe Prozedur nochmal mache (Abstecken, Anschließen, NFC-Authentisierung),

    und ziehst danach noch einen Debug-Report.

    WARP1 steht nach einer gewissen Betriebszeit

    in WARP Charger

    Geschrieben

    On 11/15/2022 at 7:33 PM, floho said:

    Die LED ging an beim Anstecken des Autos. Der NFC Flicker kam aber nicht beim Hinhalten des Tags. 

    D.h. der Ladecontroller lief zumindest noch. Das ist schonmal gut.

    On 11/16/2022 at 11:15 AM, kaeferfreund said:

    Alle Boxen waren auf der 2.0.8 und hatten eine Uptime von ungefähr zwei Monaten

    Das ist sehr interessant. In letzter Zeit häufen sich die Meldungen über genau das Problem und die letzte Firmware ist zwei Monate alt. Wir haben hier zwei Wallboxen laufen, die in der Nacht zum Samstag die 50 Tage Uptime erreichen (=2^32 Millisekunden). Eventuell haben wir uns ein Timestamp-Überlauf-Problem eingetreten (auch wenn der Code das eigentlich korrekt behandelt).

    Ich melde mich am Montag nochmal ;)

    WARP2 Beta-Firmware mit Modbus-TCP-, WireGuard-, RTC- und OCPP-Unterstützung

    in WARP Charger

    Geschrieben

    Moin,

    EDIT: Alle Features diese Beta sind in "fertiger" Version in Firmware 2.1.0 enthalten.

    In die zweite OCPP-Beta (siehe hier für Beta 1) habe ich weitere neue Features gepackt, die wir in den letzten Monaten hinzugefügt haben. Die Dokumentation fehlt noch, deshalb hier eine kurze Erklärung pro neuem Feature:

    Modbus-TCP

    Wenn Modbus-TCP auf der entsprechenden Unterseite im Webinterface aktiviert wird, kann der Zustand des WARP Charger per Modbus-TCP ausgelesen werden. Optional kann auch eine Ladesteuerung über Modbus-TCP erlaubt werden. Auf der Unterseite findet sich die Dokumentation der unterstützten Register. (Siehe Screenshot für einen Ausschnitt).

    image.png

    Neben dem WARP-eigenen Registerset kann der WARP Charger die Registertablle der Keba c-Series-Wallboxen, sowie des Bender CC612/613-Ladecontrollers, der in vielen Wallboxen eingesetzt wird, emulieren. Damit sollte es möglich sein, ohne weitere Anpassungen einen WARP Charger in z.B. ein Hausautomatisierungssystem, einen Energiemanager etc. einzubinden, der eine der emulierten Wallboxen unterstützt.

    WireGuard

    Der WARP Charger kann jetzt über WireGuard VPN-Verbindungen aufbauen.Die hierfür benötigten Schlüssel müssen von Hand erstellt und auf das Webinterface eingegeben werden. Siehe hier für Details: https://www.wireguard.com/quickstart/#key-generation

    RTC-Unterstützung mit dem Real-Time Clock Bricklet 2.0

    Wie mehrfach gewünscht, kann jetzt ein Real-Time Clock Bricklet 2.0 an einen WARP Charger (bzw. an dessen ESP32 (Ethernet) Brick) angeschlossen werden. Sobald das Bricklet erkannt wurde, wird es automatisch verwendet. Der Haupteinsatzzweck ist, dass mit dem RTC Bricklet Ladevorgänge, ohne dass eine Netzwerkverbindung bestehen muss, zeitgenau aufgezeichnet werden können. Das RTC Bricklet (und damit die Systemzeit) werden automatisch gestellt, wenn das Webinterface mit einem Browser geöffnet wird. Falls die Zeit doch über das Netzwerk synchronisiert werden kann, wird die RTC auch gestellt.

    OCPP - jetzt mit SmartCharging

    Die OCPP-Implementierung unterstützt jetzt das Smart-Charging-Profil. Damit kann der Ladestrom über OCPP gesetzt werden, Zeitpläne vorgegeben werden usw.. Getestet wurde das SmartCharging-Profil unter anderem mit der HomeAssistent-OCPP-Integration. Ansonsten arbeiten wir weiter daran, ein möglichst großes OCPP-Feature-Set zu unterstützen und mit möglichst vielen Backend-Servern zu testen. Die Entwicklung könnt ihr im OCPP-Beta-Thread verfolgen.

    Ich freue mich wie immer über Feedback!

    Grüße,
    Erik

     

     

    warp2_firmware_2_0_93_63a45ecd_merged.bin

    WARP1 steht nach einer gewissen Betriebszeit

    in WARP Charger

    Geschrieben

    Reagiert bei euch beiden die Wallbox-LED noch darauf, wenn ein Auto angeschlossen wird?

    Wenn das der Fall ist, aktualisiert bitte auf 2.0.8 (bzw. WARP1 2.0.7). Wir hatten in den Firmwares davor Probleme mit der WebSocket-Implementierung, die zu genau dem Verhalten geführt haben. Meines Wissens (leider ist die einzige Möglichkeit das zu testen, eine Wallbox ein paar Wochen laufen zu lassen) sollte das aber mit der jeweils aktuellen Firmware nicht mehr auftreten. Falls doch, bitte nochmal Bescheid geben!

    WARP2 Beta-Firmware mit OCPP-Unterstützung

    in WARP Charger

    Geschrieben

    The plot thickens: Ich habe mir einen Switch mit Port-Mirroring besorgt um den Traffic zwischen eCarUp und dem WARP Charger mitlesen zu können und folgendes festgestellt: Wenn ich eine Transaktion per App/Webseite starte, dann stoppe (das Auto angeschlossen lasse) und wieder starte funktioniert alles wie erwartet. Wenn ich aber die zweite Transaktion stoppe, dauert das im eCarUp-Webinterface ein paar Sekunden länger, der Status springt dann aber auf "verbunden" um. Laut Wireshark schickt eCarUp dann aber nie den RemoteStopTransaction.req, deshalb läuft die Transaktion bei uns weiter. Wenn ich dann z.B. das Auto abziehe, antwortet eCarUp nie auf den StopTransaction.req.

    Mit dem Switch konnte ich jetzt sehen, dass die Pakete wirklich nicht ankommen (bei RemoteStartTransaction) bzw. rausgehen aber von eCarUp nicht bestätigt werden (StopTransaktion). D.h. nach meinem Verständnis liegt das Problem nicht bei uns. Ich habe den eCarUp-Leuten mal einen Bugreport geschickt.

    WARP2 Beta-Firmware mit OCPP-Unterstützung

    in WARP Charger

    Geschrieben

    Kurzes Update: Ich schaffe es jetzt auch auf verschiedene Arten, dass eCarUp-App und Webseite einen anderen Zustand anzeigen als tatsächlich der Fall ist (im Extremfall sogar dass eine Transaktion läuft aber eCarUp sagt das die schon beendet wurde).

    Aber es gibt auch eine gute Nachricht: wss funktioniert wieder. Das muss auf deren Servern für ein paar Tage kaputt gewesen sein.

    WARP1 steht nach einer gewissen Betriebszeit

    in WARP Charger

    Geschrieben

    On 11/8/2022 at 1:32 PM, michaelst said:

    Nehmen wir an, dass nur der ESP-Brick ausgefallen ist, dann könnte das nicht funktionierende Laden doch damit erklärt werden,
    dass der NFC-Tag zum Starten benötigt wird und das NFC-Bricklet am "stehenden" ESP hängt und damit nicht erkannt wird.

    Richtig?

    Korrekt. Der ESP schreibt dann nie einen Strom > 0 in die Benutzer-Ladestromgrenze (die auf dem EVSE liegt)

    Laut der Daten hat sich also mindestens der ESP in der Nacht vom 7. auf den 8. aufgehangen. Falls du das nochmal erzeugt bekommst, versuche mal, ob du den ESP noch anpingen kannst und ob (notfalls über den Access-Point des ESPs) du auf http://10.0.0.1/recovery (bzw. eine andere IP wenn du nicht über den ESP-Access-Point gehst) kommst. Falls ja zieh da mal einen Debug-Report.

    Umstellung auf Preact für eigene Module notwendig?

    in WARP Charger

    Geschrieben

    On 11/7/2022 at 9:01 PM, mattsches said:

    Muss ich das mit meinen Modulen so nachturnen, wenn ich auf den aktuellen Stand gehe, oder funktionieren meine Frontend-Seiten weiter wie bisher?

    Im Moment sollten deine Module noch funktionieren, weil ich jedes Frontend-Modul erstmal einzeln nach Preact umgestellt habe. Es steht noch aus, das Seiten-Template ansich umzuschreiben. Wenn wir das implementiert haben und du das nachziehen willst, musst du dann deine Module umstellen.

    • Thanks 1

    WARP1 steht nach einer gewissen Betriebszeit

    in WARP Charger

    Geschrieben

    55 minutes ago, michaelst said:

    Es gibt keine Reaktion auf das Anschließen des Autos, keine Reaktion der Led.

    Das ist wirklich interessant: Die LED wird vom Ladecontroller (dem EVSE Bricklet) gesteuert. Die Ladecontroller-Firmware ist so ausgelegt, das selbst wenn der ESP-Brick (über den läuft das Webinterface, MQTT, usw.) nicht funktioniert, das Laden (und die LED) weiterlaufen.

    Wenn also nicht mal die LED angeht, wenn du ein Auto ansteckst, dann muss der Ladecontroller selbst hängen. Mir ist ehrlicherweise unklar, wie das passieren kann.

    Ich habe gerade getestet, wie sich der ESP-Brick in dem Fall verhält, aber außer vielen Fehlermeldungen im Ereignis-Log der Form 

    2022-11-08 12:53:13,767  all_data_1 -1

    funktioniert alles wie erwartet. Die APIs unter evse/ aktualisieren sich dann nicht mehr, aber prinzipiell bleiben Webinterface, MQTT usw. erreichbar. D.h. irgendwie müssen sowohl EVSE, als auch ESP bei dir (unabhängig voneinander?) in ein Problem laufen.

    Wir bauen für die nächste Firmware mal ein, dass das EVSE-Bricklet und der ESP-Brick jeweils neustarten, falls die Kommunikation eine lange Zeit gestört ist (z.B. weil eben die andere Komponente hängt). Ob das bei deinem Problem hilft ist mir aber unklar.

     

    1 hour ago, michaelst said:

    Kann ich programmiertechnisch irgendetwas einbauen, um den Fehler ggf. zu erkennen?

    Je nachdem welche Daten du in deine Datenbank geloggt hast könnten wir vielleicht erkennen, ob sich der Ladecontroller zuerst aufgehangen hat. Hast du einen der häufig wechselnden Werte in die Datenbank geschrieben? (z.B. irgendetwas aus evse/low_level_state).

    changing mqtt topics in mqtt bindings

    in General Discussion

    Geschrieben

    If you only want to change the prefix (i.e. tinkerforge/) you can use the --global-topic-prefix command line argument:https://www.tinkerforge.com/en/doc/Software/API_Bindings_MQTT.html#topic-prefix

    To also change the suffix to /config, you have to write your own script or change the bindings. (You can techically add a suffix to any tinkerforge-topic however home assistant does not allow node_ids with / in them so this doesn't work in your case)

×
×
  • Neu erstellen...