rtrbt

Not Authorized als Fehler ist interessant. Hast du bei deinem MQTT-Broker Benutzername und Passwort konfiguriert? Dann musst du das in der EVCC-Konfiguration eintragen.

Frag ansonsten am besten auch mal im EVCC-Forum: https://github.com/evcc-io/evcc/discussions

Das sollte problemlos funktionieren. Callbacks bekommen immer alle verbundenen Clients, egal von welchem Host. Der Client muss aber auf das Callback registriert sein.

For that you can use the IP connection's enumerate callback. See here for an example:

https://www.tinkerforge.com/en/doc/Software/IPConnection_C.html#enumerate

This will report all connected Bricks and Bricklets with their UID and more.

On 10/3/2022 at 11:18 AM, gustavpaula said:

Ist noch unklar, warum es so viele Ladungen mit Dauer unter 1 Minute gibt (siehe Anhang)

Das ist wirklich interessant. Hattest du dazu schonmal was geschrieben? Wenn du das reproduzieren kannst würde mich ein Ladeprotokoll interessieren (kannst du auf der Ladecontroller-Unterseite erzeugen)

On 10/1/2022 at 10:52 AM, flozy said:

Gibt es Überlegungen, das man die Fahrzeuge wie bei ENBW AutoCharge oder beim Tesla Supercharger über das Einstecken erkennen kann?

Oder ist das überhaupt möglich?

Leider nicht. Die Fahrzeugerkennung läuft über https://de.wikipedia.org/wiki/ISO_15118, was ein extrem kompliziertes Protokoll ist, das von den ganzen Schnell-(Gleichstrom-)ladern implementiert wird. Das kann unsere Hardware nicht.

Die Kommunikation an den meisten Wallboxen (so auch am WARP Charger) läuft über https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung, was sehr viel einfacher funktioniert, aber nur den Fahrzeugstatus (will/darf laden) und den erlaubten Ladestrom kommunizieren kann.

Wenn du nicht direkt den Weg über NFC-Karten gehen willst, kannst du über die API des WARP Chargers NFC-Tags faken: https://www.warp-charger.com/api.html#nfc_inject_tag Da müsstest du dir aber selbst etwas programmieren.

Ja. Siehe z.b. hier:

Ja, es gibt eine erste Beta-Version hier:

Möglicherweise bist du zu ungeduldig:

Wenn du das Auto ansteckst sollte die LED an der Wallbox das "gib mir ein Tag"-Blinken machen. Wenn du das NFC-Tag an die Box hältst und sie das "bestätigende Blinken" macht, dann bleibt die Tag-Freigabe erhalten bis du das Auto abziehst. Die LED sollte dann nicht mehr blinken. Es kann jetzt aber sein, dass EVCC eine Weile braucht, bis die Ladung freigegeben wird.

Wenn du jetzt das Tag ein zweites Mal dranhältst sollte wieder das "bestätigende Blinken" kommen, danach macht die Wallbox aber wieder das "gib mir ein Tag"-Blinken. Die Wallbox interpretiert das Tag beim zweiten Mal also als wieder abmelden bzw. blockieren. (Hintergedanke ist, dass man das Tag auf das geladen wird wechseln können soll, ohne das Auto abzuziehen)

Du kannst im Webinterface übrigens sehen, was gerade das Laden blockiert: Einmal bei "Erlaubter Ladestrom" auf der Statusseite, da sollte 0 A durch Benutzer stehen wenn das Tag fehlt und 0A durch externe Steuerung wenn EVCC blockiert. Für Details gibt es unter Ladecontroller noch die Ladestromgrenzen.

Hattest du davor eine der Testversionen laufen, die wir im Forum veröffentlicht haben? Falls ja ist vermutlich die EVSE-Firmware-Versionsnummer durcheinander gekommen. Das kannst du ad-hoc testen, indem du im Webinterface unter Ladecontroller den Low-Level-Zustand aufklappst und da ganz unten auf "Neu flashen" klickst. Dann sollten die Meldungen aufhören.

Wenn das bei dir klappt, würde ich kurzerhand 2.0.9 veröffentlichen, mit einer reparierten Ladecontroller-Firmware-Versionsnummer. Das betrifft dann vermutlich auch alle die diese Firmware hier

installiert hatten.

Firmware: WARP2 2.0.90

Details hier:

ACHTUNG: Dieser Thread über die OCPP Unterstüzung ist veraltet, biete diesem Thread folgen:

Moin,

Die vergangenen Monate habe ich an einer OCPP-Implementierung für den WARP Charger gearbeitet. Als erste Vorschau hier eine Beta-Version.

Was funktioniert bereits?

Aktuell unterstützt wird das Core Profile von OCPP1.6J, folgende Funktionen sind mit einem OCPP-Server möglich:

• Starten/Stoppen von Ladevorgängen
• Autorisierung von Ladevorgängen über NFC-Tags
• Steuerung der Verfügbarkeit
• Anzeige des aktuellen Status der Wallbox
• Einstellen diverser Konfigurationen
• Übertragung von Zählerwerten an den Server
• Neustart der Wallbox

Es gibt noch ein paar Einschränkungen bezüglich der Zählerwert-Historie: Laut Spezifikation können Zählerwerte über einen Ladevorgang auf der Wallbox gesammelt werden und beim Ende des Ladevorgangs auf einmal übertragen werden. Das unterstützen wir derzeit nicht. Diese Einschränkung ist aber nach OCPP-Spezifikation erlaubt, sollte also hoffentlich bei keinem Server zu Problemem führen.

Bisher ist die OCPP-Implementierung mit SteVe 3.4.9: (https://github.com/steve-community/steve) sowie https://web.ecarup.com/ erfolgreich getestet worden. Weitere OCPP-Server werden wir im Zuge der Weiterentwicklung testen.

Was fehlt?

Neben den genannten Einschänkungen bzgl. der Zähler-Historie fehlen noch folgende (geplante) Features bzw. bestehen folgende Probleme:

• Bessere Einbindung ins Webinterface: Aktuell kann OCPP aktiviert, sowie die Server-URL eingetragen werden. Außer im Ereignis-Log gibt es kein Feedback über den OCPP-Betrieb.
• Entkopplung in eine eigene Ladestromgrenze: Aktuell benutzt OCPP die "externe Steuerung"-Ladegrenze, blockiert damit also andere Steuerungen wie z.B. EVCC oder eigene Scripte. Wir werden deshalb OCPP eine eigene Ladestromgrenze zuweisen.
• Bessere Verzahnung mit anderen Features der Wallbox: Im Moment läuft OCPP komplett parallel neben anderen Features wie der NFC-Tag/Benutzerverwaltung. Künftig werden diese Funktionen stärker gekoppelt, sodass z.B. nur entweder die Ladefreigabe per OCPP, oder die lokale Freigabe per NFC-Tag aktiv ist, um Verwirrung zu vermeiden.
• Um weitere OCPP-Server (z.B. EVCC) zu unterstützen, werden wir möglicherweise weitere Profile, insbesondere das Smart Charging Profile, mit dem Ladeströme gesteuert werden können, implementieren.

Wie kann ich die OCPP-Implementierung testen?

Zum Testen wird ein OCPP-Server benötigt. Lokal kann SteVe (siehe oben) ausgeführt werden. Alternativ bietet https://web.ecarup.com kostenlose Accounts an.

Nach dem Flashen der Beta-Firmware steht im Webinterface der neue Menüpunkt OCPP zur Verfügung. Hier kann die URL des Endpoints eingetragen werden. Es werden sowohl ws (WebSocket), als auch wss (WebSocketSecure)-URLS unterstützt. Wir empfehlen zweiteres, damit die Kommunikation verschlüsselt stattfindet. Die Firmware beinhaltet ein Zertifikats-Bundle mit den üblichen Root-Zertifikaten (siehe hier für Details). In einer späteren Version werden wir hinzufügen, dass ein eigenes TLS-Zertifikat auf die Wallbox hochgeladen werden kann.

Neben dem Aktivieren von OCPP und dem Eintragen der Endpoint-URL muss im Moment außerdem unter Ladecontroller die externe Steuerung aktiviert werden.

Bei einem erfolgreichen Verbindungsaufbau sollten Nachrichten ähnlich zu den folgenden im Ereignis-Log auftauchen:

                  5,790  Sending boot notification. 5790 0 60000 60000
                  5,801  Sending status Available for connector 1
                  5,933  Received message [3, "0", {"status":"Accepted","currentTi
2022-09-14 15:45:33,000  Sending status Available for charge point
2022-09-14 15:45:33,011  Sending status Available for connector 1
2022-09-14 15:45:33,183  Received message [3, "2", {}]
2022-09-14 15:45:33,298  Received message [3, "3", {}]

und der OCPP-Server die Wallbox registrieren.

Warum nur für WARP2?

Der ESP32 Brick, der in der WARP1 verbaut ist, verfügt über 320kB RAM. Der ESP32 Ethernet Brick der in der WARP2 verbaut ist hat zusätzliche 4MB PSRAM. In aktuellen WARP1-Firmwares ist der verfügbare RAM zu knapp für die OCPP-Implementierung. Im Moment ist unklar, ob OCPP auf der WARP1 möglich sein wird.

warp2_firmware_2_0_90_6321dac1_merged.bin

On 9/12/2022 at 11:35 PM, eweri said:

4. An der WARP1 mit Benutzer und Passwort angemeldet und den Ladevorgang gestartet -> "Unbekannter Benutzer" 

Ich hätte mit einer anderen Reaktion gerechnet. Oder muss man sich erst an der WARP1 anmelden, dann das Fahrzeug anschließe und dann den Ladevorgang starten? Gerade ausprobiert, hat auch nicht funktioniert. 

Jemand schon weiter gekommen?

Im Moment kannst du Ladevorgänge nur über NFC Benutzern zuordnen. Es gibt aber die Möglichkeit, ein NFC-Tag nicht physisch vor die Box zu halten sondern per API vorzutäuschen. Das ist auch was EVCC tut. (Das funktioniert im Moment aber nur wenn zumindest ein NFC-Bricklet angeschlossen ist: https://github.com/Tinkerforge/esp32-firmware/issues/133)

Ladevorgänge über das Webinterface Nutzern zuzuordnen ist im Moment noch nicht implementiert, steht aber auf der TODO-Liste (und jetzt auch in einem Issue, das fehlte seltsamerweise: https://github.com/Tinkerforge/esp32-firmware/issues/161)

Moin eweri,

Auf dem Firmen-Mac funktionierts mit genau dieser Firmware-, macOS- und Safari-Version. Hast du das Problem mit Firmware 2.0.7 (gerade frisch veröffentlicht, deshalb die späte Rückmeldung) immer noch? Falls nein: Drück mal Command+Option+I, geh auf Konsole und versuche dann nochmal das Ladelog runterzuladen. Bekommst du da irgendwelche Meldungen ausgegeben?

On 9/11/2022 at 9:30 AM, gustavpaula said:

Beim Abstecken des WLAN Bricklets beachten: das 7p Kabel kommt nachher wieder an die UNTERE Buchse auf der linken Seite, an die OBERE wird das 7p Kabel für das RS-485 Bricklet angesteckt! (Da hab ich nicht drauf geachtet und NICHTS im Internet gefunden, wo was hinkommt...)

Dem ESP ist egal an welchen Port du RS485, NFC und EVSE Bricklet anschließt ;)

On 9/11/2022 at 9:30 AM, gustavpaula said:

(z.B. SDM630). So einen hatte ich aber nicht rumliegen. (sehe gerade, dass der SDM72D-M v2 das nun auch kann). Aber kann das auch schon die Warp SW? Irgendwo hab ich "proto-version" gelesen.

Die Software unterstützt beide. Das Issue (https://github.com/Tinkerforge/esp32-firmware/issues/134 ) dafür ist noch offen, weil die Detektion, ob ein Zähler vorhanden ist, nicht so robust ist wie ich das gerne hätte. Ich räume das mal kurz auf. Edit: jetzt hier: https://github.com/Tinkerforge/esp32-firmware/issues/160

On 9/11/2022 at 9:39 AM, gustavpaula said:

Wenn die Warp beim Neustart das Licht des SDM72 abschalten bzw. auf 1 Min. leuchten stellen könnte, damit die WB nicht dauernd von innen beleuchtet wird.

Ist notiert. https://github.com/Tinkerforge/esp32-firmware/issues/159

On 9/9/2022 at 10:32 AM, gustavpaula said:

Falls hier noch jemand vom Entwicklerteam mitliest:

Die "freigeben" Buttons bei den Ladestromgrenzen sollen m.E. ausgegraut/inaktiv sein, wenn bereits freigegeben ist. Oder die Buttons nur anzeigen, wenn man tatsächlich freigeben kann.

Gute Idee! https://github.com/Tinkerforge/esp32-firmware/issues/158

On 9/9/2022 at 10:32 AM, gustavpaula said:

Nach Ladebeginn probiert der EVCC auch viel zu lange unterschiedl. Ladeströme aus und dabei klackert das Warp-Schütz auch ständig. Solange, bis der e-up anscheinend an eine Störung der Wallbox glaubt und die Zusammenarbeit einstellt.

Das klingt seltsam. Bekommst du aus den EVCC-Logs raus welche Ladeströme gesetzt werden?

On 9/9/2022 at 10:32 AM, gustavpaula said:

und da werden auch Ladeströme mit 3 Nachkommastellen am Warp Status -> erlaubter ladestrom angezeigt, ich dachte, da darf nur in 1A Schritten variiert werden??

1A ist nur der Default-"Sprung", 3 Nachkommastellen sind erlaubt.

Noch ein Gedanke: Hast du Auto-Start wieder aktiviert? Sonst kommt EVCC vermutlich durcheinander. (Auto-Start ist unabhängig von der externen Steuerung)

Das funktioniert soweit, wenn du den Ioniq nicht erst nach 22 Uhr anschließt. Das start_charging würde in dem Fall nicht funktionieren, weil es ignoriert wird, wenn kein Auto angeschlossen ist.

Du kannst aber folgendes machen:

22:00 curl -X PUT -d 32000 http://warp2.fritz.box/evse/external_current_update
06:00 curl -X PUT -d 0 http://warp2.fritz.box/evse/external_current_update

(musst dann aber die externe Steuerung im Webinterface unter Ladecontroller aktivieren).

Moin,

Für OCPP kommt hoffentlich heute noch (spätestens morgen, muss zwei Wochen Forum usw. aufholen) eine erste Test-Version. Hatte es vor meinem Urlaub nicht mehr geschafft.

Grüße,
Erik

Klappt es mit der Firmware aus diesem Post?

Dann ist es wirklich ein Genauigkeitsproblem beim PWM-Signal. Je nachdem wie das Auto (was ist das btw für eins?) das PWM misst könnte diese Firmware helfen.

Das ist leider etwas kompliziert: Die Ladezeit auf der Statusseite berechnen wir über den aktuellen Zeitpunkt (seit Start der Wallbox) und benutzen die echte Zeit deines Browsers.

Für den Ladetracker braucht die Wallbox selbst die aktuelle Zeit, die sie sich per NTP, also Netzwerkzeitsynchronisierung besorgt. Dafür braucht die Wallbox die Möglichkeit, einen Zeitserver zu erreichen. Passen eventuell die Netzwerkeinstellungen nicht? (z.B.: statische IPs aber kein DNS-Server eingetragen)

Falls du die Wallbox nicht ins Internet lassen willst, aber z.B. eine Fritzbox als Router in deinem Heimnetz hast, kannst du die IP der Fritzbox (typischerweise 192.168.178.1 ) als Zeitserver eintragen.

Künftig wird das auch komplett ohne Netzwerk gehen, wenn du ein Real-Time-Clock-Bricklet einbaust: https://github.com/Tinkerforge/esp32-firmware/issues/26 Das ist aber noch nicht implementiert.

Vermutlich war Teil des Problems, dass du (zmdst laut dem debug-report) Auto-Start deaktiviert hattest. Das hat nichts mit der externen Steuerung zutun, sondern ist nur dafür da, dass du selbst per API oder Webinterface den Ladevorgang freigeben kannst.

19 hours ago, Dosepower said:

wie wird der Zähler ausgelesen/ins System eingebunden?

Du brauchst, damit der Zähler von der WARP 1 ausgelesen werden kann noch ein RS485 Bricklet: https://www.tinkerforge.com/de/shop/rs485-bricklet.html und, damit du ihn sinnvoll einbauen kannst, den Berührschutz mit dem entsprechenden Ausschnitt. (Der Klemmenblock ist nicht so hoch wie der Zähler, deshalb ist da kein Loch bei der Smart) Dafür müsstest du eine Mail an info@tinkerforge.com schicken, am besten mit einem Hinweis auf den Foren-Thread hier wegen Kontext.

Für NFC brauchst du das Bricklet und das 15cm-Kabel, das ist korrekt.

19 hours ago, Dosepower said:

oder lieber gleich warp 2 pro kaufen?

Da werde ich dich nicht von abhalten ;)

On 8/13/2022 at 8:18 PM, Loïc G. said:

I think it can be done in a better way using a pointer instead of a array of 255 uint8_t elements

Nope, you have to pass a buffer with enough space for 256(!) entries. The station IDs are collected in this buffer and the Bricklet can detect up to 256 stations.

Theoretically you cound call

tf_outdoor_weather_get_station_identifiers(&this->ow, nullptr, &station_nb);

first to get the number of stations and then creating a buffer that is large enough, for example with

uint8_t *stations_id = (uint8_t*) malloc(stations_nb * sizeof(uint8_t));

However this is dangerous, as the Bricklet could receive another new station after the call to get the number of stations, but before the second call to get the station IDs. So don't do this!

Yeah, the MQTT bindings map 1:1 to the Bricklet API, so they are more complicated to use.

On 8/9/2022 at 8:59 AM, Pat28 said:

"tinkerforge/request/nfc_bricklet/Y2U/simple_get_tag_id": {"index": 0, "tag_type": 2, "tag_id": 0, "last_seen": 0},

tag_type, id and last_seen are the response values, you only have to pass the index.

For example if you put a tag on the bricklet and then send (Remember to switch to simple mode before doing this)

Quote

 "tinkerforge/request/nfc_bricklet/Y2U/simple_get_tag_id": {"index": 0}

you should get a response like this:

Quote

 "tinkerforge/response/nfc_bricklet/Y2U/simple_get_tag_id": {"tag_type": 2, "tag_id": "01:23:45:67", "last_seen": 123}

On 8/9/2022 at 8:59 AM, Pat28 said:

"tinkerforge/register/motion_detector_v2_bricklet/MPc/motion_detected": {"register": true}

This looks okay. What errors are you getting?

On 8/9/2022 at 8:59 AM, Pat28 said:

On every bricklet MQTT you have an example at the top off the document, but never in the api section. 

Those are examples showing how to use the API?

Wenn du auf Ethernet verzichten kannst, ist es vermutlich sinnvoll, nur NFC und Stromzähler nachzurüsten.

Wenn du von v1 auf v2 aufrüsten willst, musst du im Endeffekt alles außer Gehäuse, Schütz und Typ-2-Kabel wechseln. Das kannst du anhand der Ersatzteile https://www.tinkerforge.com/de/shop/warp/warp2-spare-parts.html durchrechnen, ich komme auf grob 450€ bzw. 650€ wenn du gleich auf Pro wechseln willst.

Du kannst natürlich erstmal NFC und Zähler nachrüsten und wenn du später beschließt doch Ethernet bzw. den neueren Ladecontroller haben zu wollen, kannst du den Rest immer noch nachkaufen ;)