Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.388
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Alle erstellten Inhalte von rtrbt

  1. Direkt geht das nicht. Du kannst aber über MQTT ein NFC-Tag vortäuschen: https://www.warp-charger.com/api.html#nfc_inject_tag Wenn OCPP dieses Tag kennt, sollte dann ein Ladevorgang beginnen.
  2. Im Moment geht das nicht so einfach. Wir haben aber vor zukünftig das Format der aufgezeichneten Ladevorgänge nochmal zu ändern. Dabei würde ich pro Ladevorgang ein Flag vorsehen, dass angibt, dass er gelöscht ist. Siehe hier: https://github.com/Tinkerforge/esp32-firmware/issues/329
  3. Teste mal diese WARP2-Firmware: Wenn das Auto nach der 4-Sekunden-Trennung nicht aufwacht, trennen wir jetzt nochmal für 30 Sekunden. Damit sollte es nicht mehr notwendig sein, dass du die Trennung des WEMs verlängerst. Hier hat jemand ein ähnliches Problem:https://github.com/evcc-io/evcc/issues/12480 warp2_firmware-NIGHTLY_2_2_1_65dca55f_2aa5b51ad4b2067_merged.bin
  4. 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)
  5. 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.
  6. 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
  7. @Makee Da du ja eine eigene Firmware baust: Ich habe den MQTTS-Support gerade gepusht. Sollte jetzt einfach funktionieren.
  8. 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.
  9. Das geht prinzipiell, indem du dir mehrere Regeln mit der selben Bedingung erstellst. Ist nicht super-hübsch, funktioniert aber. Das wiederum geht mit der aktuellen Implementierung nicht. Wir haben das erstmal einfach gehalten, für Use-Cases wie eine Zeitschaltung o.Ä. Prinzipiell immer, ich kann aber nicht versprechen, dass wir die dann auch umsetzen ;)
  10. rtrbt

    Veröffentlichungen

    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
  11. Nur um das auszuschließen: Hast du Sonderzeichen im Kennwort, die in der Shell escapt werden müssen? Du kannst es testweise mal auf "password" o.Ä. ändern.
  12. Kurzes Update dazu: Das Problem scheint ja zu sein, dass der Energy Manager nach einem Neustart blockiert, bis EVCC einmal einen Phasenwechsel anfordert. Das haben wir auf unserer Seite behoben, nach einem Neustart des WEM bleibt die letzte Phaseneinstellung erhalten. Kommt mit Firmware 2.0.2.
  13. Machen wir alles schon: https://github.com/Tinkerforge/evse-bricklet/blob/1892e31a648db0700fc45a944992ddc9f9077730/software/src/ads1118.c#L194
  14. Wir arbeiten dran :D 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.
  15. An den Energy Manager direkt kannst du von Eastron den SDM630, SDM630-MCT-V2, SDM72-V2, von Eltako den DSZ15DZMOD und von YTL den DEM4A anschließen. Außerdem kannst du alle SunSpec-kompatiblen Zähler über eine Netzwerkverbindung auslesen.
  16. 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.
  17. Kein Problem. energy_manager_firmware_2_0_1_65b77317_7046d2627114a44_merged.bin
  18. rtrbt

    Veröffentlichungen

    Firmware: WARP Energy Manager 2.0.1 Alte Stromzähler-API repariert Download: WARP Energy Manager 2.0.1
  19. Die Änderungen der Beta sind in der Energy Manager Firmware 2.0.0 btw. der Wallbox Firmware 2.2.0 enthalten. Achtung: Beim Update von der Beta-Firmware auf WEM 2.0.0 muss eventuell die Schützkontrolle neu auf externe Steuerung (EVCC) konfiguriert werden! Beim Update von 1.0.8 auf 2.0.0 passiert das automatisch.
  20. 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. Steht auf der Liste: https://github.com/Tinkerforge/esp32-firmware/issues/218
  21. Sorry für die späte Antwort, musste erst das Firmware-Release fertig bekommen. 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: (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 Ω Das sieht soweit gut aus. Du hast da aber auch 16 A freigegeben, teste sicherheitshalber bei Gelegenheit nochmal mit 6 A. 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: 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. 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. D.h. jetzt ist alles gut? :D
  22. rtrbt

    Veröffentlichungen

    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
  23. rtrbt

    Veröffentlichungen

    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...