floho

Guten Morgen, ja, der "Ton" kommt mir pampig rüber, auch wenn ein Grund dafür angeführt wird. Ich will hier nicht den Lehrer spielen, natürlich "darfst" Du das machen wie du willst. Ich denke: wenn man eine WB von "klassischen" Firmen kauft, werden Kundenwünsche in der Regel nicht umgesetzt, hier wird auf fast jeden Wunsch eingegangen. Dadurch entsteht wohl so eine Art Selbstverständnis dass alles umbesetzt werden muss, wie man es übrigens öfters bei Open Source und kundennahen Projekten beobachten kann. Gekauft wurde der ist-Zustand, der funktioniert. Somit ist diese Aufforderung keine Mangelbeseitigung, sondern ein Wunsch. Diese vermittle ich persönlich lieber nett ;-) Gruß und schönen ersten Advent, Florian. p.s. man hat sich ja auch für ein Open-Source Projekt entschieden ... also ran an den Speck Code ;-) Edit: oben steht geschrieben, dass die WB bei Änderung sendet und Änderungen sekündlich geprüft werden. Eventuell ist das gar nicht so einfach gemacht wie 1000 auf 5000 zu ändern im Code.

Wurde doch schon aufgenommen. Warum so pampig? Klingt zumindest für mich so. Ein workaround bis es soweit ist, ist wohl auch kein Angriff. schönen restlichen Abend, Florian.

Ich nehme mal an, dass der Zähler an die "RS485" beschriftete JST Buchse (4 Pins) angesteckt wird. Da die Kabel ja überall erhältlich sind würde es auch genügen wenn wir die Länge und Pinbelegung wüssten (weiß nicht ob ich mich auf die Farben verlassen möchte). Vielleicht kann einer das original Kabel zeigen, wenn zur Hand. Dann weiß man die Farben und die Länge ja. Danke und Gruß.

Hallo, gibt es hier etwas Neues? Ich habe aus einem früherem (gescheitertem) Projekt den SM630 hier. Nun würde ich mir gerne eine zweite WARP bestellen und dann natürlich "nur" die Smart. Würde daher gerne das JST Kabel gleich mitbestellen. Außerdem die Frage: Sind die Stromkabel welche am Klemmenblock der Smart angeschlossen sind und zu dem Schütz verlaufen gleich lang wie die die bei der PRO vom Zähler zum Schütz laufen? Oder muss ich hier neue, längere verlegen? Danke und Gruß, Florian

Naja, dann hätte ich mir das sparen können. Andererseits, auch kein Aufwand.

Laut API-Beschreibung (https://www.warp-charger.com/api.html#evse_auto_start_charging) passiert genau das nach einem Neustart. Ich habe es so gelöst dass, wenn die Wallbox erkannt wird, wird ein MQTT Kommando gesendet welches den Autostart abschaltet. Zusätzlich mache ich das alle 2 Stunden falls ein Neustart nicht korrekt erkannt wird und nach dem Neustart der Steuerung. Vielleicht wäre es aber sinnvoll wenn man diesen Zustand einfach persistent speichern würde in der Wallbox.

Ich denke die Dose muss verriegeln während des Ladens. Sonst könnte man unter Last den Stecker ziehen. Weiß nicht wie da die Vorgaben sind, kann mir aber nicht vorstellen, dass man das so machen sollte/darf. Zusätzlich ist bei diesem Typ 2 Steckern kaum eine Klemmung vorhanden. Sprich der geht echt leicht raus. edit: Ich habe hierzu noch ein wenig nachgelesen. Es ist wohl so, dass die Verriegelung mechanisch oder elektrisch gemacht werden muss. Sprich, die Wallbox, wenn nicht mechanisch verriegelt wird, muss das Abziehen durch den nachgeführten CP Kontakt erkennen und daraufhin den Schütz innerhalb einer vorgegebenen Zeit abschalten. Inwieweit das eine sicherheitsrelevante Bewertung braucht, weiß ich nicht. Ob die WARP das (spezifikationstechnisch ausreichend) tut weiß ich natürlich auch nicht. Alles in allem klingt das nicht nach einer sehr guten Lösung. Was spricht gegen eine Wanddurchführung des Kabels?

Das stimmt natürlich, solange man die Box einzeln betrachtet. Allerdings gibt es da Shellys, andere MQTT Sensoren, Gateways, mehrere Wallboxen, ... und es ist auch das WLAN welches belastet wird, nicht das LAN. Somit bin ich generell bei dir, fände aber dennoch eine Möglichkeit gut die zyklischen Daten nicht pauschal im vollen Set und sekündlich zu senden. Eine niederpriores Anliegen, aber wert überdacht zu werden ;-)

Wenn man das Kabel nicht über die Wallbox selbst führt ist das natürlich kein Problem. Wenn ich und das Wetter Lust haben schau ich nochmal in die Box und suche nach einer besser passenden Stelle. Ist aber tatsächlich sehr voll da drin (habe die PRO). Es funktioniert aber auch so schon relativ gut, der Tag muss eben ein wenig an dem Kabel vorbeigeführt werden. Wirklich schlimm ist das nicht, ich wollte den Gedankengang dennoch an andere Nachrüster weitergegeben haben.

Stimmt. Dar letzte erkannte Tag ist immer seen_tags[0], danke. Aus technischer Sicht habe ich keinerlei Probleme mit der aktuellen Implementierung, alles funktioniert bestens. Allerdings "sorge" ich mich ein wenig wegen des Traffics. Die Wallbox sendet im 1s Takt und der Payload wird immer größer. Und sie ist ja nicht der einzige MQTT/HTTP Teilnehmer. Daher dachte ich, dass für meinen Anwendungsfall z.B. die Tag-History nicht wirklich relevant ist, und schon gar nicht sekündlich. Die vergangenen Sekunden könnte man durch einen Timestamp ersetzen. Dann könnte man sich den Wert selbst errechnen. Andererseits kann so kein Ist-Zustand abgerufen wenden wenn man das einmalig gesendete Telegramm verpasst oder "vergessen" hat. Also auch keine so gute Lösung. Mein Vorschlag: Auch wenn das eher eine niedrige Priorität hat, vielleicht lässt sich in Zukunft auf der MQTT Seite eine erweiterte Konfig vornehmen: Sendeintervall abhängig vom Zustand der Wallbox. Z.B. im Idle jede Minute, während des Ladevorgangs weiter sekündlich abhängig von der Variable. Z.B. aktuelle Ladeleistung sekündlich, erkannte Tags eher langsamer. ... Zusammensetzung des Topic An- und Abwählen der einzelnen Bestandteile verschiedenen Formate ... Kann man beliebig aufblasen, klar. Wie gesagt, wenn Luft ist wäre das sicher eine nette Option, aber Dinge wie "Nutzer/Tagverwaltung" halte ich für wichtiger. Gruß und Danke, Florian

Ich hab nun in die WARP 1 das NFC Tool nachgerüstet. Dadurch werden per MQTT zyklisch diese Einträge versendet: Topic: warp/XXX/nfc/seen_tags Inhalt: [ {"tag_type":2,"tag_id":[1,2,3,4,5,6,7],"last_seen":1703665}, {"tag_type":0,"tag_id":[],"last_seen":0}, {"tag_type":0,"tag_id":[],"last_seen":0}, {"tag_type":0,"tag_id":[],"last_seen":0}, {"tag_type":0,"tag_id":[],"last_seen":0}, {"tag_type":0,"tag_id":[],"last_seen":0}, {"tag_type":0,"tag_id":[],"last_seen":0}, {"tag_type":0,"tag_id":[],"last_seen":0} ] Nun versuche ich das teil sinnvoll in HA zu integrieren. Ich dachte an ein Template mit dem Attributen "ID" und "last seen". Der Type ist eigentlich (für meinen Zweck) egal. Leider habe ich es bisher nicht hinbekommen. Vielleicht ist jemand hier firmer und hat eine Idee. Außerdem noch eine Frage an Tinkerforge: warum zyklisch? Und warum 8 Einträge? Kann es sein dass 8 Tags angelernt werden können und in einer fixen Liste gespeichert werden? Diese 8 Tags werden dann eben zyklisch gesendet? Aktuell habe ich nur einen Tag, daher kann ich es nicht empirisch ermitteln. EDIT: Nun habe ich einen zweiten NFC Tag gefunden. Offensichtlich werden in dem MQTT Topic einfach die letzen 8 gefundenen NFC - Tags gesendet. Da ich das ja direkt auswerte würde ich mir wünschen, dass man einstellen könnte dass einfach der letze erkannte Tag gesendet wird, nicht die letzen 8. Außerdem wäre es klasse wenn der Publisher nur nach dem Erkennen (gerne mehrmals) ein Nachricht sendet. So wird doch sehr viel Traffic erzeugt .... Gruß und Danke, Florian

Kam gerade an. Nach 5 Minuten Montage klappt es auf Anhieb. Super Sache ... jetzt also warten auf Tagspezifische Zählerstände ;-) Gruß, Florian p.s. Ein Nachteil bei Anbringen an der Oberseite ist, dass dort immer das Kabel im Weg ist (wenn das Auto sehr nah parkt ist noch eine Schlaufe um die Wallbox). Geht, ist aber nicht sehr komfortabel. Besser doch unten oder seitlich, da steht das Kabel etwas ab.

Ich hätte die Freigabe dennoch über RFID gemacht. Ein Separater Leser der dann über HomeAssistant die Freigabe macht. Eingebaut ist mir das dennoch lieber. Die Kosten sind auch kaum höher. Bin gespannt wie "leicht" man das in das PRO Gehäuse gefummelt bekommt :-)

Habe ich jetzt auch geordert. Bin gespannt was da noch an Funktionen kommt, aber so auch schon gut zum Starten (hängt bei uns frei zugänglich an der Hauswand).

🤚

Hat es schon jemand gemacht? Mich würde die Befestigung des NFC Moduls und die benötigte Kabellänge interessieren. Dann bin ich dabei :-)

Super, funktioniert tadellos. Danke. Eine Anmerkung habe ich. Ich würde die Sensoren wie folgt abändern: sensor: - platform: mqtt name: "Wallbox Leistung" state_topic: "warp/XXX/meter/state" value_template: "{{ value_json.power }}" device_class: power state_class: measurement unit_of_measurement: "W" - platform: mqtt name: "Wallbox Zählerstand" state_topic: "warp/XXX/meter/state" value_template: "{{ value_json.energy_abs }}" device_class: energy state_class: total unit_of_measurement: "kWh" Also die "state_class" Attribute einfügen. Dann wird das neue Energy Feature unterstützt und somit die Langzeitauswertung des Zählers. Gruß, Florian

Laut Anleitung ist doch sogar ein Typ A gefordert.

Tatsächlich finde ich den Halter auch sehr schick. Allerdings sehe ich den Vorteil gegenüber dem ersten Bild nicht ganz. Die Box selbst kann das doch auch?

Hübsch ;-)

Das muss so. Der Typ B erkennt einen DC Fehlerstrom und macht daraus einen AC Fehlerstrom den dann wiederum der Typ A im Sicherungskasten erkennt. Jetzt muss ich ein RTFM nachreichen ;-) https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf unter 2.4

Noch nicht. Aber ich plane das gleiche sobald ich die WB habe. Also schon mal zwei :-)