rtrbt

Noch eine Ergänzung dazu: Wenn die Wallbox das erste Mal einen Zähler sieht, aktiviert sie die Zählerüberwachung. Danach sind Ladevorgänge nur noch möglich, wenn der Zähler ausgelesen werden kann. D.h. wenn jemand den Zähler ausbaut ö.Ä. blockiert die Wallbox das Laden. Die Zählerüberwachung kannst du im Webinterface deaktivieren, falls du deine WARP3 Pro auf eine Smart downgraden willst, oder der Zähler wirklich kaputt ist.

Stimmt, das war noch privat. Sollte jetzt sichtbar sein.

On 4/17/2024 at 11:25 PM, ecthelion said:

Wie muss evcc hier denn konfiguriert werden, damit die automatische Phasenumschaltung funktioniert?

On 4/18/2024 at 1:41 AM, MatzeTF said:

Bei den EVCC-Einstellungen musst du den Eintrag für den Energy Manager hinzufügen und dafür das gleiche Topic eintragen wie für die Wallbox, da sie das Feature integriert hat.

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

On 4/17/2024 at 1:31 PM, poohnet said:

Dass ihr WARP nur gemäß Spezifikation ausliefern könnt, ist absolut verständlich, aber welche Gefahr würde denn bestehen, wenn ich tatsächlich 17A vorgebe?

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.

brickd_2.4.5+snapshot~e70c9c6_arm64.deb

No, because Brick Daemon ignores the configured GPIO numbers if a HAT is detected.

It seems like kernel 6.6 changed the GPIO numbers again. https://github.com/raspberrypi/linux/issues/6037 We have to update Brick Daemon for the new GPIO numbers, probably next week.

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.

On 3/15/2024 at 10:34 PM, borg said:

Eventuell kannst du über MQTT die OCPP-Ladegrenze ändern, da bin ich mir nicht sicher.

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

warp2_firmware-NIGHTLY_2_2_1_65dca55f_2aa5b51ad4b2067_merged.bin

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)

On 2/19/2024 at 6:30 AM, Eddi said:

In der API scheint sich ein Tippfehler eingeschlichen zu haben.. 
mit energy_manager/charge_mode_update konnte ich die Modi nicht umstellen. Mit power_manager/charge_mode ging es dann. 

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.

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 ;)

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.