Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.388
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Posts erstellt von rtrbt

  1. Jein. Man kann theoretisch per nfc/inject_tag ein NFC-Tag vortäuschen und damit per API den Ladevorgang für einen bestimmten Benutzer starten. Im Moment muss, damit diese API funktioniert aber ein NFC-Bricklet vorhanden sein (Das zu fixen ist dieses Issue:https://github.com/Tinkerforge/esp32-firmware/issues/133). Perspektivisch wollen wir aber dahin kommen, dass man per API (und dann auch übers Webinterface) für spezifische Benutzer einen Ladevorgang starten kann: https://github.com/Tinkerforge/esp32-firmware/issues/161

  2. Was @poohnet sagt. WSS über TLS geht bereits, im Moment beinhaltet die Firmware den kompletten Satz Root-Zertifikate von Mozilla: https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-reference/protocols/esp_crt_bundle.html Die Möglichkeit ein eigenes Root-Zertifikat hochzuladen wird aber auf jeden Fall noch kommen. Damit der Gedanke nicht verloren geht habe ich ein Issue dafür angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/233

  3. Firmware: WARP 2.1.2 und WARP2 2.1.2

    • UID der Wallbox zu Entitätsnamen der MQTT Auto Discovery hinzugefügt
    • EVSE Coils für Modbus TCP 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
    • Zugriff auf das Lastmanagement-Verteilungslog repariert
    • Robustheit der statischen IP-Konfiguration der LAN-Schnittstelle verbessert
    • Löschen kontrollierter Wallboxen auf der Lastmanagement-Konfigurationsseite repariert
    • Übersetzungen verbessert
    • Behoben, dass Zeit- und Energielimits weitere Ladevorgänge blockieren konnten
    • Zeitzonen-Datenbank aktualisiert
    • Ausgabe der Verbindungsdauer bei Verlust einer LAN-, WLAN-, MQTT- oder WireGuard-Verbindung hinzugefügt
    • Behoben, dass OCPP nicht neu verbunden wurde, falls eine TLS-Verbindung direkt nach dem Verbindungsaufbau geschlossen wurde
    • Behoben, dass Energie-Wert über Modbus-TCP mehr als einmal zurückgesetzt wurde
    • Defekte Links auf der Status-Seite entfernt, falls Lastmanagement-Konfiguration geändert, aber nicht angewandt wurde
    • PDF-Download-Timeout erhöht
    • MQTT-Timeout erhöht
    • Stoppen des Ladevorgangs im Webinterface, während ein anderer Ladestromslot blockiert, hinzugefügt

    Download: WARP 2.1.2 bzw. WARP2 2.1.2

  4. On 4/13/2023 at 7:04 AM, gollum said:
    On 4/12/2023 at 11:12 AM, MatzeTF said:

    Theoretisch sollte es so sein, dass fertig geladene Fahrzeuge mit niedriger Priorität geführt werden und nur dann wieder Strom zugeteilt bekommen, wenn noch was frei ist. Alternativ würden fertig geladene Fahrzeuge auf den Minimalstrom reduziert und der restliche Strom auf andere Wallboxen verteilt. So der Plan. Ist leider noch nicht fertig.

    Dann warte ich einfach mal ab was kommen wird.

    Das ist übrigens dieses Problem: https://github.com/Tinkerforge/esp32-firmware/issues/173 tl;dr: Der Lastmanager sollte Wallboxen an denen ein voll geladenes Fahrzeug hängt komplett deaktivieren und nur, falls von den anderen Wallboxen noch Strom übrig ist, versuchen die mit dem Minimalstrom wieder aufzuwecken. Das ist im Moment leider nicht funktional.

     

    On 4/13/2023 at 7:08 AM, gollum said:

    Ich habe auch schon verschiedene Debug-Reports erstellt, die zumindest ein Problem mit der DNS-Namensauflösung aufzeigen.

    Soll ich zu diesem Problemen einen neuen Thread aufmachen oder eventuell über einen anderen Weg melden?

    Das hier https://github.com/Tinkerforge/esp32-firmware/issues/225? Oder hast du noch einen anderen Bug gefunden? Kannst du hier posten.

  5. Du kannst, damit der type_override wieder deaktiviert ist auch genau wie oben über die Recovery-Seite einen API-Call machen, nur diesmal mit

    {"method":"PUT", "url":"/meter/type_override_update", "payload":"255"}

    Dann versucht die Wallbox wieder zu detektieren, was für ein Zähler verbaut ist, statt dass immer ein SDM630 angenommen wird.

  6. On 3/28/2023 at 6:51 PM, Warpuser77 said:

    Der Fehler kommt jetzt nicht mehr, allerdings lädt sie trotzdem mit z.B. 9KW obwohl ich auf PV gestellt habe im EVCC und nur 3,5 KW erzeugt werden.

    Wenn du die Situation nochmal erzeugen kannst, zieh einen Debug-Report von der Wallbox und am besten auch ein EVCC-Log und poste beide hier. Da muss irgendwas mit der Ansteuerung schieflaufen.

  7. Außer der Verbindung zum MQTT-Broker musst du auf der Wallbox nur genau eine Sache einstellen: Unter Wallbox->Lade­ein­stellungen musst du die externe Steuerung aktivieren. Ansonsten werden die von EVCC geschickten Befehle ignoriert.

    Ich sehe gerade, dass das aus irgendeinem Grund nicht in unserer EVCC-Anleitung steht. Fixe ich gleich.

  8. Das bleibt leider seltsam: In deinem letzten Log kam die erste Anfrage an den Zähler durch (das war Request 2, für den es keine Fehlermeldung gibt). Du bekommst dann

                      1,966  Found unknown meter type 0x0. Assuming this is a SDM72DM.

    was vermutlich daran liegt, dass das ein älterer SDM630 ist. Es gibt vom SDM630 diese ältere Version, die als Meter Type nicht 0x0070 meldet, sondern 0x0000. Das haben wir bei den Zählern in der WARP2 häufig beobachten können. Leider wissen wir nicht, ob es vom SDM72DM (der serienmäßig in der WARP1 Pro verbaut wurde) eine Version gibt, die auch dieses Problem hat. Deshalb müssen wir an der Stelle annehmen, dass das ein SDM72DM ist. Das sollte prinzipiell aber erstmal egal sein, der SDM630 unterstützt alle Register, die wir bei einem SDM72DM auslesen würden. Um 100%ig auf Nummer sicher zu gehen, kannst du den Meter Type aber erzwingen. Geh dazu mal auf http://192.168.2.30/recovery und füge bei API ins obere Feld folgendes ein:

    {"method":"PUT", "url":"/meter/type_override_update", "payload":"2"}

    Wenn du dann auf Call API klickst sollte im unteren Feld eine 200 erscheinen. Dann einmal die Wallbox neustarten.

    Falls das auch nicht hilft vermute ich, dass der Zähler einen Defekt hat, weil er ja nur extrem sporadisch auf Anfragen antwortet.

    Edit: Wegen der Error-LED: Die geht an, wenn das RS485-Bricklet in Timeouts läuft. D.h. das ist ein Symptom, nicht die Ursache des Problems.

  9. Firmware: WARP 2.1.1 und WARP2 2.1.1

    • MQTT-Auto-Discovery für Home Assistant und kompatible System hinzugefügt
    • Zeit- und Energielimits für Ladevorgänge hinzugefügt
    • Core-Dump zu Debug-Report hinzugefügt
    • Höhe des Stromzählergraphen auf mindestens 100 W limitiert
    • Live-Graph in den ersten vier Minuten nach Neustart repariert
    • Falsche Gesamtenergie-Berechnung in PDF-Ladelogs repariert
    • Aufzeichnung von Ladevorgängen bei Stromversorgungsverlust repariert
    • Fehlermeldungen von Texteingabefeldern repariert
    • Platzhaltertext der Passphrase der WLAN-Verbindung repariert
    • Löschen der WLAN-Verbindungs-Passphrase repariert
    • Längenprüfung von Text- und Passworteingabefeldern repariert
    • Robustheit des Bricklet-Flashens repariert
    • Übersetzungen verbessert
    • 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
    • Filter, der mDNS-Antworten, die nicht von WARP Chargern gesendet wurden, 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
    • (nur WARP2) Stromlimits für konfigurierbaren Eingang hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.11)
    • Abbruch des Ladeprotokolls nach 60 Sekunden behoben
    • MQTT-Fehlermeldungen verbessert

    Download: WARP 2.1.1 bzw. WARP2 2.1.1

  10. Tut mir leid, deine Antwort ist irgendwie untergegangen. Damit wir das Problem beheben können, müssen wir erst die Ursache herausfinden. Da eventuell im Ereignis-Log etwas interessantes steht, dass aber von den MQTT-Meldungen zugemüllt wird: Benutzt du als MQTT-Broker ioBroker? Falls ja, deaktiviere bitte einmal die Einstellung "Publish own states on connect" (siehe hier: https://www.iobroker.net/#en/adapters/adapterref/iobroker.mqtt/README.md?iobrokerworkingasmqttbroker) Dann solltest du nicht mehr die ganzen Meldungen im Log bekommen, wenn du die Wallbox neustartest und dann noch einen Debug-Report herunterlädst.

  11. Dein Problem ist, dass wir alle Werte als uint32 oder float hinterlegen. Beides ist vier Bytes (also zwei Modbus-Register) lang. Mit Pymodbus kannst du 4 Byte lange Werte z.B. so schreiben und lesen:

    from pymodbus.client import ModbusTcpClient
    from pymodbus.payload import BinaryPayloadBuilder, BinaryPayloadDecoder
    from pymodbus.constants import Endian
    
    def uint32_to_regs(value):
        builder = BinaryPayloadBuilder(wordorder=Endian.Big, byteorder=Endian.Big)
        builder.add_32bit_uint(value)
        return builder.to_registers()
    
    def float_to_regs(value):
        builder = BinaryPayloadBuilder(wordorder=Endian.Big, byteorder=Endian.Big)
        builder.add_32bit_float(value)
        return builder.to_registers()
    
    def regs_to_uint32(response):
        decoder = BinaryPayloadDecoder.fromRegisters(response.registers, wordorder=Endian.Big, byteorder=Endian.Big)
        return decoder.decode_32bit_uint()
    
    def regs_to_float(response):
        decoder = BinaryPayloadDecoder.fromRegisters(response.registers, wordorder=Endian.Big, byteorder=Endian.Big)
        return decoder.decode_32bit_float()
    
    client = ModbusTcpClient('warp2-22oH')
    client.connect()
    
    # Setze 12,345 A als Modbus-Ladestrom
    client.write_registers(1002, uint32_to_regs(12345))
    # Lies den Modbus-Ladestrom zurück
    print(regs_to_uint32(client.read_holding_registers(1002, 2)))
    
    # Lies den insgesamt erlaubten Ladestrom (allowed_charging_current)
    print(regs_to_uint32(client.read_input_registers(1010, 2)))

    EDIT: int -> uint

    • Thanks 1
  12. Firmware: WARP Energy Manager 1.0.1

    • Energiebilanz hinzugefügt
    • LED-Blinken in Magenta bei Konfigurationsfehlern hinzugefügt
    • Aggressives/Konservatives Regelverhalten hinzugefügt.
    • Phasenumschaltungs-Zustand zur Statusseite hinzugefügt
    • Anzeige interner Zustände zur Debug-Ansicht hinzugefügt
    • Core Dump zu Debug-Report hinzugefügt
    • Aussehen der Lademodus-Buttons verbessert
    • Veraltete Statuswerte nach Trennung der WLAN-Verbindung entfernt
    • Übersetzungen verbessert
    • Sichergestellt, dass Min­dest­lade­leistung für Min + PV-Modus nicht weniger als die für einen Ladevorgang notwendige Leistung sein kann
    • Nicht unterstützten SDM72CTM von der Stromzählerseite entfernt
    • Kontrollierte Wallboxen auf Statusseite zu klickbaren Links umgewandelt
    • Sichergestellt, dass keine duplizierten Hosts in Konfiguration kontrollierter Wallboxen akzeptiert werden
    • mDNS-Antworten die nicht von WARP Chargern gesendet wurden gefiltert
    • Zeichnen negativer und großer Leistungswerte behoben
    • Längenprüfung in Text- und Passwortfeldern repariert
    • Häufige Ereignis-Log-Meldungen behoben
    • Fehler-Feedback von Textfeldern repariert
    • Passwort-Platzhaltertext der WLAN-Verbindungsseite repariert
    • Löschen des WLAN-Verbindungspassworts repariert
    • Fehlende Stromzählerwerte auf Stromzähler-Unterseite repariert

    Download: WARP Energy Manager 1.0.1

  13. Wenn du Abstürze debuggen willst hast du noch zwei weitere Optionen:

    Du bekommst du auf der seriellen Konsole beim Crash einen Backtrace, den du mit dem decode-Script (in esp32-firmware/software) dekodieren kannst. Das Script wählt automatisch die zuletzt gebaute ELF-Datei aus um den Backtrace zu dekodieren. Du kannst noch den Inhalt des PC-Registers (das ist der Program Counter, also die Instruktion die gerade ausgeführt wird) vorne an den Backtrace anhängen, dann wirds genauer. Wenn du also z.B. folgenden Backtrace bekommst:

    Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
    
    Core  1 register dump:
    PC      : 0x40117aeb  PS      : 0x00060b30  A0      : 0x800ec077  A1      : 0x3ffc8e50  
    A2      : 0x3ffb6e74  A3      : 0x00000004  A4      : 0xffffffff  A5      : 0x3ffc8dc8  
    A6      : 0x3ffc8e70  A7      : 0x00000000  A8      : 0x80117ae9  A9      : 0x3ffc8de0  
    A10     : 0x505a9d89  A11     : 0x505a9d89  A12     : 0x3ffc5608  A13     : 0x3ffb513c  
    A14     : 0x3ffcef1c  A15     : 0x3ffc9970  SAR     : 0x00000015  EXCCAUSE: 0x0000001c  
    EXCVADDR: 0x00000004  LBEG    : 0x4000c46c  LEND    : 0x4000c477  LCOUNT  : 0x00000000  
    
    
    Backtrace: 0x40117ae8:0x3ffc8e50 0x400ec074:0x3ffc8e90 0x40179a1e:0x3ffc9190

    dann kannst du den (mit PC-Register) so dekodieren:

    ./decode 0x40117aeb 0x40117ae8:0x3ffc8e50 0x400ec074:0x3ffc8e90 0x40179a1e:0x3ffc9190

    und bekommst dann:

    Using toolchain-xtensa-esp32@8.4.0+2021r2-patch3 package
    0x00000000: ?? ??:0
    0x40117ae8: EVSEV2::setup() at /home/erik/Tinkerforge/esp32-firmware/software/src/modules/evse_v2/evse_v2.cpp:400
    0x400ec074: setup() at /home/erik/Tinkerforge/esp32-firmware/software/src/main.cpp:244
    0x40179a1e: loopTask(void*) at /home/erik/Tinkerforge/esp32-firmware/software/packages/arduino-esp32#warp2-2.0.9_9326b6026102e72489017bcf1c8fa08d0084e30f/cores/esp32/main.cpp:42

    evse_v2.cpp Zeile 400 ist bei mir gerade

    int blah = *((int*)0x04);
    logger.printfln("%d\n", blah);

    um den Crash zu provozieren.

    Option zwei ist, dass der ESP, wenn er crasht, seit kurzem einen Coredump in die entsprechende Partition schreibt. Wenn du das Debug-Modul reinkompilierst, dann kannst du unter warp2-abc/debug/coredump.elf den Coredump runterladen und mit https://github.com/espressif/esp-coredump auseinandernehmen.

×
×
  • Neu erstellen...