Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.388
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Posts erstellt von rtrbt

  1. Wir haben uns den Debug-Report angesehen, anscheinend passiert folgendes:

    • Der NFC-Leser selbst schickt entweder > eine Sekunde lang keine Daten mehr, oder die Wallbox ansich hängt aus anderen Gründen so lange
    • Das sorgt dafür, dass ein Code-Pfad genommen wird, der definitiv falsch ist (habe ich verbockt, sorry)
    • Das crasht die Wallbox -> sie startet neu

    Ich fixe auf jeden Fall den Code, der da crasht, aber:

    On 6/12/2023 at 10:03 AM, timmy said:

    Ich habe keine relevanten, weiteren Meldungen gesehen, kann auch nicht beschwören, dass ich nachher nochmals den NFC-Leser getestet habe. Muss ich mal nachholen.

    Wenn du das tust: teste bitte nochmal mit genau den NFC-Tags die du davor probiert hast. Falls du mit einem der Tags reproduzierbar den NFC-Leser abschießen kannst, wäre das sehr interessant.

     

  2. On 6/9/2023 at 7:51 PM, kagehisa said:

    Wenn EVCC die Steuerung übernimmt muss an der Wallbox dann trotzdem Lastmanagement aktiviert werden?

    Ja. Das Lastmanagement ist für die Phasenumschaltung notwendig, weil darüber der Ladevorgang gestoppt und das CP-Signal getrennt wird, bevor die Phasenumschaltung durchgeführt wird.

    On 6/9/2023 at 7:51 PM, kagehisa said:

    GIbt es einen speziellen Grund warum das so gemacht wurde?

    Mehrere: Das EVCC-Weltmodell kennt den Energy Manager nicht, er wird praktisch als Teil der Wallbox behandelt und nur für die Phasenumschaltung verwendet. Außerdem ist die Idee, dass EVCC vermutlich bereits eine Solaranlage auslesen und damit besser steuern kann.

    • Thanks 1
  3. Die obligatorische erste Frage: Läuft die aktuelle Firmware (2.1.2) auf der Wallbox? Nicht dass wir alte Bugs jagen.

     

    On 6/9/2023 at 9:13 PM, timmy said:

    Das hat bei zwei Karten funktioniert, dann verlor ich die Verbindung zum Access-Point des WARP2 -- wohl ein reboot. Danach konnte der NFC-Leser wieder keine Karten erkennen und zeigte keine Reaktion.

    Hattest du nach zwei Karten auf Speichern und dann Neu starten geklickt oder ist die Wallbox von sich auch neugestartet? Im zweiten Fall würde ich gerne herausfinden, warum das passiert ist. Dafür müsstest du einen Debug-Report von der Wallbox ziehen.

    On 6/9/2023 at 9:13 PM, timmy said:
    305,337  NFC mode invalid. Did the bricklet reset?

    Bekommst du nach dieser Meldung weitere? Die Meldung wird genau ausgegeben, bevor die Wallbox den NFC-Leser neu initialisiert. D.h. eigentlich sollten spätestens danach wieder Tags erkannt werden.

    On 6/12/2023 at 8:09 AM, timmy said:

    Habe ich es hier mit einem Hardware-Defekt zu tun?

    Möglich. Das muss aber etwas nicht offensichtliches sein, wenn die Kommunikation zum NFC-Bricklet noch funktioniert, es sich aber sporadisch zurücksetzt? (so interpretiere ich das Log erstmal).

    Zieh wie gesagt mal einen Debug-Report von der Wallbox. Ich hoffe, dass wir dann mehr sehen.

  4. Eigentlich sollte

    On 6/10/2023 at 9:16 PM, piwo2 said:

    "qt.qpa.qgnomeplatform.theme: The desktop style for QtQuick Controls 2 applications is not available on the system (qqc2-desktop-style). The application may look broken."

    kein Problem sein, da der Brick Viewer nicht QtQuick sondern QtWidgets benutzt. Du kannst z.B. mal versuchen, die Verwendung des Fusion-Styles (oder jedes beliebigen anderen) zu verwenden mit

    sudo QT_STYLE_OVERRIDE=fusion brickv

     

    Eventuell hilft das hier?: https://wiki.archlinux.org/title/qt#Theme_not_applied_to_root_applications

     

  5. Das kommt darauf an, wie du den maximalen Ladestrom setzt:

    Wenn du evse/global_current_update verwendest, wird die Ladestromgrenze verändert, die auch im Webinterface auf der Statusseite als "Konfigurierter Ladestrom" angezeigt wird. Diese Stromgrenze wird in der Tat im Flash des Ladecontrollers gespeichert.

    Alternativ kannst du in den Ladeeinstellungen die externe Steuerung aktivieren und dann mit evse/external_current_update den Ladestrom setzen. Dieser Wert wird nicht im Flash gespeichert und ist deshalb auch der, der von z.B. EVCC verwendet wird.

  6. Es gibt in esp32-firmware/software das Script coredump.py. Dem kannst du entweder einen Pfad zu einem Debug-Report geben (an den hängen wir den letzten Coredump an) oder mit -p einen seriellen Port an dem ein ESP angeschlossen ist, von dem der Coredump runtergeladen werden soll. Das Script besorgt sich auf eine der beiden Weisen einen Coredump, sucht in esp32-firmware/software/build nach der .elf-Datei die zu der Firmware gehört und startet dann einen gdb der den Stacktrace dekodiert und ihn und die Register usw. ausgibt.

  7. Firmware: WARP Energy Manager 1.0.3

    • Neuen Phasenumschaltungs-Modus "Einphasig PV/Dreiphasig schnell" hinzugefügt
    • Anzeige des Zustands der Phasenumschaltung bei externer Kontrolle hinzugefügt
    • Prüfung auf überlappende Netzwerkbereiche bei IP-Konfiguration von LAN, WLAN und WireGuard hinzugefügt
    • Übersetzungen verbessert
    • Sofortiger Start des WLAN Access Points hinzugefügt, falls keine WLAN-Verbindung konfiguriert und kein Ethernet-Kabel verbunden ist
    • Sichtbarkeit der Nulllinie verbessert
    • Alle 48h-Graphen auf mindestens 1500 Watt skaliert
    • Minimalhöhe der Monatsübersicht auf 10 kWh reduziert
    • Ereignis-Log-Meldungen überarbeitet
    • Generierung des Energie-Manager-Protokolls repariert
    • Verwendung des falschen Minimalstroms bei einphasigem Laden repariert
    • Plötzlichen Ladestop bei geringer PV-Produktion behoben
    • Instabiles Verhalten am Anfang eines Ladevorganges bei teilweise bewölktem Wetter behoben
    • Behoben, dass Daten der dritten und weiterer Wallboxen nicht aufgezeichnet worden
    • Überlappende Balken in Monatsübersicht behoben
    • Abgeschnittenen ersten und letzten Balken in Monatsübersicht behoben

    Hinweis: Version 1.0.3 hat einen Bug der dazu führen kann, dass kein Zugriff auf das Webinterface möglich ist. Bitte direkt 1.0.4 verwenden.

  8. Sorry den Edit hatte ich nicht gesehen. Der ESP crasht in deiner Variante, weil du pixels in der Funktion anlegst. Dann landet das Array auf dem Stack und der ist je nach den Werten von WIDTH und HEIGHT zu klein. Wenn du z.B. das ganze Display füllen willst, also WIDTH 64 und HEIGHT 128, braucht das Array 64 * 128 = 8 kB Speicherplatz. Der Stack ist aber wenn ich mich richtig erinnere nur 6 kB groß.

    Wenn du die Deklaration von pixels aus der Funktion rausziehst, funktioniert es.

  9. Die Funktion hat den Fallstrick, dass die Endwerte jeweils auch Pixelkoordinaten sind. Das heißt, dass wenn du 16*16 Pixel zeichnen möchtest, die Endwerte jeweils der Startwert plus 16 Pixel sind, weil der Startpixel mitzählt.

    #include "Arduino.h"
    
    #include "bindings/config.h"
    #include "hal_arduino_esp32_brick/hal_arduino_esp32_brick.h"
    #include "bindings/errors.h"
    #include "bindings/bricklet_oled_128x64_v2.h"
    
    // Used to report any error encountered while running the example.
    extern "C" void check(int e_code, const char *c) {
        if (e_code == TF_E_OK) {
            return;
        }
    
    #if TF_IMPLEMENT_STRERROR != 0
        tf_hal_printf("Failed to %s: %s (error code %d)\n", c, tf_hal_strerror(e_code), e_code);
    #else
        tf_hal_printf("Failed to %s: %d\n", c, e_code);
    #endif
    }
    
    TF_HAL hal;
    
    static TF_OLED128x64V2 oled;
    
    bool pixels[16*16] = {
        true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true, 
        false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, true,
        true,  false, false, false, false, false, false, false, false, false, false, false, false, false, false, true,
        true,  false, true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  false, false, true,
        true,  false, true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  false, false, true,
        true,  false, false, false, false, true,  true,  false, false, false, false, false, false, false, false, true,
        true,  false, false, false, false, true,  true,  false, true,  true,  false, false, false, false, false, true,
        true,  false, false, false, false, true,  true,  false, true,  true,  false, false, false, false, false, true,
        true,  false, false, false, false, true,  true,  false, true,  true,  true,  true,  true,  false, false, true,
        true,  false, false, false, false, true,  true,  false, true,  true,  true,  true,  true,  false, false, true,
        true,  false, false, false, false, true,  true,  false, true,  true,  false, false, false, false, false, true,
        true,  false, false, false, false, true,  true,  false, true,  true,  false, false, false, false, false, true,
        true,  false, false, false, false, true,  true,  false, true,  true,  false, false, false, false, false, true,
        true,  false, false, false, false, false, false, false, false, false, false, false, false, false, false, true,
        true,  false, false, false, false, false, false, false, false, false, false, false, false, false, false, false,
        true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true,  true
    };
    
    void setup() {
        Serial.begin(115200);
        delay(3000);
        Serial.println("Hello World!");
    
        check(tf_hal_create(&hal), "hal create");
    
        // Create device object
        check(tf_oled_128x64_v2_create(&oled, NULL, &hal), "create device object");
    
        // Clear display
        check(tf_oled_128x64_v2_clear_display(&oled), "call clear_display");
    
        // Write "Hello World" starting from upper left corner of the screen
        check(tf_oled_128x64_v2_write_line(&oled, 0, 0, "Hello World"), "call write_line");
        // Draw logo to center of screen
        check(tf_oled_128x64_v2_write_pixels(&oled, 56, 24, 56 + 15, 24 + 15, pixels, 16*16), "call write_pixels");
    }
    
    void loop() {
        // Poll for callbacks
        tf_hal_callback_tick(&hal, 0);
    }

     

  10. USB mit einem Industrial Digital Out, IO4, oder ähnlichen Bricklets zu sprechen funktioniert vermutlich nicht. Dafür ist die Kommunikation zwischen ESP und Bricklet zu langsam. Über die Pins auf der Stiftleiste des ESP32 Brick sollte das theoretisch gehen, spontan finde ich aber nur Implementierungen für den ESP32-S2, der USB-Hardware-Support mitbringt.

    Der Ansatz, ein RS232-Bricklet und einen USB-Seriell-Wandler zu verwenden sollte funktionieren.

    Alternativideen:

    • Direkt den USB-Port des ESP-Bricks verwenden. Da musst du das Logging totlegen oder deine Nachrichten speziell markieren, damit der PC sie von den normalen Logs unterscheiden kann
    • Statt USB über das Netzwerk gehen. Du kannst den ESP per WLAN oder wenn es ein ESP-Ethernet-Brick ist auch per LAN ins Netzwerk bringen und die Daten dann über TCP oder UDP übertragen. Noch einfacher für den Anwender ist es, wenn du den Webserver benutzt, dann kann man die Daten z.B. einfach als Dateien herunterladen.
    • Thanks 1
  11. Moin,

    Ich glaube du und damit dann auch @MatzeTF sind falsch abgebogen. Die ESP32-Firmware zu erweitern ergibt eigentlich nur Sinn, wenn du auch die ganzen Features der Firmware nutzen willst. Webinterface, API usw. Wenn du eine kleine Firmware für einen ESP und ein paar Bricklets schreiben willst, ist es sinnvoller, eine "ganz normale" neue Arduino-Firmware zu schreiben.

    Die ganze Struktur kannst du dir anlegen wie hier: https://docs.platformio.org/en/latest/integration/ide/vscode.html#setting-up-the-project beschrieben (den Teil kennst du vermutlich, wenn du mit VSCode schon ESP-Firmwares geschrieben hast). Damit du mit den Bricklets kommunizieren kannst, brauchst du dann unsere C/C++-Bindings für Mikrocontroller, die kannst du hier: https://download.tinkerforge.com/bindings/uc/tinkerforge_uc_bindings_latest.zip herunterladen und dann folgende Ordner/Dateien in dein Projekt packen:

    • Den source\bindings-Ordner aus der Zip-Datei in dein Projekt nach src\bindings
    • Aus source\hal_arduino_esp32_brick bzw. hal_arduino_esp32_ethernet_brick (hängt davon ab ob du den Brick mit oder ohne Ethernet gekauft hast)  die .h und .cpp (nicht die .ino!) nach src\hal_arduino_esp32_brick
    • Wenn du die Beispiele verwenden möchtest, die zu jedem Bricklet in der Dokumentation (und der Bindings-Zip-Datei) enthalten sind, dann kannst du die .ino-Dateo aus source\hal_arduino_esp32_(ethernet_)brick als main.cpp nach source legen und dir eins der Beispiele daneben legen.

    Alternativ habe ich das ganze für das E-Paper-Bricklet mal durchgespielt, die Zip im Anhang beinhaltet alles, was du brauchst.

    esp32_epaper_example.zip

  12. Der konfiguierbare (grüne) Eingang ja, der Abschalteingang hat nur drei Pins.

    Um einen der Eingänge zu schließen musst du ihn mit GND verbinden. Also beim konfigurierbaren Eingang Pin 2 (IN) mit Pin 4 (GND), beim Abschalteingang Pin 1 mit einem der beiden anderen, die sind beide Masse.

  13. Moin,

    Das kannst du auf verschiedene Arten umsetzen:

    Variante 1: Falls die Wallbox relativ weit vom Smart Meter entfernt ist, kannst du den Lastabwurf über einen WARP Energy Manager umsetzen: https://www.warp-charger.com/energy-manager.html Der Energy Manager hat unten am Gehäuse zwei Eingänge, über die du den Ladestrom aller gesteuerter Wallboxen limitieren kannst. Die Kommunikation zwischen Wallbox und Energy Manager läuft übers Netzwerk.

    Variante 2: Die Wallbox selbst hat am Ladecontroller einen Abschalteingang und einen konfigurierbaren Eingang. Da laut der Vorgaben die Ladeleistung nur anteilig reduziert werden muss, kannst du den konfigurierbaren Eingang verwenden und diesen im Webinterface der Wallbox entsprechend konfigurieren:

    image.png

    Die Eingänge findest du am Ladecontroller hier: (grün - konfigurierbarer Eingang, orange - Abschalteingang)

    image.png

    Um das Steuerungskabel in die Wallbox zu bekommen musst du ein Loch ins Gehäuse bohren und mit einer Kabeldurchführung abdichten.

  14. Firmware: WARP Energy Manager 1.0.2

    • Wolkenfilter hinzugefügt
    • Support für PWA-artige Lesezeichen hinzugefügt
    • Monatsgraph zur Energiebilanz hinzugefügt
    • Statistiken zur Energiebilanz hinzugefügt
    • Minimalen Ladestrom für ein- und dreiphasiges Laden aufgeteilt
    • Einstellung des minimalen Ladestroms anhand des konfigurierten Fahrzeugtyps hinzugefügt
    • Verwendung der RTC des Energy-Manager-Bricklets hinzugefügt
    • Füllung für Stromzählerplot hinzugefügt
    • Konfiguration des Web-Interface-Ports hinzugefügt
    • WLAN-Empfangsqualität durch Deaktivierung des HT40-Modus und 11b verbessert
    • Robustheit der Stromzähler-Initialisierung verbessert
    • Robustheit der statischen IP-Konfiguration der LAN-Schnittstelle verbessert
    • Löschen kontrollierter Wallboxen auf der Lastmanagement-Konfigurationsseite repariert
    • Übersetzungen verbessert
    • Zeitzonen-Datenbank aktualisiert
    • Ausgabe der Verbindungsdauer bei Verlust einer LAN-, WLAN-, MQTT- oder WireGuard-Verbindung hinzugefügt
    • Defekte Links auf der Status-Seite entfernt, falls Lastmanagement-Konfiguration geändert, aber nicht angewandt wurde
    • MQTT-Timeout erhöht
    • NetBIOS-Unterstützung entfernt
    • DNS-Cache vergrößert
    • Fehlermeldungen von Texteingabefeldern repariert
    • Längenprüfung von Text- und Passworteingabefeldern repariert
    • Klickbare Links für kontrollierte Wallboxen auf der Statusseite hinzugefügt
    • Prüfung auf duplizierte Wallbox-Hostnamen bzw. IPs in der Lastmanagement-Konfiguration hinzugefügt
    • Auflösung von .local-Hostnamen via mDNS-Scan hinzugefügt
    • Veraltete WLAN-Empfangsqualitäts- und IP-Werte entfernt wenn WLAN-Verbindung verloren wird
    • MQTT-Fehlermeldungen verbessert

    Download: WARP Energy Manager 1.0.2

  15. On 5/14/2023 at 8:53 PM, poohnet said:

    Bei der Implementierung ist mir allerdings aufgefallen, dass das NFC-Modul wohl das Users-Modul benötigt, welches seinerzeit dann von EVSE(2) abhängig ist. Ist es geplant, die Module zukünftig weiter zu entkoppeln, sodass NFC bzw. die Userverwaltung auch außerhalb von WARP funktionieren?

    Prinzipiell ja, sobald wir die Benutzer für mehr verwenden, als nur zur Freigabe eines Ladevorgangs. Zum Beispiel soll es künftig Administratoren und "normale" Benutzer geben. Das wäre dann auch der Punkt, wo man das Users-Modul für den Energy Manager übernehmen und von der EVSE-Logik trennen würde.

    • Thanks 1
  16. On 5/5/2023 at 9:59 AM, poohnet said:

    Bei der Analyse habe ich festgestellt, dass es in den Ladeeinstellungen nun einen neuen Punkt "Zählerüberwachung" gibt, der den Ladevorgang blockiert. Da ich keinen Zähler verbaut habe sondern die Zählerstände per MQTT bereitstelle, habe ich die Option deaktiviert, was beim Speichern wie üblich einen Neustart des ESP32-Bricks ausgelöst hat.

    Die Zählerüberwachung sollte auch wenn du die Zählerstände per MQTT schickst funktionieren. Weil die Zählerüberwachung noch nicht veröffentlicht ist, ist sie aber noch nicht gut dokumentiert. Im Endeffekt macht sie folgendes:

    • Alle Stromzählerwerte werden als NaN initialisiert (damit wir unterscheiden können welche Werte nie gesetzt wurden, sei es über MQTT oder einen physisch angeschlossenen Zähler)
    • Wenn der Energie-Wert nicht auf etwas anderes als NaN gesetzt wird, blockieren wir den Ladevorgang. Dann ist der Zähler defekt, die Kommunikation gestört, oder ähnliches.
    • Standardmäßig ist auf einer Wallbox die Zählerüberwachung aus und im Moment wo das erste Mal ein Zähler auftaucht wird sie aktiviert. Also bei einer Pro schon bei uns beim Testen, bei einer Smart wenn du per API die ersten Werte schickst.
    On 5/5/2023 at 9:59 AM, poohnet said:

    Nach dem Neustart hat die Ladung sofort begonnen, allerdings wurde im Charge Tracker direkt ein fehlerhafter Ladevorgang protokolliert.

    Lief die Wallbox seitdem durch? Falls ja zieh mal einen Debug-Report. Mich wundert, warum nicht der End-Zählerstand der Ladung vor dem Neustart verloren gegangen ist (Das werden wir bald in den getrackten Ladungen reparieren können: https://github.com/Tinkerforge/esp32-firmware/issues/213), sondern der anscheinend da ist, aber der Startwert der Ladung nach dem Neustart fehlt.

    On 5/5/2023 at 9:59 AM, poohnet said:

    Ich habe das jetzt nicht nochmal versucht zu reproduzieren, aber kann es sein, dass der Charge Tracker aus dem Tritt gerät bzw. den Start der Ladung nicht richtig mitbekommt, wenn man den ESP32-Brick neustartet, während das Auto verbunden ist?

    Das ist einer der Gründe, warum es jetzt die Zählerüberwachung gibt. Wenn ESP und EVSE zu schnell booten (das kann man gut erzeugen wenn man bei einer WARP2 viele Features, vorallem Ethernet komplett deaktiviert), kann es ohne die Überwachung passieren, dass bei einem Ladestart noch kein Stromzähler gefunden wurde, und deshalb kein Stromzählerstand aufgezeichnet wird. Die Überwachung verhindert das, indem sie den Ladestart blockiert, bis ein Stromzählerwert ankommt.

     

    On 5/5/2023 at 9:59 AM, poohnet said:

    Zweite Frage: Gibt es eine Möglichkeit bzw. ist es geplant, einzelne Ladevorgänge zu löschen?

    Im Moment geht das nicht. Die Ladevorgänge werden direkt hintereinander in Dateien gespeichert, an die wir aus Robustheitsgründen nur Daten hinten hinzufügen, aber nie Daten modifizieren.

    On 5/7/2023 at 8:36 PM, poohnet said:

    Prinzipiell wäre eine einfache Option „ungültige Ladevorgänge ausblenden“ ja ausreichend, sodass derartige Ladevorgänge schlichtweg nicht angezeigt und beim Export übersprungen werden…

    Eventuell bauen wir das bald ein.

  17. Je nach Wallbox könnte das platzmäßig interessant werden: Der Piezo Speaker 2.0 ist relativ groß.

    Die Software dafür anzupassen sollte mit relativ wenig Aufwand klappen, folgendes müsstest du tun:

    1. Dich entscheiden, wann genau der Piezo Speaker Geräusche machen soll. Das kann z.b. sein:
      - Bei jedem bemerkten Tag, egal ob es ein bekanntes oder ein unbekanntes ist
      - Nur bei bekannten Tags ein Geräusch, bei unbekannten ein anderes
      - Bei bekannten Tags, aber nur wenn damit auch wirklich ein Ladevorgang gestartet wird
      - Auch wenn die Nutzerfreigabe von anderen Quellen gesetzt wird
    2. Abhängig davon, wann du Geräusche haben willst, musst du dich in eins oder mehrere der Module hängen:
      1. Im NFC-Modul läuft dieser Code bei jedem bemerkten Tag: https://github.com/Tinkerforge/esp32-firmware/blob/e44d2c98c47deab1e3394c615e9014ac7f306112/software/src/modules/nfc/nfc.cpp#L165C11-L197
      2. Wenn ein Tag eine Aktion auslöst läuft immer dieser Code: https://github.com/Tinkerforge/esp32-firmware/blob/e44d2c98c47deab1e3394c615e9014ac7f306112/software/src/modules/users/users.cpp#L842
      3. Wenn du (was in Summe am einfachsten ist) immer dann ein Geräusch willst, wenn auf der Front-LED ausgegeben werden soll, dass ein Tag erkannt wurde, kannst du dich hier vor die ganzen Priorisierungschecks hängen: https://github.com/Tinkerforge/esp32-firmware/blob/e44d2c98c47deab1e3394c615e9014ac7f306112/software/src/modules/evse_led/evse_led.cpp#L64 Das hat den Vorteil, dass wenn die Freigabe anders funktionieren würde (Man kann bald die Front-LED per API/Modbus TCP steuern) das einfach funktionieren würde

    Bei jeder dieser Varianten musst du dann aber immer, wenn du die Firmware deiner Wallbox aktualisieren willst, deine Variante davon neu bauen.

    • Thanks 1
  18. Bei meinem Zoe sieht das z.B. wie folgt aus, wenn man den Bereich von 18 Ampere bis 6 Ampere in 100mA-Schritten abfährt und jeweils 30 Sekunden zum einpendeln lässt:image.png

    Der spannungskompensierte Strom ist der L1-Strom, aber auf 230V skaliert. In Echt bricht die Spannung beim einphasigen Laden etwas ein, habe ich testweise mal rausgerechnet, um besser das Verhalten des Zoes zu sehen, aber selbst dann wird der Abstand relativ groß.

    Edit: Auf geglätteten Werten sieht mans besser: Der Zoe lässt immer ~ 500W Luft: (X-Achse ist der erlaubte Strom)

    image.png

  19. Wenn das so funktioniert, wie im Artikel beschrieben, dann musst du dafür die Honda-Wallbox benutzen:

    1. brauchst du einen CCS-Anschluss, d.h. die Wallbox macht aus Wechselstrom Gleichstrom und andersrum beim Einspeisen. Das heißt auch, dass die Wallbox die Netzsynchronisierung übernimmt.

    2.

    Quote

    Das Strommanagementsystem nutzt dabei die Echtzeit-Informationen zur aktuellen Situation im Stromnetz, die Next zur Verfügung stellt. Bei Abweichungen wird innerhalb der vorgeschriebenen Zeit auf die Lade- und Entlade-Anforderungen des Netzbetreibers reagiert. Laut Wikipedia muss innerhalb von 30 Sekunden die gesamte Regelleistung abgegeben werden.

    D.h. die Wallbox bzw. das Strommanagementsystem (ich gehe davon aus, dass das ein Extra-Rechner ist) muss diese Informationen verarbeiten.

    3. Muss man dann so ein "virtuelles Kraftwerk" aufbauen, da bist du rein rechtlich vermutlich sofort ein Energieversorger. Die Bürokratie dafür dürfte anstrengend werden.

  20. On 4/25/2023 at 7:53 PM, wolkenschaufler said:

    Grundsätzlich warte ich noch auf eure Anpassung der API damit EVCC auch den WEM steuern kann. Wenn das der Fall ist, dann können doch auch zwei WEMs eingesetzt werde wo jeder seine "eigene" WB steuert oder?

    Das müsste funktionieren. Ich weiß aber noch nicht, wie EVCC das dann genau umsetzen wird, also ob man pro Wallbox festlegen kann, ob und wenn ja von welchem WEM die Phasenumschaltung durchgeführt werden kann. (Wenn wir die API angepasst habe, werde ich das mal nachfragen)

    On 4/25/2023 at 7:53 PM, wolkenschaufler said:

    Phasenschieflast wäre ja nur ein Problem, wenn man auf mehr wie 16 A pro Phase geht, was aber bei zwei WB dann wiederum eine Genehmigung vom VNB nach sich ziehen würde.

    Wenn ich mich richtig erinnere brauchst du eine Genehmigung bei mehr als 11 kW (also 16 A dreiphasig). Trotzdem darfst du nur maximal 20 A Schieflast auf einer Phase erzeugen. Also rein theoretisch müsstest du dir eine 32 A-Wallbox die einphasig angeschlossen ist nicht genehmigen lassen, dich dann aber selbst darum kümmern, dass die nur 20 A Schieflast erzeugen kann.

    On 4/25/2023 at 7:53 PM, wolkenschaufler said:

    Ist jetzt natürlich ein wenig Glaskugellesen: Wäre es denn möglich, zwei WARP mit einem WEM zu betreiben und EVCC dennoch die Steuerung und Priosierung zu überlassen?

     

    Theoretisch doch schon oder?

    Da gehe ich von aus. Mit dem Setup kannst du dann aber nur bei beiden Wallboxen gleichzeitig die Phasen umschalten.

    • Like 1
  21. Mit etwas Programmier-/Script-Arbeit kannst du dir das bauen: Du kannst den WARP Charger per HTTP- und MQTT-API steuern (die sind fast identisch). In beiden Fällen wäre das Vorgehen etwa wie folgt:

    • Periodisch prüfen, ob ein Auto angeschlossen ist mit evse/state (darin der Wert "charger_state") (per http://warp2-abc/evse/state oder über MQTT auf warp2/abc/evse/state)
    • Periodisch prüfen ob ein NFC-Tag gesehen wurde mit nfc/seen_tags (die API liefert dir die letzten 8 gesehenen Tags, typischerweise reicht es wenn man sich den ersten Eintrag davon ansieht)
    • Wenn beides der Fall ist, den Ladevorgang mit einem HTTP PUT bzw. MQTT Publish vom gewünschten Ladestrom auf evse/external_current_update starten. Damit die externe Ladestromgrenze beachtet wird, musst du einmal im Webinterface unter Wallbox -> Ladeeinstellungen die externe Steuerung aktivieren.
    • Wenn ein Auto abgezogen wird, den Ladestrom auf 0 setzen, damit der Ladevorgang blockiert ist. Damit du das nicht von Hand machen musst, kannst du mit evse/external_clear_on_disconnect festlegen, dass das automatisch passieren soll, wenn ein Auto abgezogen wird. Das kannst du dann mit evse/external_defaults persistent machen.

    Mit einer der nächsten Firmwares kannst du das ganze auch per Modbus TCP umsetzen, da fehlt im Moment noch die Ausgabe des/der gesehenen NFC-Tags: https://github.com/Tinkerforge/esp32-firmware/issues/227

    Den SoC der Fahrzeuge rauszubekommen ist leider nicht ganz einfach. Eventuell hilft es, wenn du dir ansiehst, wie EVCC das macht.

    Als weniger flexible Alternative, bei der du aber nichts selbst programmieren musst, kannst du dir SteVe ansehen. Das ist ein OCPP-Server, der die Wallboxen steuern, NFC-Tags managen und Ladevorgänge aufzeichnen kann.

×
×
  • Neu erstellen...