Paulkerl

@borg Vielen Dank die schnelle Antwort. Ich könnte mir vorstellen, dass die Lösung langfristig ggf. für "Verstimmungen" bei den Behörden führen könnte, wenn es zu einer Prüfung kommt. Kann mich aber auch täuschen. Ich denke, wir werden die privaten Tags ebenfalls in Powerfill anlegen und einer privaten Gruppe zuteilen. Nicht unsere präferierte Lösung, aber dennoch OK. Noch eine weitere Frage: wir wollen sicherstellen, dass bei Ausfall der Verbindung zum OCPP Backend dennoch geladen werden kann (zumindest bei den privaten Boxen). Gibt es hierfür so etwas wie ein AuthorizationCache in der Box den wir aktivieren können? Nochmals besten Dank für die Hilfe. P.

Hallo zusammen, wir nutzen die WARP4 Pro in Kombination mit powerfill.app und stehen vor folgendem Problem: Mitarbeiter mit privatem E-Auto sollen denselben Ladepunkt nutzen, die privaten Ladevorgänge sollen aber nicht über Powerfill abgerechnet werden (hier geht es um die private Wallboxen der Mitarbeiter mit Privatstrom). Problem: Powerfill verweigert den Ladevorgang, sobald ein TAG nicht in Powerfill hinterlegt ist – auch wenn dieser TAG lokal in der WARP4 Pro angelegt ist. Wir möchten vermeiden, private TAGs unserer Mitarbeiter in Powerfill zu pflegen. Unsere Wunschkonfiguration: Company-TAGs → werden an OCPP (Powerfill) weitergegeben → Abrechnung läuft normal Private TAGs → werden nur lokal verarbeitet → lokales Logging, lokale Aktivierung der Box, keine OCPP-Weitergabe Fragen: Ist eine solche Differenzierung in der WARP4 Pro konfigurierbar? Falls nicht – gibt es einen anderen empfohlenen Lösungsweg für diesen Use Case? Vielen Dank an euch. P.

Hallo zusammen, hat hier schonmal wer versucht oder es sogar geschafft, seine Warp2/3 zur Abrechnung an 50five anzubinden? Danke euch.

@cord Danke Dir, hatte das Downgrade auch schon im Kopf und nun durchgeführt. Ob es hilft, werde ich im Laufe der Woche wissen. VG P.

Hallo in die Runde, ich habe die erste Version des Energy Managers und die Warp2 Pro. ich habe vor zwei oder drei Tagen das aktuelle Update eingespielt. Überschuss laden steuere ich über EVCC. nun habe ich das Phänomen, dass wenn von 1 auf 3 beziehungsweise von 3 auf 1 Phasen umgestellt wird, das System erneut die NFC Weitergabe benötigt. Nachtrag: bisher hat die Phasenumschaltung einwandfrei funktioniert. Ohne weitere NFC Freigabe kennt das Phänomen jemand? Danke im Voraus, liebe Grüße P.

@ffreddow Danke für die schnelle Antwort. Das erkärt das Problem. Einen Reverseprxy werde ich dafür nciht extra bemühen. Dann verwende ich für die Warp und WEM weiterhin meinen VPN Zugang. VG D.

Hallo zusammen, ich verwende Cloudflare Zero Trust um auf meine Systeme zu Hause zuzugreifen. Somit auch auf meine Warp2Pro und WEM. Alle WebApps wie EVCC etc. sind auf diesem Weg verfügbar gemacht worden. Füge ich nun die Warp2 und WEM hinzu, meldet mein Browser: Header fields are too long. Schalte ich die Athentifizierung von cloudflare ab (also mache ich die Warp2/WEM ohne auth. öffenltich verfügbar), funktioniert die Oberfläche. Kann es sein, dass der Header von Haus aus schon recht "groß" ist und die größe "gesprengt" wird sobald noch der auth-Header von Cloudflare dazu kommt? Eine Idee, wie ich die Größe reduzieren kann? Leider kann bei CF nichts an der Größe ändern. Dank euch. VG D.

@the_muck & @rtrbt Hallo zusammen, es lag am tag type. Nun sende ich type 2 und es läuft. Danke euch!

Hallo @MatzeTF, besten Dank. Ich habe die Warp2 mal neu gestartet und dann nochmals versucht den Inject zu senden mit: curl -X POST http://192.168.98.243/nfc/inject_tag_start \ -H "Content-Type: application/json" \ -d '{"tag_type": 1, "tag_id": "04:0C:11:22:4B:76:80"}' \ -v im Anhang das LOG. warp2-22re-Debug-Report-2025-07-14T08-48-19-491.txt

Hallo zusammen, ich veruche meine Warp2 per API freizuschalten. Hier der Code: curl -X POST http://192.168.98.243/nfc/inject_tag_start \ -H "Content-Type: application/json" \ -d '{"tag_type": 1, "tag_id": "04:0C:11:22:4B:76:80"}' \ -v Das kommt zurück: Note: Unnecessary use of -X or --request, POST is already inferred. * Trying 192.168.98.243:80... * TCP_NODELAY set * Connected to 192.168.98.243 (192.168.98.243) port 80 (#0) > POST /nfc/inject_tag_start HTTP/1.1 > Host: 192.168.98.243 > User-Agent: curl/7.68.0 > Accept: */* > Content-Type: application/json > Content-Length: 49 > * upload completely sent off: 49 out of 49 bytes * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Content-Type: text/plain; charset=utf-8 < Content-Length: 0 < Connection: close < * Closing connection 0 Die Warp2 bleibt auf "Wartenauf Freigabe". Was mache ich falsch? Danke euch für eure Hilfe.

Hallo Matze, da ist definitiv etwas dran, was du sagst. Die Batterie bekommen wir nicht unter 30 % im Sommer. Wenn es kein Unterschied macht, ob ich mit zehn KW oder kontinuierlich mit 0.5 KW entlade ist das was du sagst definitiv richtig. Grüße und noch einen schönen Abend, Paul

Hallo Matze, Danke für die ausführliche Antwort. Was die Stromkosten etc. angeht, bin ich voll und ganz bei dir. Es ist egal wie man es dreht. Mir geht es eigentlich rein um die Lebensdauer des Akkus. Wir haben zwei E-Autos. Somit müssen wir fast täglich laden. Jedes Mal die Batterie leer machen geht mE auf die Lebensdauer. aktuell habe ich mir das Sperren der Batterie auch selber gebaut. Eine integrierte Lösung fände ich aber schöner. Nochmals vielen Dank für deine Antwort. Grüße Paul.

Hallo zusammen, hat hier vielleicht schonmal jemand versucht, den WarpCharger und/oder EnergyManager mit einem E3DC-Speicher (X10) zu verbinden? Ziel ist es, die Überschußlade-Logik von E3DC zu verwenden. Aktuell habe ich EVCC im Einsatz - was auch (meist) super funktioniert. Leider gibts da (noch) keine Steuerung um die Entladung des Batteriespeichers im Schnellade-/Ziellademodus zu sperren. Danke für euer Feedback. Vg Paul.

Hallo @MatzeTF, ich habe Mosquitto nun am laufen. Wie es aussieht, scheint es nun wieder zu funktionieren 🤞. Ich hoffe der Zustand ist dauerhaft. Nochmals besten Dank. VG Paul

Hallo Matze, besten Dank für Deine Antwort. Ich hatte schon die gleichen Gedanken bzgl. Mosquitto zu installieren und so zu testen. Werde ich wohl nun auch mal machen. Das System ist basiert auf einem Intel I5 mit recht viel Power. Alle Systemressourcen scheinen weit weg von Auslastung zu sein. Updates habe ich sowohl auf die aktuellen FWs von Tinkerforge als auch auf die aktuellen versionen/Adapter von IOBroker gemacht. Deshalb fällt es mir schwer zu sagen, woran es genau liegt.. Gefühlt hätte ich gesagt, als mit EVCC auf die 124.x gegangen bin. Aufgrund der Symptome schließe ich EVCC aber aus. Ich installiere die Tage mal Mosquitto und melde mich wieder zurück. VG Paul