rtrbt
Administrators
-
Benutzer seit
-
Letzter Besuch
Alle erstellten Inhalte von rtrbt
-
Ab dem nächsten EVCC-Release musst du das Energy Manager Topic nicht mehr eintragen, WARP3 wird dann separat unterstützt: https://github.com/evcc-io/evcc/commit/dcb1f5c313d6ff3db8c78e4d309842ef5dc3aeb6 -
Das ist weniger eine Begründung, warum du das nicht tun solltest und mehr eine Erklärung, warum man das Offset des Boost-Modus nicht konfigurieren kann. Wenn ich einen Worst-Case konstruieren sollte, wäre das vermutlich, dass du für einen Zoe R135 kompensierst (sagen wir mal + 1,5A), und dann ein Model 3 (falls es das mit 22kW-Lader gibt, das habe ich gerade nicht im Kopf) anschließt: Das Model 3 zieht gerne mal 0,5A mehr, als du vorgibst, d.h. du könntest 2A über der Vorgabe liegen. Wenn dein LSS funktioniert und nicht rausfliegt, sollte (Achtung! Bin nur Software-Entwickler, kein Elektriker) nichts passieren, aber wenn dein Haus abbrennt oder deine Milch sauer wird, ö.Ä. bist du schuld :D
-
Je nachdem welche Art Zoe das ist musst du möglicherweise sehr stark korrigieren: Das ist der Ideale Ladestrom vs. was die Autos wirklich ziehen (die Daten rauschen etwas :D ). Wenn du selbst drin rumzoomen willst: https://github.com/Tinkerforge/warp-charger/blob/master/tools/current_ramp/allowed_vs_effective_3.gp D.h. wenn du z.b. einen R135 (gelb einphasig, orange dreiphasig) auf 16A zwingen willst, müsstest du ~ 17,25A vorgeben. Das ist aber wenn du ein anderes Auto anschließt viel zu viel. Der Boost-Modus so wie wir ihn implementiert haben ist genau so viel mehr, wie die Spezifikation das erlaubt.
-
Sorry, the WARP3 firmware release took a bit longer than expected. Please test the attached brickd package (you can install it with sudo dpkg -i brickd_2.4.5+snapshot~e70c9c6_arm64.deb ) I've rewritten the HAT specific code to use the GPIO's names (those will hopefully never change!) instead of their numbers. Edit: Attachment deleted. Brick Daemon 2.4.6 has been released. Please install the official release instead.
-
Firmware: WARP3 2.3.0 Erstes Release Download: WARP3 2.3.0
-
Firmware: WARP 2.3.0 und WARP2 2.3.0 (nur WARP2) PV-Überschussladen hinzugefügt (nur WARP2) Zweite längere CP-Trennung hinzugefügt, wenn Fahrzeug nicht innerhalb von 30 Sekunden reagiert (durch Update auf Ladecontroller-Firmware 2.2.3) (nur WARP2) “Limitiere auf 4200 W (§14 EnWG) wenn geöffnet/geschlossen” als Konfiguration des Abschalteingangs hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.3) (nur WARP2) Konfiguration der angeschlossenen Phasen hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.3) Unterstützung von MQTTS und MQTT über WS(S) hinzugefügt HTTP-Automatisierungsbedingung hinzugefügt Modal für WLAN-Scan-Ergebnisse hinzugefügt SunSpec: Unterstützung mehrerer Geräte im selben Registersatz hinzugefügt SunSpec: Unterstützung mehrerer Instanzen des selben Models in einem Gerät hinzugefügt SunSpec: Boot-Scan-Robustheit verbessert SunSpec: Skalierung des Leistungsfaktors repariert WiFi Enterprise: EAP-TLS-Verbindungen mit Client-Key repariert (nur WARP2) Repariert, dass Netzwerkeinstellungs-Reset mit dem Front-Taster nicht die HTTP-Anmeldung deaktiviert hat (nur WARP2) DSZ15DZMOD-Unterstützung der veralteten Stromzähler-API repariert Automatische Kanalauswahl des WLAN-Access Points repariert Anzeige aktiver Phasen bei negativem Phasenstrom repariert (nur WARP2) OCPP-Crash repariert, der auftrat, wenn vor Firmware 2.2.1 OCPP nie verwendet wurde (nur WARP2) Latenz von Leistungs- und Phasenstromwerten des angeschlossenen Zählers verbessert Lastmanagement: Steuerzykluszeit auf 5 Sekunden reduziert Lastmanagement: Spielraum des Phasenstroms verdoppelt wenn exakt eine Wallbox lädt Modulname zu Ereignislog-Nachrichten hinzugefügt Menüstruktur des Webinterfaces überarbeitet Label/Inhaltsteilung auf Status- und Unterseiten vereinheitlicht Platzhalter eingefügt, wenn Zeit der Echtzeituhr nicht gestellt ist Anzeige deaktivierter Automatisierungsbedingungen und -aktionen hinzugefügt Download: WARP 2.3.0 bzw. WARP2 2.3.0
-
-
-
Wir haben hier ein paar von denen https://www.meatpi.com/products/wican rumliegen. Leider hatte bisher noch keiner Zeit, die Anbindung dafür zu implementieren.
-
Der Charge Tracker benutzt die nicht zurücksetzbaren Werte. D.h. du brauchst die 209 wenn du seit Firmware 2.2.0 mindestens einmal die aufgezeichneten Ladevorgänge gelöscht hast. Falls du noch ältere Ladevorgänge hast, benutzt der Charge Tracker den Wert 213 Energy Active LSum ImExSum statt ... Import, also die Summe aus Import und Export. Das hatten wir in 2.2.0 geändert, aber damit in den Ladelogdateien kein Sprung entsteht, passiert der Wechsel erst wenn die Ladevorgänge einmal geleert werden. Siehe hier: https://www.tinkerforge.com/de/blog/new-features-in-warp2-221-and-wem-202/ (ganz unten) Wichtig, weil du das so geschrieben hast: 209 usw. sind nicht direkt Indices in meters/0/values, sondern am Index an dem in meters/0/value_ids die 209 steht, steht in /values der entsprechende Wert.
-
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.
-
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
-
Immer gerne. Ich bin gespannt ob's hilft.
-
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 Edit: Veraltete Firmware entfernt.
-
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)
-
Gefixt, danke für den Hinweis!
-
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.
-
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
-
@Makee Da du ja eine eigene Firmware baust: Ich habe den MQTTS-Support gerade gepusht. Sollte jetzt einfach funktionieren.
-
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.
-
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 ;)
-
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
-
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.
-
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.
-
Machen wir alles schon: https://github.com/Tinkerforge/evse-bricklet/blob/1892e31a648db0700fc45a944992ddc9f9077730/software/src/ads1118.c#L194
