Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.388
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Posts erstellt von rtrbt

  1. On 2/19/2024 at 8:13 AM, eweri said:

    Im WARP Ereignis-Log finde ich folgende Einträge: um 17:34:05 habe ich den Wagen abgezogen und nach einiger Zeit wieder angesteckt - wie man sieht bleibt die WARP im Status 2 statt in 0 zu wechseln.

    Das ist sehr seltsam. Kannst du das nochmal machen und dabei ein Ladeprotokoll ziehen? (Also Auto normal laden lassen, dann Protokoll starten, dann Auto abziehen und warten, dass auf 2, aber nicht auf 0 gewechselt wird)

  2. This won't work. Android smartphones periodically change the NFC tag ID. The only way to change this (as far as I know) is to use some kind of NFC card emulation app that (depending on your smartphone) will only work if you root your phone. See for example here: https://stackoverflow.com/questions/19764476/host-based-card-emulation-with-fixed-card-id

    We've thought about not using a tag's ID but instead the first payload page (see here: https://github.com/Tinkerforge/esp32-firmware/issues/90) but nobody had the time to implement this yet.

  3. Sorry, ich hatte überlesen, dass du ein selbst-signiertes Zertifikat hast. Wenn du die Firmware mit dem Certs Back- und Frontend-Modul kompilierst, dann kannst du auf dem Webinterface das selbst-signierte Zertifikat hochladen und für die MQTT-Verbindung auswählen.

    Ohne das Certs-Modul wird nur das eingebettete Zertifikatsbundle verwendet. Das ist eine Sammlung von Root-Zertifikaten, mit denen der ESP Verbindungen zu Servern mit "echten" (also nicht selbst-signierten) Zertifikaten aufbauen kann: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_crt_bundle.html

  4. Du hast zwei Möglichkeiten:

    1. Kannst du die ganze Standardfirmware ignorieren und dir einen "normalen" Arduino-Sketch schreiben. Dokumentation dafür findest du hier: https://www.tinkerforge.com/de/doc/Software/API_Bindings_uC_HAL_Arduino_ESP32_Brick.html bzw. für den ESP32 Ethernet Brick hier:https://www.tinkerforge.com/de/doc/Software/API_Bindings_uC_HAL_Arduino_ESP32_Ethernet_Brick.html  Das ist für den Anfang einfacher, du musst aber die Netzwerk- und MQTT-verbindungen von Hand aufbauen oder dir eine MQTT-Bibliothek suchen.

    2. Kannst du dir die ESP-Firmware erweitern, dafür haben wir hier: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_ESP32_Firmware/Tutorial.html#tutorial-esp32-firmware ein Tutorial. Du müsstest im Endeffekt das Mqtt-Modul reinkompilieren (bei den custom_backend_modules und custom_frontend_modules jeweils zu der Liste hinzufügen) und dir ein eigenes Modul schreiben, dass die Sensoren ausliest und die Daten in eine API schreibt. Das ist im Tutorial Phase 2. APIs werden sowohl für die Kommunikation mit dem Webinterface über HTTP, als auch für MQTT verwendet. Das sollte also automatisch funktionieren. Der restliche Teil der Implementierung ist dann relativ ähnlich zu dem Arduino-Sketch den du dir in Variante 1 geschrieben hättest.

    In beiden Fällen benutzt du die C/C++-Bindings für Mikrocontroller für die Kommunikation mit den Bricklets (wir haben für jedes Bricklet Beispiele!), der Teil sollte also mehr oder weniger identisch aussehen.

  5. On 2/13/2024 at 1:40 PM, Smoki said:

    (dazu bräuchte man mehrere Aktionen pro Bedingung)

    Das geht prinzipiell, indem du dir mehrere Regeln mit der selben Bedingung erstellst. Ist nicht super-hübsch, funktioniert aber.

    On 2/13/2024 at 1:40 PM, Smoki said:

    Dazu müsste man aber mehrere Bedingungen für eine Aktion festlegen können.

    Das wiederum geht mit der aktuellen Implementierung nicht. Wir haben das erstmal einfach gehalten, für Use-Cases wie eine Zeitschaltung o.Ä.

    On 2/13/2024 at 2:23 PM, Smoki said:

    Sammelt ihr Erweiterungsvorschläge für diese Automatisierung?

    Prinzipiell immer, ich kann aber nicht versprechen, dass wir die dann auch umsetzen ;)

  6. Firmwares: WARP 2.2.1, WARP2 2.2.1 und  WARP Energy Manager 2.0.2

    • HTTP-API-Fehler bei schlechter Verbindungsqualität behoben
    • Zeitzonen-Datenbank aktualisiert
    • (nur WARP2) Repariert, dass DC-Fehler sporadisch auslöste (durch Update auf Ladecontroller-Firmware 2.2.2)
    • SunSpec: Herstellerspezifische Modelle werden nicht mehr als unbekannt angezeigt
    • SunSpec: Hängenden Scan unter spezifischen Fehlerbedingungen behoben
    • SunSpec: Hinzugefügt, dass Scan abgebrochen wird, wenn Browser-Tab geschlossen wird
    • (nur WARP Energy Manager) Hinzugefügt, dass externe Phasensteuerungsanforderungen über Neustarts hinweg erhalten bleiben
    • (nur WARP2) OCPP: LED-Steuerung hinzugefügt
    • (nur WARP2) OCPP: Antworten auf Server-Anfragen repariert
    • (nur WARP2) OCPP: Anzeige abgelehnter NFC-Tags zum Status hinzugefügt
    • (nur WARP2) OCPP: Wiederherstellung von Transaktionsnachrichten über Neustarts hinweg repariert
    • (nur WARP2) OCPP: Meldung falscher Zählerstände bei Transaktionsende über Neustarts hinweg repariert

    Download: WARP 2.2.1 bzw. WARP2 2.2.1 bzw. WARP Energy Manager 2.0.2

    • Like 1
  7. On 1/30/2024 at 2:56 PM, eweri said:

    🤢 wann ist die WARP3 verfügbar?

    Wir arbeiten dran :D

    On 1/30/2024 at 8:47 PM, eweri said:

    e-up von 16A runter, aber der e-up hat nur mit maximal 10A geladen (dafür müsste ich dann noch im Auto was änder)

    Das ist okay. Wie viel das Auto tatsächlich zieht, beeinflusst die Messung nicht. Relevant ist nur, dass das Auto prinzipiell lädt bzw. für die anderen beiden Debug-Protokolle, dass es voll ist und nicht laden möchte.

  8. Dann war die Kalibrierung für den e-up vermutlich zu stark. Damit wir dir eine bessere Kalibrierung erstellen können, müsstest du einmal alle relevanten Fälle wie folgt protokollieren:

    • 16 A Ladestrom einstellen
    • Ladeprotokoll starten
    • Auto anschließen
    • Warten bis es lädt
    • in 1-Ampere-Schritten bis auf 6 A runtergehen, dazwischen immer ~ 20 bis 30 Sekunden warten. Wenn du dich den 6 A näherst, kann es sein, dass du dann das Schütz-Ping-Pong triffst.

    Das ganze machst du mit dem e-up wenn er laden möchte, dann nochmal mit dem e-up wenn er voll ist und beides auch mit dem Hyundai. Das sollten also vier Protokolle werden, mit denen wir dir dann (hoffentlich! hat aber bisher immer geklappt) eine Kalibrierung erstellen können, bei der alles funktioniert.

  9. On 1/25/2024 at 6:45 PM, MatzeTF said:

    Dann hattest du vorher wahrscheinlich die Beta-Firmware installiert. Danach ist das zu erwarten.

    Ich hatte gestern nicht mehr daran gedacht, im Beta-Thread noch einen Hinweis darauf zu posten, sorry.

    Benutzt du EVCC mit dem Energy Manager? Dann musst du ggfalls ein paar Tage warten, wir mussten Teile der API ändern, die von EVCC verwendet werden. Habe die Entwickler schon informiert. Falls du irgendetwas eigenes mit der externen Steuerung machst: wem/xyz/energy_manager/external_control_update heißt jetzt wem/xyz/power_manager/external_control_update weil wir das Modul aufgeteilt haben.

    On 1/25/2024 at 9:05 PM, andyknownasabu said:

    Ich wünsche mir immer noch, ähnlich dem Charger, HomeAssistant MQTT-Autodiscovery für den EnergyManager. Soll ich dafür ein Issue auf GitHub aufmachen oder ist das schon auf eurer Liste?

    Steht auf der Liste: https://github.com/Tinkerforge/esp32-firmware/issues/218

    • Like 1
  10. Sorry für die späte Antwort, musste erst das Firmware-Release fertig bekommen.

    On 1/22/2024 at 9:08 PM, eweri said:

    macOS 13.6.3 (22G436) mit Safari Version 17.2.1 (18617.1.17.11.12, 18617) (keine aktiven Erweiterungen oder sonstige Manipulationen)

    Ziemlich genau die Version habe ich auch getestet und hier funktionierts. Wir haben aber von einem anderen Kunden ähnliche Probleme gemeldet bekommen mit anderen Browsern und Betriebssystemen. Da muss irgendetwas auf Wallboxseite kaputt sein.

     

    Kurz zur Erklärung, was überhaupt bei dem Ping-Pong passiert: Die Wallbox misst einen Widerstand (CP/PE), der vom Auto angelegt wird. Wenn kein Auto angeschlossen ist, ist das "unendlich", wenn ein Auto angeschlossen ist, aber (noch) keinen Strom anfordert sinds 2700 Ω, wenn das Auto Strom anfordert 880 Ω. Details hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung

    Aufgrund dessen, wie die Signalisierung funktioniert, wird der Widerstand immer nur in einem kurzen Zeitfenster gemessen, die Länge davon hängt vom erlaubten Ladestrom ab. Bei 6 A ist die Messung deshalb maximal schlecht: Vor der Kalibrierung hat deine Box immer irgendwas zwischen 1700 und 1800 Ω gemessen, da liegt aber genau die Grenze für die Wallbox. Insgesamt sah das dann so aus:

    image3.png

    (Rot mit rechter Achse der Widerstand, Blau mit linker Achse der Ladezustand. 1 ist "Auto will keinen Strom, Schütz nicht geschaltet", 2 ist "Auto will Strom, Schütz geschaltet")

    Die Kalibrierung, die wir dir gegeben haben schiebt deshalb den gemessenen Wert etwas nach Unten, er landet dann bei ~ 1300 Ω

    On 1/22/2024 at 9:24 PM, eweri said:

    Hier die Ergebnisse vom Hyundai vorher und nach der Installation der Kalibrierungsdatei

    Das sieht soweit gut aus. Du hast da aber auch 16 A freigegeben, teste sicherheitshalber bei Gelegenheit nochmal mit 6 A.

    On 1/22/2024 at 9:53 PM, eweri said:

    So ich also noch einmal nach draußen in die feuchte Kälte:

    Kabel vom e-up getrennt, wieder ins Haus, Protokoll starten, wieder zum e-up Lade-Timer abgeschaltet, Kabel gesteckt, NFC-Dongle drangehalten, es klackt sofort in der WARP und im e-up, und es klackt sofort wieder. Es lädt nicht. Irgend wie alles komisch ich halte noch einmal den Dongle an die WARP, es klackt wieder, diesmal lädt der e-up mit 2,7kW was ca. 5,6A entspricht. Eigentlich sollte der e-up aber mit 5A laden (nachträgliche Korrektur: 10A sind wohl richtiger, siehe Beitrag unten).

    Wenn man sich im Energieverbrauch vom Volkszähler das ansieht, dann war der erste Klack wirklich nur mit 2,3kW und der zweite Klack hat dann erst 2,7kW gemacht. 

    Ist jetzt evcc das Problem? Ich steige nicht so ganz mehr durch.

    Ich glaube, da hattest du einfach Pech mit dem NFC-Tag: Im Debug-Report sehe ich, dass genau als das Auto anfangen wollte zu laden, die Nutzerfreigabe blockiert hat:

    image.png

    Der Ladevorgang lief kurz, dann hast du vermutlich das Tag nochmal drangehalten, das stoppte den Ladevorgang und später hast du wieder freigegeben und es wurde weitergeladen. Während des ganzen Ladevorgangs hat EVCC auf 6 A limitiert. Das ist das Minimum, was die Wallbox dem Auto kommunizieren kann. D.h. wenn du im Auto 5 A einstellst, muss die Wallbox trotzdem 6 A erlauben und das Auto zieht dann halt weniger.

    On 1/22/2024 at 10:12 PM, eweri said:

    Wenn die 60% erreicht sind, wechselt die Lade-Steuerung wieder auf die Zeitsteuerung und die sagt "5A, 80% SoC und bitte um 6:50 Uhr fertig". Am Tage habe ich "32A, 80% SoC und bitte um 17 Uhr fertig" das in Verbindung mit evcc "Min+PV" sollte mir am Tag das Laden mit PV-Überschuss ermöglichen. 

    Mache ich einen Denkfehler?

    Nein, das sollte soweit funktionieren. EVCC gibt dir bei Min+PV ja mindestens 6 A + was an Überschuss da ist und das Auto sollte dann alles verwenden, wenn du es auf 32 A gestellt hast.

    On 1/24/2024 at 10:36 PM, eweri said:

    Heute Abend habe ich den e-up angesteckt und jetzt lädt er mit 5A komplett ohne Ping-Pong.

    D.h. jetzt ist alles gut? :D

  11. Firmware: WARP Energy Manager 2.0.0

    • Blogpost über die neuen Features, sowie aktualisierte API-Dokumentation folgen in Kürze.
    • API-Änderungen; möglicherweise sind Anpassungen an Software die mit der Wallbox interagiert notwendig!
    • API des energy_manager-Moduls in energy_manager und power_manager aufgeteilt
    • Automatisierung hinzugefügt
    • Unterstützung für WPA Enterprise (EAP-TLS, EAP-PEAP und EAP-TTLS) hinzugefügt
    • Stromzähler-Implementierung überarbeitet:
      • meters-API und Unterstützung von bis zu sieben Stromzählern hinzugefügt
      • Auslesen von SunSpec-Stromzählern und -Wechselrichtern hinzugefügt
      • Konfigurierbaren API-Stromzähler hinzugefügt
      • Unterstützung der Eltako DSZ15DZMOD und YTL DEM4A Stromzähler hinzugefügt
      • Zurücksetzbare Energie-Import- und -Export-Werte hinzugefügt
      • Fehlenden "Durchschnittliche Spannung gegen Neutralleiter"-Messwert des SDM72v2 hinzugefügt
    • Maximum der (lastgemanagten) Wallboxen auf 32 erhöht
    • Berechnung der verfügbaren Leistung im "Schnell"-Modus repariert
    • Wolkenfilter repariert
    • Übersetzungen verbessert
    • MQTT-Performance verbessert
    • WLAN-Access-Point-Performance, falls gleichzeitig eine WLAN-Verbindung aufgebaut wird, verbessert
    • Fehlermeldungen in Eingabefeldern verbessert
    • Unterstützung von TLS-Versionen vor 1.2 entfernt
    • Hinzugefügt, dass WLAN-Access-Point bei instabiler WLAN-Verbindung länger geöffnet bleibt
    • Sichergestellt, dass zum WLAN-AP mit der besten Empfangsqualität verbunden wird
    • Subnetz-Konfiguration des WLAN-Access-Points repariert
    • Sichergestellt, dass Lastmanagement erst Strom verteilt, wenn alle gesteuerten Wallboxen erreichbar sind
    • Sichergestellt, dass WLAN-HT40-Modus immer deaktiviert bleibt
    • Web-Interface-Labels die fehlende IDs referenzieren entfernt
    • Änderung eines konfigurierten TLS-Zertifikats repariert
    • Funktion des Zurück-Buttons bei Aufruf des Webinterfaces repariert
    • Tastatureingabe in Datumsfeldern repariert
    • Zeitzonen-Datenbank aktualisiert
    • Repariert, dass Watchdog des verfügbaren Stroms des Lastmanagements permanent auslöste
    • Sichergestellt, dass Analyse-Subplots nur dann versteckt werden, wenn keine Daten in beiden vorliegen

    Download: WARP Energy Manager 2.0.0

  12. Firmware: WARP 2.2.0 und WARP2 2.2.0

    • Blogpost über die neuen Features, sowie aktualisierte API-Dokumentation folgen in Kürze.
    • Automatisierung hinzugefügt
    • Unterstützung für WPA Enterprise (EAP-TLS, EAP-PEAP und EAP-TTLS) hinzugefügt
    • Stromzähler-Implementierung überarbeitet:
      • meters-API und Unterstützung von bis zu zwei Stromzählern hinzugefügt
      • Auslesen von SunSpec-Stromzählern und -Wechselrichtern hinzugefügt
      • Konfigurierbaren API-Stromzähler hinzugefügt
      • (nur WARP2) Unterstützung der Eltako DSZ15DZMOD und YTL DEM4A Stromzähler hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.0)
      • Zurücksetzbare Energie-Import- und -Export-Werte hinzugefügt
      • Ladetracker usw. verwenden jetzt Energie-Import- statt wie bisher Import+Export-Wert. Wechsel findet beim nächsten Löschen der Ladevorgänge statt.
      • Fehlenden "Durchschnittliche Spannung gegen Neutralleiter"-Messwert des SDM72v2 hinzugefügt
    • (nur WARP2) Maximum der (lastgemanagten) Wallboxen, NFC-Tags und Benutzern auf 32 erhöht
    • API um Ladelimits neuzustarten hinzugefügt
    • Ausgabe im Ereignislog für Zählerüberwachung hinzugefügt
    • (nur WARP2) OCPP-Transaktions-ID zu gemeldeten Stromzählerwerten hinzugefügt
    • Übersetzungen verbessert
    • MQTT-Performance verbessert
    • (nur WARP2) OCPP-Nutzerinterface verbessert
    • WLAN-Access-Point-Performance, falls gleichzeitig eine WLAN-Verbindung aufgebaut wird, verbessert
    • Fehlermeldungen in Eingabefeldern verbessert
    • (nur WARP2) DC-Fehler-Nutzerinterface verbessert. Unterstützung für X804-Sensor hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.0)
    • (nur WARP2) Diodenprüfung verbessert (durch Update auf Ladecontroller-Firmware 2.2.0)
    • Schütz- und PE-Fehler getrennt
    • Unterstützung von TLS-Versionen vor 1.2 entfernt
    • Hinzugefügt, dass WLAN-Access-Point bei instabiler WLAN-Verbindung länger geöffnet bleibt
    • Sichergestellt, dass zum WLAN-AP mit der besten Empfangsqualität verbunden wird
    • Subnetz-Konfiguration des WLAN-Access-Points repariert
    • Sichergestellt, dass Lastmanagement erst Strom verteilt, wenn alle gesteuerten Wallboxen erreichbar sind
    • Sichergestellt, dass WLAN-HT40-Modus immer deaktiviert bleibt
    • RFID-Tag-Register im Keba-Emulationsmodus ohne Stromzähler repariert
    • Web-Interface-Labels die fehlende IDs referenzieren entfernt
    • Änderung eines konfigurierten TLS-Zertifikats repariert
    • Reparatur der Zuordnung von NFC-Tags zu Nutzern beim Start der Wallbox hinzugefügt
    • Funktion des Zurück-Buttons bei Aufruf des Webinterfaces repariert
    • Tastatureingabe in Datumsfeldern repariert
    • Gemeldetes Intervall des Ladestroms in der MQTT-Auto-Discovery repariert
    • Zeitzonen-Datenbank aktualisiert
    • Anzeige der maximalen Anzahl von aufgezeichneten Ladevorgängen (7680) hinzugefügt
    • Repariert, dass Watchdog des verfügbaren Stroms des Lastmanagements permanent auslöste
    • Anzeige von LED-Blinkmustern während des Ladevorgangs erlaubt (durch Update auf Ladecontroller-Firmware 2.2.0 (WARP2) bzw. 2.1.9 (WARP1))
    • Sichergestellt, dass Ladevorgang nicht sofort blockiert wird, wenn die externe Steuerung aktiviert wird (durch Update auf Ladecontroller-Firmware 2.2.0 bzw. 2.1.9 (WARP1))

    Download: WARP 2.2.0 bzw. WARP2 2.2.0

×
×
  • Neu erstellen...