Rangliste

Edit: Wer nur auf der Suche nach den aktuellen Binaries der wie unten beschriebenen modifizierten Firmware ist und nicht den ganzen Thread durchschauen möchte, bitte hier lang: https://github.com/mattsches1/esp32-firmware/releases --- Hallo zusammen, ich nutze mal den verregneten Abend, um das Umbauprojekt an meiner WARP 1 vorzustellen. Es gab ja hier im Forum schon mehrere Diskussionen zum Thema Phasenumschaltung, vielleicht ist das ja für den einen oder anderen interessant. Mein Ziel war es, eine Phasenumschaltung direkt in die Wallbox zu integrieren, um ein optimiertes Überschussladen von unserer PV-Anlage zu erreichen. Über meine Haussteuerung wollte ich dabei nur die Ladeleistung vorgeben, und die Box sollte selbständig die passende Zahl zu schaltender Phasen bestimmen. Das heißt, ich wollte ohne weitere Hardware wie zusätzlicher Zähler, Umschalteinrichtung oder was auch immer auskommen. Erreicht habe ich mein Ziel im Wesentlichen durch Austausch des vierpoligen Schützes gegen drei zweipolige Ergänzung je eines Industrial Quad Relay und Digital In Bricklets Ergänzung eines Softwaremoduls zur Bereitstellung der zusätzlichen API-Endpunkte, Ansteuerung der Bricklets und des EVSEs Eine CP-Trennung wäre sicher über das Industrial Quad Relay möglich, habe ich mir aber gespart, nachdem unser Auto sie offenbar nicht benötigt. Auf den angehängten Bildern ist der Umbau zu sehen und ein Screenshot des neuen Moduls. Zum Zeitpunkt des Screenshots war der Ladevorgang beendet, es hätte aber noch mit gut 4200 Watt geladen werden können, also mit drei Phasen (daher "Angeforderte Phasen" auf "Drei"). Die Nutzung ist nun recht simpel: Meine Haussteuerung errechnet aus aktueller Ladeleistung + aktueller Einspeisung ins Netz (=aktuellem Überschuss) die neue Ladeleistungsvorgabe und schickt sie per HTTP API an die Box. Dabei habe ich eine Hysterese von 50 Watt vorgesehen, erst wenn sich der Sollwert also um mindestens diesen Betrag geändert hat, wird eine neue Vorgabe gemacht. Das ist aber alles Geschmackssache und erfolgt sozusagen bauseits. Anders ausgedrückt: Für die Ermittlung der gewünschten Ladeleistung ist die Infrastruktur verantwortlich, nicht die Box. Übersteigt nun die Leistungsvorgabe die Grenze, ab der mit einer höheren Phasenanzahl geladen werden kann (mit Mindeststrom 6 A), erfolgt die Umschaltung. Und umgekehrt, wenn die Leistungsvorgabe darunter sinkt. Dabei muss die Leistungsvorgabe mindestens eine einstellbare Zeit über oder unter der Schaltgrenze liegen ("Verzögerungszeit", siehe Screenshot). Zudem wird die aktuelle Phasenanzahl unabhängig von der Leistungsvorgabe immer für eine gewisse Mindestdauer gehalten. Das mache ich, um ein zu hektisches Umschalten z. B. bei Wolken oder Lastwechseln im Haus zu vermeiden. Sonst geht zumindest unser Flitzer in Ladestörung. Ich habe das Modul dabei zur Zeit eher defensiv eingestellt, so dass relativ zügig zurück- aber eher spät hochgeschaltet wird (um Netzbezug möglichst zu vermeiden). Die Pause zwischen Stopp und erneutem Start des Ladevorgangs ist ebenfalls einstellbar. Der Parameter "Betriebsart" bestimmt, wie viele und welche Phasen überhaupt genutzt werden sollen. Einstellbar sind: Nur einphasig (also keine Umschaltung) Nur zweiphasig Nur dreiphasig Ein-/zweiphasig Ein-/dreiphasig Ein-/zwei-/dreiphasig Ideal wäre es natürlich, wenn das Auto auch mit zwei Phasen geladen werden kann. Geht bei unserem nicht, daher habe ich "Ein-/dreiphasig" in Betrieb. Insgesamt funktioniert das bisher ganz prima. Im Diagramm auf dem Screenshot seht ihr in blau die Leistungsvorgabe. Grün ist die tatsächliche Ladeleistung, grau die Mindestleistung für die aktuell genutzte Phasenanzahl. Gut zu erkennen ist, wie ab ca. 8:20 Uhr die Ladeleistung trotz steigender Vorgabe konstant bleibt. Ich habe die Box wegen der Zuleitung auf 13 A gedrosselt, hier war das Maximum von knapp 3000 W erreicht. Ab ca. 10 Uhr war dann die Mindestleistung für drei Phasen lange genug überschritten, so dass die Umschaltung eingeleitet wurde. Gegen 11:30 Uhr lief die Spülmaschine, aber es reichte weiterhin für dreiphasiges Laden. Ebenfalls bei den dann aufkommenden Wolken. Um 12:45 Uhr war dann der gewünschte Ladestand erreicht. Weiter war mir noch wichtig, den ganzen Mechanismus übersteuern zu können, "wenn's mal bressiert". Wird der Leuchttaster nun lange gedrückt, startet der Ladevorgang sofort mit der maximal eingestellten Phasenzahl und voller Leistung. Die Phasenumschaltung ist dann für diesen Ladevorgang deaktiviert, und die Leistungsvorgabe wird ignoriert. Wer sich den Source Code reinziehen will, kann das gerne hier tun. Ich halte den Stand zur Zeit ziemlich aktuell, derzeit bin ich auf der Version 2.0.5. Weitere Infos und/oder eine compilierte Version der Firmware gibt es gerne bei Bedarf. Für jetzt ist der Roman erst mal lang genug. Abschließend sei nur noch bemerkt, dass für einen solchen Umbau die entsprechende Sachkenntnis vorausgesetzt wird und das erforderliche Werkzeug vorhanden sein muss. Wer hier anpackt, tut das auf eigene Gefahr! Cheers, mattsches P. S. Herzlichen Dank an dieser Stelle an Erik (rtrbt) für die stets schnelle, freundliche und kompetente Unterstützung! Cool, mit welcher Offenheit ihr hier solchen Aktionen gegenübersteht!

Hallo Leute, Die neuen WARP3 Charger sind nun im Shop: https://www.tinkerforge.com/de/shop/warp/wallbox.html Einmal die Innenansicht der finalen Version wie sie jetzt ausgeliefert wird. Die Box kommt jetzt mit einem wertigeren Zähler, zwei Schützen für die Phasenumschaltung und neue EVSE/ESP Bricklets vertikal im Huckepack. Es gibt jetzt immer Anschlussklemmen für den Elektriker und der LED Button (hier nicht im Bild) kann jetzt RGB statt nur blau. Es war jetzt vor Ostern doch alles ein bisschen knapp geworden, aber wir hatten vielen Leuten versprochen das man ab heute vorbestellen kann, daher wollten wir es jetzt auch durchziehen. Die Shopeinträge und die neue Homepage sind noch nicht komplett fertig. So fehlen im Shop noch ein paar Fotos und Beschreibungen der Zubehörteile und als größere Änderung auf der Homepage planen wir eine Trennung zwischen der Homepage und der Dokumentation. In Zukunft soll warp-charger.com mehr als "Landingpage" für Neukunden sein mit vielen Anwendungsbeispielen und Erklärungen die weniger technisch sind. Zusätzlich wird eine neue Dokumentationsseite aufgebaut (die ist nicht rechtzeitig fertig geworden leider, aktuell gibt es erstmal noch die alte API-Doku). Dort soll die API und andere technische Merkmale und Konfigurationsmöglichkeiten besser dargestellt werden mit mehr Beispielen etc. Diese Seite ist dann mehr für die Bestandskunden gedacht, die mit ihrer Wallbox irgendwas machen wollen und nachschauen möchten wie das geht. Das wird jetzt Stück für Stück fertig gestellt. Wenn die ersten Wallboxen in den Versand gehen wird das sicher alles schon viel ordentlicher aussehen! An der Stelle einmal der Hinweis das wir beim Erstellen der neuen WARP3 Betriebsanleitung auch die WARP2 Betriebsanleitung nochmal auf den neuesten Stand gebracht haben. Dort sollten jetzt nach aktuellem Stand wieder alle Hardware- und Firmwarefeatures beschrieben sein! Es wird dann wenn alles fertig ist auch noch einen "offiziellen" Blogeintrag geben in dem wir ausführlich beschreiben was mit WARP3 aktuell schon möglich ist und was wir in Zukunft als neue Features planen. Wir haben da noch so einiges vor 😊.

Edit: Die fertigen Firmwares WARP 2.0.0 und WARP2 2.0.0 sind jetzt auf warp-charger.com verfügbar. Edit: Beta 4 für WARP2 bzw. Beta 3 für WARP1 ist jetzt weiter unten im Thread verfügbar: tl;dr: WARP2 Firmware 2.0.0 Beta 1 mit Ladetracker, Benutzerverwaltung und mehr. Achtung: API-Bruch! Was gibt's neues? Das große neue Feature ist das Tracken der Ladungen pro Benutzer mit CSV-Export. Damit zusammenhängend sind folgende neue Features: Die Benutzerverwaltung: Hier können bis zu 8 Benutzer angelegt und geändert werden. Jedem Benutzer kann ein maximaler Ladestrom zugeordnet werden. Falls der Login des Webinterfaces aktiv ist, kann pro Benutzer konfiguriert werden, ob dieser sich anmelden darf. Umbau des NFC-Moduls: NFC-Karten können jetzt Benutzern zugeordnet werden Der Ladetracker: Der WARP Charger kann jetzt bis zu 7680 Ladungen aufzeichnen. Bei jeder Ladung werden Startzeitpunkt, Nutzer, Zählerstart bei Start und Ende der Ladung, sowie Ladedauer gespeichert. Die gesammelten Daten können als CSV-Datei über das Webinterface heruntergeladen werden. Zeitsynchronisierung per NTP (Prototyp): Per DHCP kann der WARP Charger die eines NTP-Servers erfragen, über den dann eine Zeitsynchronisierung erfolgt. Die gesetzte Zeit wird für Ladetracker und Ereignislog verwendet. Entkopplung der NFC-Freigabe von anderen Ladefreigaben: Eine externe Steuerung wird, falls die NFC-Freigabe aktiv ist, nicht mehr blockiert. Außerdem haben wir diverse Bugs gefixt und kleinere Verbesserungen am Webinterface vorgenommen. Verbindungsabbrüche des Webinterfaces sollten jetzt deutlich seltener auftreten. Warum der Versionssprung auf 2.0.0? Wir haben die interne Verwaltung der Stromgrenzen und Blockaden (Button, NFC, Lastmanagement, Benutzerverwaltung, externe Steuerung usw.) komplett umgebaut. Diese Umbauten haben es notwendig gemacht, dass wir die HTTP-/MQTT-API anpassen. Deshalb wird die Versionsnummer, entsprechend des Semantic Versionings auf 2.0.0 gesetzt. Die veränderte API ist noch nicht dokumentiert, die Dokumentation wird aber in Kürze folgen. Wie beeinflusst der API-Bruch externe Projekte, z.b. EVCC? EVCC ist Stand jetzt nicht mit dieser Betaversion kompatibel. Wir stehen aber im Kontakt zu den EVCC-Entwicklern, bevor die fertige Version 2.0.0 erscheint, wird eine kompatible Version von EVCC zur Verfügung stehen. Warum gibt es die Beta nur für WARP 2? Wird WARP 1 nicht mehr weiterentwickelt? Ein klares Nein: Die neuen Features werden alle für WARP 1 nachgezogen, die fertige Version 2.0.0 wird wie gewohnt für alte und neue Hardware parallel veröffentlicht. Wir haben die internen Umbauten der Kommunikation zwischen Ladecontroller und ESP zunächst nur für WARP 2 vorgenommen und wollen uns dafür zunächst von euch Feedback abholen, bevor wir sie für WARP 1 übernehmen. Ist der Ladetracker kompatibel zum WARP Charger Smart? Ja. Es kann dann allerdings nicht die geladene Energie gemessen werden. Warum ist die Zeitsynchronisierung nur ein Prototyp? Bisher wird nur ein per DHCP gesetzter Zeitserver zur Synchronisierung verwendet, es fehlt noch eine sinnvolle Standardeinstellung. Außerdem fehlt noch ein Abschnitt im Webinterface zur Konfiguration, sowie die Anbindung eines möglicherweise verbautem RTC-Bricklets. (Siehe https://github.com/Tinkerforge/esp32-firmware/issues/26 ) Wie geht's weiter? Neben dem Umsetzen eures Feedbacks werden wir in den nächsten Wochen die API-Dokumentation und die Anleitung aktualisieren, die Änderungen für WARP 1 nachziehen und einige Features (allen voran den NTP-Sync) finalisieren. Wie kann ich die Beta testen? Die Firmware ist an diesen Post angehangen. ACHTUNG: Die Konfiguration vorheriger Firmwares ist teilweise nicht kompatibel zur Beta-Version. Netzwerkeinstellungen müssen nach dem Flashen der Beta-Firmware neu konfiguriert, NFC-Tags neu angelernt werden. Die finale Version 2.0.0 wird voraussichtlich die Konfiguration älterer Firmwares migrieren können. Das Ladetracking ist automatisch aktiv. Damit Ladungen einem Nutzer zugeordnet werden können, muss dieser unter System->Benutzerverwaltung angelegt werden und ihm muss ein NFC-Tag zugeordnet werden. Damit nur bekannte Nutzer laden dürfen, muss unter Ladecontroller die Benutzerautorisierung aktiviert werden. Andernfalls erlaubt die Wallbox (wie gehabt) das Laden ohne Benutzerzuordnung, im Ladetracker tauchen diese Ladevorgänge dann mit "unbekannter Nutzer" auf. Edit: Veraltete Firmware entfernt.

Das Ladekabel kann bei WARP Chargern problemlos getauscht werden. Das Einziehen des Kabels ist zugegebenermaßen etwas fummelig, aber alle entsprechenden Anschlüsse in der Wallbox sind gut erreichbare Schraub- oder Klemmverbindungen. Falls du selbst nicht die nötige Qualifikation hast, kann prinzipiell jede Elektrofachkraft das Kabel tauschen. Stichwort Reparierbarkeit: Nicht nur das Kabel, sondern auch alle anderen Komponenten der WARP Charger lassen sich einzeln tauschen. Falls die Reparatur nicht bei uns durchgeführt werden soll, können alle Teile auch einzeln über unseren Shop nachbestellt werden. Stromlaufpläne zur Verkabelung der Komponenten sind frei verfügbar. Hier im Forum haben einige Nutzer sogar ihre alten WARP Charger mit Ersatzteilen der neueren Generationen aufgerüstet und haben jetzt vollwertige Wallboxen der neuesten Generation und dabei nur minimal Elektroschrott produziert. Den EU-Plänen zu Reparierbarkeit und Nachhaltigkeit sind wir damit weit voraus. 😉

Hallo zusammen, der Übersichtlichkeit halber starte ich für das Thema "WARP on Steroids", d. h. den Umbau von WARP1 auf den ESP32 Ethernet Brick, sowie die hierfür notwendige Firmware-Anpassung mal ein neues Topic. Damit wird die in https://www.tinkerunity.org/topic/8025-anschluss-von-warp-charger-pro-1-an-citywatt-abrechnungssystem/?do=findComment&comment=46114 begonnene Diskussion fortgesetzt. Anbei schon mal die aktuelle Firmware-Version 2.1.1 (Stand TF 31.03.2023)... Gruß Thomas Admin-Edit: Veraltete Firmware entfernt.

Gutes Argument, aber könnt ihr dann nicht einfach zuschauen, wie alles automatisch funktioniert? 😉 Okay, zugegebenermaßen ist die ganze Logik im Lastmanagement inzwischen so komplex, dass wir ein paar Bugs drin hatten, die von den besagten technikbegeisterten Nutzern entdeckt wurden… Die wirklich faszinierende Technik des Lastmanagements kannst du dir zu Hause übrigens gar nicht ansehen. Stell dir einen Ladepark mit 64 Wallboxen vor, mit einer bunten Mischung aus WARP 1, WARP 2 (mit und ohne Phasenumschaltung per Energy Manager) und WARP 3, manche davon mit bekannter, manche mit unbekannter Phasenrotation, der an einer unterdimensionierten Zuleitung hängt, die dynamisches Lastmanagement benötigt, und der zusätzlich auch noch bei gutem Wetter PV-Überschussladen auf allen Wallboxen machen soll und bei schlechtem Wetter die billigsten Stunden eines dynamischen Stromtarifes nutzen soll, und dann am Ende des Tages, wenn alle Mitarbeiter der Firma nach Hause wollen, jedem ungefähr gleich viel Energie ins Auto geschoben haben. Gleichzeitig soll der Anwendungsfall mit nur einer Wallbox zu Hause damit genauso gut funktionieren. Ja, wir hatten im letzten Jahr echt viel Spaß. 🤪

Hallo ich habe mir drei Energy Monitore mit Zubehör bei Tinkerforge gekauft, eingebaut und in Betriebgenommen. Ich bin schon seit vielen Jahren Bastler in diversen Sachen ,sowas wie Tinkerforge habe ich lange gesucht .Einfach alles vorhanden Software ,Hardware, Zeichnungen für Freecad ,einfach nur Top .Großes Kompliment an alle Mitarbeiter von Tinkerforge, Dankeschön Udo

tl;dr: Ladetracking Beta 2 bzw. Beta 1 für WARP1 Was gibt's neues? Die Änderungen an der Ladecontroller-Firmware, sowie das Ladetracking stehen jetzt auch für WARP1 zur Verfügung. Außerdem gibt es neben einigen Bugfixes jetzt eine neue Konfigurationsunterseite für die Zeitsynchronisierung, Benutzer- und Zeitfilter für das Ladetracking und die Möglichkeit, Wallboxen einen Anzeigenamen zu geben. Zusätzlich haben wir die Verwendung der API vereinfacht und ein konfigurierbares Mindest-Interval für MQTT-Nachrichten eingebaut. API-Änderungen Um es zu erleichtern, die API zu verwenden, haben wir folgende Änderungen vorgenommen: Unter info/features kann eine Liste von Funktionalitäten abgefragt werden, die von der konkreten Wallbox unterstützt werden. Bei einer WARP1 Smart mit nachgerüstetem NFC wird beispielsweise ["evse","nfc"] zurückgegeben, bei einer WARP2 Pro ["evse","cp_disconnect","button_config","ethernet","meter","meter_phases","meter_all_values","nfc"] Die API akzeptiert jetzt auf Topics, die einen leeren Payload erwarten (z.B. Kommandos wie evse/start_charging), nicht nur null, sondern auch folgende JSON-Werte: "", false, 0, [] und {} Kommandos und Konfigurations-Updates, die ein JSON-Objekt mit genau einem Eintrag erwarten, können jetzt direkt mit dem Wert des Eintrags aufgerufen werden. Zum Beispiel akzeptiert evse/external_current_update nicht mehr nur {"current": 13000} sondern auch direkt 13000 Edit: Die für die neue API aktualisierte Dokumentation findet sich hier: https://www.warp-charger.com/api_beta.html Achtung: Solange 2.0.0 noch nicht final veröffentlicht ist, garantieren wir keine API-Stabilität. Große Änderungen sind aber nicht mehr zu erwarten. Edit: Veraltete Firmware entfernt.

Hallo Tinkerforge Team vielen Dank für tolle Arbeit am Barometer Bricklet! Am Samstag meinte sich ja ein Vulkan in Tonga zu sprengen und es ist der Hammer, wie gut man das beim Barometer Bricklet (v1) sehen konnte. Man konnte sowohl die nach Norden laufende Druckwelle, wie auch die nach Süden laufende sehen und ebenso konnte man sie um Rauschen erkennen, nachdem sie einmal um die Erde gelaufen waren. Top!

Mahlzeit zusammen, seit ungefähr einem halben Jahr befindet sich der Fernzugriff in Entwicklung und so langsam wird es Zeit für die erste Begegnung mit der echten Welt. Edit 27.08.2024: Es ist aktuell nicht möglich neue Wallboxen für den Fernzugriff zu registrieren. Eine neue Firmware folgt in den nächsten Tagen in Form eines offiziellen Firmware-Releases. Edit 07.08.2024: Brechende Änderung! Ab dem 14.08.2024 funktionieren nur noch die neuen Firmwares! Die neuen Firmwares sind nicht mit der aktuellen Version des Servers kompatibel! Es wurde nur das protokoll zur Kommunikation mit dem Server angepasst und Änderungen aus dem Master Branch übernommen. Edit 12.07.2024: Brechende Änderung! Ab dem 24.07.2024 funktionieren nur noch die neuen Firmwares! Performance Optimierung und Behebung eines Fehlers in der Fehlerbehandlung von http requests. Edit 24.06.2024: Behebung eines Fehlers, durch welchen die Boxen nach einem Neustart des Servers teilweise nicht mehr über den Fernzugriff erreichbar waren. Was ist der Fernzugriff? Der Fernzugriff erlaubt es von überall über https://my.warp-charger.com auf die mit einem Account verknüpften Warp-Charger zuzugreifen. Der Fernzugriff ist Ende-zu-Ende verschlüsselt zwischen der Wallbox und dem Browser, insbesondere können wir als Serverbetreiber nicht die Walllbox steuern und/oder deren Daten einsehen. Wie funktioniert der Fernzugriff? Es wird eine mittels WireGuard verschlüsselte Verbindung zur Wallbox aufgebaut worüber das Webinterface geladen wird. Die dafür benötigten Schlüssel werden mit einem vom Passwort abgeleiteten Schlüssel verschlüsselt wodurch nicht einmal wir auf die Wallboxen zugreifen können. Zum Anmelden wird natürlich auch ein vom Passwort abgeleiteter Schlüssel benutzt weshalb der Server niemals das eigentliche Passwort sieht. WireGuard ist doch P2P, warum wird ein Relay-Server benötigt? Da der Browser nur Websocket verbindungen unterstützt, die Wallbox aber (noch?) kein WireGuard über Websocket unterstützt, wird ein Server benötigt, der den WireGuard-Datenstrom aus der Websocket-Verbindung entpackt und and die Wallbox weiterleitet und umgekehrt. Welche Daten werden dabei erhoben und wofür werden sie genutzt? Die E-Mail-Adresse wird verwendet um bei einem verlorenen Passwort den Account wieder herzustellen. Zusätzlich wird dabei eine beim Registrierungsprozess erstellte Wiederherstellungsdatei benötigt um den Zugang zu den Wallboxen wiederherzustellen. Die Kombination aus IP-Adresse und Port der Wallboxen wird verwendet um diese eindeutig zu identifizieren und Verbindungen zwischen Nutzern und Wallboxen zuordnen zu können. Dies ist nötig, da wir den Datenverkehr nicht entschlüsseln und somit anderweitig nicht zuordnen können. Es wird immer nur die letzte IP-Adresse gespeichert und kein Verlauf erfasst. Die UID der Wallbox (z.B. warp2-AbCd) wird dem Account des Besitzers zugeordnet. Wie kann ich den Fernzugriff nutzen? Einen Account unter https://my.warp-charger.com anlegen Die E-Mail-Adresse bestätigen Die passende Firmware aus dem Anhang des Posts herunterladen und auf der Wallbox installieren Die Zugangsdaten in der Wallbox unter System -> Fernzugriff eintragen, den Haken für Fernzugriff setzen und speichern. (Es muss nur Email und Passwort eingetragen werden, die restlichen Einstellungen sind bereits voreingestellt und werden nur benötigt falls ein anderer Relay-Server genutzt werden soll.) Hinweise: Es handelt sich um eine Alpha-Version. Auch wenn es in den kontrollierten Tests stabil läuft sind Probleme und Bugs zu erwarten. Da es sich um eine Testversion handelt, die jederzeit gebrochen werden kann sollte auf die Existenz einer Ausweichmöglichkeit um auf die Wallboxen zuzugreifen geachtet werden. https://my.warp-charger.com befindet sich aktiv in Entwicklung. Elemente können sich jederzeit verändern/verschieben oder verschwinden. Ebenso kann die Datenbank jederzeit zurückgesetzt werden, auch wenn wir versuchen dies zu vermeiden. Die Wallboxen werden davon nicht betroffen, es muss sich in dem Fall einfach nur neu registriert werden. Sollten Probleme auftreten, die sich nicht durch neu laden der Seite beheben hilft oftmals ein Ab- und Anmelden oder Neustart der Wallbox. Die angehängten Firmwares sind Entwicklungsversionen. Dementsprechend wird Vergleichsweise viel im Ereignis-Log ausgegeben und andere Dinge könnten untergehen. Das Aufbauen der Verbindung kann einige Sekunden dauern. Alle bekannten Bugs und Probleme sind im Github Repository aufgeführt. Sollten unbekannte Probleme auftreten freue ich mich über eine Meldung in diesem Thread oder auf Github direkt. In diesem Sinne frohes ausprobieren! Edit: Veraltete Firmware entfernt.

Analog zum "Veröffentlichungen"-Thread für die Bricks und Bricklets, posten wir hier immer einen Hinweis, wenn es eine Wallbox-Firmware gibt. (Den Thread kann man übrigens abonnieren ;) )

Wer möchte kann an der öffentlichen Beta unserer WARP App teilnehmen: Android: https://play.google.com/store/apps/details?id=com.tinkerforge.warp iOS: https://testflight.apple.com/join/4NwN9xnn Die beiden Apps können über my.warp-charger.com auf euren WARP1|2|3 und WARP Energy Manager zugreifen. Die Verbindung zwischen eurem Handy und dem Gerät ist natürlich wieder Ende-zu-Ende verschlüsselt und wir können nicht reinschauen, genauso wie bei der Webversion. Technisch rendern die Apps auch das HTML welches vom WARP Charger/Energy Manager ausgeliefert wird, es werden aber der Header und das Menü durch native Android/iOS Elemente ersetzt. Zusätzlich sollte es so sein dass ihr euch nur einmal anmelden müsst und die App stellt die Verbindung automatisch wieder her wenn ihr sie wieder öffnet. Bekannte Bugs: In seltenen Fällen stürzt die Rendering-Engine(?) im Hintergrund ab. In dem Fall muss man einmal im Menü auf Geräte klicken und kann dann wieder zurück (oder die App neustarten). Der Grund dafür ist aktuell noch unklar, das wollen wir vor dem Release natürlich noch fixen. Beschreibungstexte und Screenshots usw in den App Stores sind noch nicht fertig, das wird alles noch aufgehübscht.

Die Apps sind jetzt aus der öffentlichen Beta und veröffentlicht 🥳: Android Play Store: https://play.google.com/store/apps/details?id=com.tinkerforge.warp Apple App Store: https://apps.apple.com/de/app/warp-by-tinkerforge/id6736695801 Ich denke die meisten "Kinderkrankheiten" sind behoben und die Apps sollten ziemlich stabil laufen. Wenn ihr weitere Probleme findet könnt ihr die natürlich trotzdem hier posten und wir kümmern uns drum.

Moin, ich bin total begeistert, dass nun alle Ladungen als PDF aus der Box kommen. Super!!! Wenn man nun noch die Daten für den Briefkopf permanent speichern könnte...? Das wäre das i-Tüpfelchen :-) Danke und LG. F.

Für das Kabel zum Abschalteingang gibt es keine Spezifikation. Darüber läuft nur Kleinspannung und dementsprechend ist es fast komplett egal, was du da nimmst. Der besagte Klingeldraht reicht auch. Wahrscheinlich kannst du dir die zusätzliche Leitung aber einfach schenken. Wir haben vor, dass sobald irgendein Standard oder zumindest eine weit verbreitete Lösung der Energieversorger absehbar ist, wir dafür ein Gerät zum Nachrüsten anbieten werden, das dann über Netzwerk mit der Wallbox kommuniziert.

Falls ihr euch fragt wo @ffreddow auf einmal wegkommt: Er hat den Fernzugriff in den letzten 6 Monaten in seinem Uni-Praktikum bei uns entwickelt und arbeitet seit Anfang Juni Vollzeit bei Tinkerforge an den WARP Chargern 😀.

Moin zusammen, hier mal ein kurzer Zwischenstand meiner bisherigen Experimente. Aufgrund der (leider recht länglichen) Diskussion hier https://github.com/SmartEVSE/SmartEVSE-3/issues/25 habe ich mal einen alten Powerline-Adapter "geschlachtet" und entsprechend modifiziert: CP und PE habe ich aus der WARP herausgeführt und die EVSE-Firmware so angepasst, dass sie im Status B ein PWM-Signal mit 5% Duty Cycle erzeugt - und siehe da, pyPLC kann eine Verbindung mit meinem ID.4 aufbauen. Leider toggelt der EVSE dann alle paar Sekunden zwischen Status A und B hin und her, sodass die Verbindung wieder abbricht. Lässt man unabhängig vom Status grundsätzlich 5% PWM anliegen, dann wird die gesamte "DC-Precharge"-Kommunikation durchlaufen und in den Logs steht tatsächlich irgendwo der SOC 😀 Allerdings ist das ganze noch weit weg von praxistauglich, denn eine Ladung kann mit den o. g. Anpassungen nicht mehr gestartet werden und wenn ich den Renault Zoe (ohne CCS-Lader) verbinde, dann crashed der EVSE. Grundsätzlich ist es aber schon mal eine schöne Erkenntnis, dass eine rudimentäre digitale Kommunikation möglich ist... Gruß Thomas

Es sind ein paar Detailverbesserungen drauf: Mehr Schutzbeschaltung, zwei Schütze ansprechbar, verbesserte CP-Trennung, die Schützprüfung kann jetzt zwischen Schützfehler bei Schütz 1 und 2 sowie PE-Fehler unterscheiden (vorher waren Fehler bei der PE-Verkabelung und Schützfehler nicht unterscheidbar), Temperaturüberwachung, geringerer Stromverbrauch und wir können jetzt eine RGB-LED in der Front ansprechen. Die Ethernetbuchse sitzt jetzt auch an einer besseren Stelle, wo sie für den Elektriker besser anschließbar ist. Vieles davon (neben den neuen Features) ist Umsetzung von Feedback das wir von den Elektrikern bekommen haben um die Box einfacher in Betrieb zu nehmen und Fehler besser diagnostizieren zu können. Das steht aktuell noch auf der Kippe, dazu gibt es dann mehr wenn sicher feststeht welchen Zähler wir verbauen.

Ich hab es mal auf die Liste der interessanten Sensoren gepackt 😀.

Jetzt ich: Ich benutze LibreOffice auf dem Mac und habe kein Problem mit dem Import. Ich finde das Format völlig in Ordnung. Vielleicht sollten diejenigen, die ein Windows-Format wünschen mal ihr Windows/Office aktualisieren oder z.B. LibreOffice verwenden. Bitte kein uraltes Format verwenden - UTF-8 sollte auf modernen Systemen gleich welches Herstellers kein Problem darstellen. Wenn doch, liegt es nicht am Format, sondern am verwendeten Werkzeug. Mit einem 3D-Drucker könnte man einen Export in Keilschrift auf Lehmtafeln realisieren - kleiner Scherz. 😉

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. Edit: Veraltete Firmware entfernt.

@michael99: Mit Verlaub, deinen Tonfall finde ich ziemlch daneben. Die Jungs bieten hier echt einen erstklassigen Support für uns User - kompetent, zuvorkommend, freundlich und noch dazu schnell. Und bevor du patzig wirst, solltest du deine Anfragen vielleicht so formulieren, dass man sie überhaupt verstehen kann. Also Subjekt-Prädikat-Objekt.

Firmware: WARP 2.0.0 und WARP2 2.0.0 Blogpost mit Details zu den umfangreichen Änderungen API-Änderungen; möglicherweise sind Anpassungen an Software die mit der Wallbox interagiert notwendig! Ladetracker hinzugefügt; ordnet Ladevorgänge Benutzern zu und zeichnet diese persistent auf Download eines Logs der aufgezeichneten Ladungen hinzugefügt Benutzerverwaltung hinzugefügt; NFC-Tags werden jetzt Benutzern zugeordnet Netzwerk-Zeitsynchronisierung hinzugefügt Ladestromgrenzen aufgeteilt um NFC und andere Steuerungsmöglichkeiten zu entkoppeln (durch Update auf Ladecontroller-Firmware 2.1.0 (WARP) bzw. 2.1.2 (WARP2)) Netzwerk-Abschnitt hinzugefügt; alle Netzwerk-Interfaces verwenden jetzt den selben Hostnamen Konfigurierbares Sendeintervall für MQTT hinzugefügt Editierbaren Wallboxnamen hinzugefügt Unterstützung des Browser-Verlaufs hinzugefügt Eingabefeld des Ladestroms verbessert Übersetzungen verbessert Webinterface-Details verbessert Warnung hinzugefügt, wenn WLAN-Access-Point deaktiviert werden soll Hinweis zu Lastmanager-Watchdog hinzugefügt WebSocket-Verbindungsverlust durch falsches Ping-Frame-Handling repariert Browser-Caching repariert Anzeige der Ladecontroller-Version repariert WebSocket-Verbindungen durch SSL-Proxies repariert Logik der Fehleranzeige im Webinterface repariert Repariert, dass Passphrase bei Verbindung zu anderem Access Point mit selber SSID nicht verlangt wird Sporadisches Fehlen des Ereignis-Logs repariert Download: WARP 2.0.0 bzw. WARP2 2.0.0

You can use a GPIO connector like this one: https://www.berrybase.de/en/new/gpio-edge-erweiterung-gpio-adapter-f-252-r-raspberry-pi?c=2413 and plug it between the Pi and the HAT. In the HAT Bricks schematic you can see with GPIOs are not used by the HAT: https://raw.githubusercontent.com/Tinkerforge/hat-brick/master/hardware/hat-schematic.pdf (the yellow rectangle to the right is the GPIO connector). To reference the numbers to the physical position of a pin, use for example this: https://i0.wp.com/maxembedded.com/wp-content/uploads/2014/07/Raspberry-Pi-GPIO-Layout-Model-B-Plus.png

Ein Weihnachtswunder: https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta24.zip Das wird voraussichtlich die letzte Beta, bzw. falls keine kritischen Bugs darin sind ist es die "fertige" Version der openHAB-2-Bindings. Die Liste von oben ist soweit abgearbeitet. Außerdem neu ist Support für die seit der letzen Beta erschienenen Bricklets: - Industrial Dual AC Relay - Industrial PTC - IMU 3.0 sowie ein deutlich einfacherer Modus für das NFC-Bricklet (der aber nur Tag-IDs liest). Für die neuen Motor-Treiber-Bricklets gibt es keinen Support, das war zeitlich nicht drin und die Verwendung wäre ähnlich unkomfortabel wie die der alten Motor-Treiber gewesen. Wichtig: In der Zip ist eine noch nicht veröffentlichte Version der Java-Bindings enthalten. Die ist notwendig um die teilweise neue API zu verwenden. Bei einem Update von einer älteren Bindingsversion bitte die 2.1.26er Jar löschen. Mit der aktuellen Version und openHAB 2.5.9 scheint es auch zu funktionieren, die Bricks und Bricklets in einer .things-Datei zu definieren. Hier ein Beispiel: Bridge tinkerforge:brickd:laptop [host="192.168.178.147"] Thing tinkerforge:brickletmultitouch:zwL "Multitouch" (tinkerforge:brickd:laptop) [uid="zwL", proximityEnabled=false]

Moin, tl;dr: Nach langem Warten gibt es (im Anhang) endlich die Beta-Version der Firmware mit Lastmanagement zwischen WARP Chargern. Das Lastmanagement stellt sicher, dass mehrere Wallboxen an einem Anschluss einen konfigurierten Ladestrom nicht überschreiten. Weitere Neuerungen Neben dem Lastmanagement habe ich die komplette Web-Server-Implementierung ausgetauscht. Der neue Web-Server läuft deutlich robuster als der alte, vorallem wenn noch weiterer Netzwerk-Traffic (wie das Lastmanagement oder MQTT) läuft. Durch ein Update der verwendeten Bibliotheken beinhaltet die Firmware jetzt einen Patch für die kürzlich bekanntgewordenen WLAN-Sicherheitslücken FragAttacks. Details finden sich hier. Auf der Statusseite wird jetzt angezeigt, warum das Ladestrom-Limit den aktuellen Wert hat. Setup Ihr könnt das Lastmanagement wie folgt testen: Die angehangene Firmware auf alle Wallboxen, die gesteuert werden sollen (Clients) und auf die Wallbox, die steuern soll (Manager), flashen Bei allen Clients und normalerweise auch beim Manager auf der Ladecontroller-Unterseite Lastmanagement aktivieren. Beim Manager auf der Lastmanager-Unterseite: Alle Clients mit einem Anzeigenamen und der entsprechenden IP hinzufügen. Hier ist noch kein Neustart notwendig. Der Manager selbst ist bereits als "lokale Wallbox" angelegt. Den verfügbaren Ladestrom einstellen. Den Lastmanager aktivieren Neu starten Wenn alles klappt, sollten die Clients jetzt auf der Statusseite des Managers angezeigt werden und das Lastmanagement sollte funktionieren. Falls Probleme beim Lastmanagement auftreten, finden sich die Informationen, die dem Lastmanagemer bekannt sind als Low-Level-Zustand auf der Lastmanager-Unterseite und Informationen zu erfolgten Stromverteilungen im Event-Log. Die Clients zeigen den vom Lastmanager festgelegten Strom auf der Ladecontroller-Unterseite an. Edit: Ein Downgrade auf eine ältere Firmware ist jederzeit möglich; im Idealfall auf die 1.2.4, die ich unter anderem veröffentlicht habe, damit der aktuelle Stand abzüglich der Lastmanagement- und Webserver-Änderungen verfügbar ist. Bekannte Bugs und Probleme Da das Lastmanagement wie unten beschrieben Strom zuweist, gibt es eine implizite Priorisierung nach der Konfigurationsreihenfolge. Das führt dazu, dass wenn weniger Strom zur Verfügung steht, als von allen ladebereiten Wallboxen benötigt wird, damit sie laden können (also weniger als 6 Ampere pro Box), werden immer die in Konfigurationsreihenfolge ersten Boxen Strom zugeteilt bekommen. Die Lastmanagement-Konfiguration hat bisher kaum User-freundliche Überprüfungen. Künftig wird bei der Konfiguration und periodisch geprüft, ob alle Wallboxen im Lastmanagement-Verbund die selbe Firmware haben und die Konfigurationen korrekt sind. Außerdem können Wallboxen bisher nur über ihre IP hinzugefügt werden. Später werden auch Hostnamen unterstützt. Jede Wallbox zeigt ihre IP auf der Status-Seite hinter WLAN-Verbindung an. Der neue Web-Server unterstützt folgende Features nicht mehr: Server-Sent Events: Stattdessen werden jetzt WebSockets verwendet um Events in das Webinterface zu übertragen. Login per Digest Authentication: In der Beta ist das Zugangsdaten-Modul deaktiviert, da es noch zu Bugs mit dem Web-Server führt. Ich arbeite an einer Lösung. Falls die Beta auf eine Wallbox geflasht wird, bei der Zugangsdaten für das Webinterface gesetzt sind, werden diese ignoriert. Nach einem Downgrade auf Firmware 1.2.4 wird das Modul automatisch wieder aktiviert. Bei einem künftigen Update auf die finale Version 1.3 sollte das genauso passieren. Handler für mehrere HTTP-Methoden: Die API reagiert in der Beta nur noch auf HTTP GET und HTTP PUT. PATCH und POST werden ignoriert. Fehleranzeigen auf dem Webinterface werden sehr schnell gelöscht. Die Status-Seite wird langsam unübersichtlich. Ich habe ein paar Ideen, wie man das Layout übersichtlicher gestalten kann, dazu später mehr. Edit: Das Lastmanagement ignoriert die Stromgrenzen der Zuleitung und Ladekabel. Das heißt wenn zum Beispiel zwei Boxen gesteuert werden, es stehen 32 Ampere zur Verfügung, eine der Boxen ist auf 12 Ampere konfiguriert und eine auf 32 Ampere, dann wird, wenn beide laden wollen, das Lastmanagement beiden Boxen 16 Ampere zuteilen, obwohl sinnvoller wäre 12 bzw. 20 Ampere zuzuteilen. In die andere Richtung ist es aber nicht schlimm, wenn nur der 12-Ampere-Box 32 Ampere zugeteilt werden (falls nur sie laden will): Die Wallbox selbst lädt nur mit dem Minimum aller Stromgrenzen. Funktionsweise des Lastmanagements Das Lastmanagement besteht aus zwei Komponenten: Einer Erweiterung der Ladecontroller-Firmware, sowie dem Lastmanager, der Strom verteilt. Die Ladecontroller-Firmware hat neben dem Maximalstrom der Zuleitung bzw. des Ladekabels und dem konfigurierten Ladestrom jetzt ein viertes Stromlimit: das des Lastmanagements. Dieses vierte Limit wird nur berücksichtigt, wenn in der Ladecontroller-Unterseite Lastmanagement aktiviert wird. Der Ladecontroller hat neue API (evse/managed_current bzw. evse/managed_current_update) über den das Stromlimit festgelegt werden kann. Wenn eine Ladung beendet wurde, und wenn über einen längeren Zeitraum (30 Sekunden) kein managed_current_update empfangen wurde wird das Limit automatisch auf 0 A gesetzt. Damit die sehr häufigen Übertragungen effizienter sind, kann diese API auch über UDP benutzt werden. Der Lastmanager benutzt die UDP-Variante der API um eine konfigurierte Menge Strom zu verteilen. Dazu schickt er regelmäßig den jeweils erlaubten Strom (anfangs 0 A) an Clients. Die Wallboxen beginnen daraufhin, dem Lastmanager regelmäßig ihren aktuellen Zustand zu übertragen. Aus diesen Informationen kann der Lastmanager erkennen, an welchen Boxen Fahrzeuge laden wollen und entsprechend Strom verteilen. Das passiert folgendermaßen: Ermitteln wie viele Boxen laden wollen Ermitteln des Ladestroms der dann jeder Box zur Verfügung steht (verfügbarer Strom / Anzahl ladebereiter Boxen) Begrenzen aller Boxen, die bereits laden Zuteilen des Stroms an Boxen die bereit sind, mit einer Ladung zu beginnen Blockieren aller anderen Boxen Falls der Lastmanager feststellt, dass ein Client nicht mehr antwortet oder reagiert, stoppt er alle laufenden Ladungen und blockiert alle Boxen, bis das Problem behoben ist. Das ist notwendig, da bei gestörter Kommunikation nicht klar ist, ob die nicht erreichbare Box gerade lädt. Ich freue mich wie immer über Feedback! Erik Edit: Veraltete Firmware entfernt.

Ich habe die Box in meinen Home Assistant eingebunden, funktioniert soweit ganz gut. Hier meine Konfiguration: config/configuration.yaml: binary_sensor: - platform: mqtt name: "Wallbox Ladekabel verbunden" state_topic: "warp/SLq/evse/state" device_class: plug json_attributes_template: '{{ value_json }}' value_template: '{{ value_json.vehicle_state in [1, 2, 3] }}' payload_on: 'True' payload_off: 'False' - platform: mqtt name: "Wallbox Fehler" state_topic: "warp/SLq/evse/state" device_class: problem json_attributes_template: '{{ value_json }}' value_template: '{{ value_json.vehicle_state in [3] }}' payload_on: 'True' payload_off: 'False' - platform: mqtt name: "Wallbox verfügbar" state_topic: "warp/SLq/evse/state" device_class: connectivity json_attributes_template: '{{ value_json }}' value_template: '{{ value_json.uptime > 0 }}' expire_after: 30 payload_on: 'True' payload_off: 'False' - platform: mqtt name: "Wallbox Ladevorgang" state_topic: "warp/SLq/evse/state" device_class: battery_charging json_attributes_template: '{{ value_json }}' value_template: '{{ value_json.vehicle_state in [2] }}' payload_on: 'True' payload_off: 'False' sensor: - platform: mqtt name: "Wallbox Leistung" state_topic: "warp/SLq/meter/state" value_template: "{{ value_json.power }}" device_class: power unit_of_measurement: "W" - platform: mqtt name: "Wallbox Zählerstand" state_topic: "warp/SLq/meter/state" value_template: "{{ value_json.energy_abs }}" device_class: energy unit_of_measurement: "kWh" switch: - platform: mqtt name: "Wallbox Maximaler Ladestrom" command_topic: "warp/SLq/evse/current_limit" payload_on: '{"current": 16000}' payload_off: '{"current": 6000}' state_topic: "warp/SLq/evse/max_charging_current" value_template: '{{ value_json.max_current_configured >= 16000 }}' state_on: "True" state_off: "False" json_attributes_template: "{{ value_json }}" - platform: mqtt name: "Wallbox Automatisches Laden" icon: mdi:ev-plug-type2 command_topic: "warp/SLq/evse/auto_start_charging_update" payload_on: '{"auto_start_charging": true}' payload_off: '{"auto_start_charging": false}' state_topic: "warp/SLq/evse/auto_start_charging" value_template: '{{ value_json.auto_start_charging }}' state_on: "True" state_off: "False" - platform: mqtt name: "Wallbox Ladevorgang" icon: mdi:battery-charging command_topic: "warp/SLq/evse/charging_command" state_topic: "warp/SLq/evse/state" value_template: '{{ value_json.vehicle_state in [2] }}' state_on: "True" state_off: "False" - platform: template switches: wallbox_ladevorgang: friendly_name: "Wallbox Ladevorgang" icon_template: mdi:battery-charging value_template: '{{ is_state("binary_sensor.wallbox_ladevorgang", "on") }}' turn_on: service: mqtt.publish data: topic: warp/SLq/evse/start_charging payload: 'null' turn_off: service: mqtt.publish data: topic: warp/SLq/evse/stop_charging payload: 'null' config/automations.yaml: Die Automation ist leider notwendig, um das MQTT-Kommando der Wallbox richtig zu senden. Die Box hat zwei Topics zum Starten und Stoppen des Ladevorgangs, und Home Assistant unterstützt leider nur einen Topic für den Schalter. Funktioniert aber gut soweit. Edit: Ich habe doch eine Variante ohne Automation gefunden, mit Hilfe eines Template-Switches.

Der aktuelle Zeitplan ist, dass ich Ende der Woche eine Beta-Version davon veröffentliche, mir damit Feedback einhole und dann ein paar Wochen später die fertige Version rausgeht. Der Plan hatte sich ein paar Wochen verschoben, weil wir bei den internen Tests festgestellt haben, dass der Webserver, der auch die HTTP-API für das Lastmanagement hostet, instabil ist. Deshalb musste ich den erst austauschen. Damit liege ich in den letzten Zügen, danach will ich das Lastmanagement noch ein paar Tage laufen lassen und durchtesten, aber ich bin optimistisch, dass das diese Woche noch fertig werden müsste. Wenn das Lastmanagement läuft, geht es dann an OCPP, damit unsere Charger auch mit anderen Wallboxen zusammenarbeiten können.

Der lokale Netzbetreiber selbst beschränkt auf 11kW in Summe? Oder meinst du wegen der Förderung? Es sind zwar nur 11kW Wallboxen förderfähig, aber man kann sich theoretisch 2stk fördern lassen und die auch gleichzeitig nutzen. Zum Thema Lastmanagement zwischen zwei Ladepunkten: Das ist das erste Feature welches wir nachreichen werden, da die Nachfrage danach so groß ist!

Welchen Grund sonst könnte es denn geben, die Wallbox von euch zu kaufen, außer faszinierendes Technik Spielzeug zu wollen? Autos aufladen wird völlig überbewertet, die sind nur Mittel zum Zweck, um Phasenumschaltungen und Überschussladen im Detail optimieren zu können... :-)

Firmware: WARP2 2.7.1, WARP3 2.7.1 Erkennung der angeschlossene Phasen nach Neustart repariert (durch Update auf Ladecontroller-Firmware 2.2.10) Download: WARP2 2.7.1 bzw. WARP3 2.7.1

Aktueller Status: WARP3 PRO 2.6.6+675aeb99 (erstellt 12.12.2024 14:56:41, von Tinkerforge GmbH) + Fiat 500e + EVCC 0.132.1 Alle Ladeprobleme bei der Umschaltung der Phasen sind verschwunden! SUPER! Vielen Dank an das ganze Entwicklungsteam! LG aus dem Norden

bin erst jetzt zum Testen gekommen. Funktuioniert bei mir so, wie ich es erwarte. @Steff49 ich habe einen Fronius Symo Gen24.

Wenn wir in Zukunft OCPP 2.0 unterstützen, wird das wahrscheinlich auch für die älteren Wallboxen nachgelegt (kann ich aber nicht versprechen), aber anscheinend hast du für OCPP 2.0 selbst ja gar keinen konkreten Anwendungsfall. ISO15118 unterstützen die WARP Charger aktuell noch nicht und für bestehende Wallboxen kann das auch nicht per Softwareupdate nachgelegt werden, da dafür zusätzliche Hardware nötig ist. Die zusätzliche Hardware ist auch der Grund, warum wir das noch nicht anbieten, da sie aktuell nur für einen unrealistisch hohen Preis zu haben ist. Wir sind aber auch sehr an dem Thema interessiert und wollen ISO15118 integrieren, sobald wir eine Möglichkeit finden, das für einen akzeptablen Preis zu machen.

Das hätte ich auch sehr sehr gerne, da ich den gleichen Ablauf habe: Aussteigen, zur Wallbox laufen - und hier würde ich gerne: NFC dranhalten und dann - Stecker nehmen, zum Auto laufen und einstecken und Auto sollte laden. Also die Freigabe im Voraus, die dann halt auch z.B. 2 Minuten hält - wäre da natürlich super man würde die Freigabe an der LED blinken sehen. Im jetzigen Zustand ists einfach umständlich, denn man muss nach dem Anstecken wieder zur Wallbox laufen, NFC dran und dann wieder zurück zum Auto um zu sehen ob das Teil auch lädt.

Wir haben mal ein dbus-warp-charger klon entwickelt. Diesen findet ihr auf Github zusammen mit einer kleinen Beschreibung: https://github.com/Tinkerforge/dbus-warp-charger Wie die go-e Implementierung nutzen wir auch deren Wallbox (evcharger) Implementierung. Daher ist eine Phasenumschaltung innerhalb der Victron Remote Console damit nicht möglich. Schaut euch gerne das ganze mal an und gebt Feedback oder entwickelt mit.

Warum würdest du das erwarten, wenn ich fragen darf? Es ist doch kein offiziell unterstütztes Feature eine ältere Box auf die Funktion eines neueren Produkts umzurüsten. Das ist dein persönlicher Spaß, und dass man überhaupt dazu Unterstützung bekommt, ist doch schon einmalig. Frag mal bei einem anderen Hersteller nach wie du dein gekauftes Gerät auf den Nachfolger aufrüsten kannst ;-) Wundere mich zusehends über die Selbstverständlichkeit der eigens definierten Erwartungen, bin da aber vielleicht auch nicht das Maß der Dinge. Persönlich hätte ich nett gefragt ob das jemand zusammenfassen kann wenn ich es selbst nicht verstehe. Gruss, Florian.

Ich habe für meine Eltern einfach die Ladekarte des Anbieters den sie unterwegs benutzen angelernt. So müssen sie nicht noch eine Karte mitnehmen und für sie ist das ziemlich intuitiv die selbe Ladekarte zu verwenden die sie sonst auch unterwegs benutzen.

Wen interessiert wie das technisch funktioniert mit der Ende-Zu-Ende-Verschlüsselung kann ich sonst auch noch die Sequenzdiagramme dazu empfehlen:https://github.com/Tinkerforge/esp32-remote-access/blob/main/sequence.md

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

Hallo zusammen, falls sonst noch jemand mit einer WARP1 die Phasenumschaltung über den WARP Energy Manager nutzen möchte: Ich habe nach Weihnachten mal etwas gebastelt, d. h. ein eigenes kleines Bricklet für die CP-Trennung entwickelt und von JLCPCB fertigen lassen: Auto verbunden 2024-01-24 17:34:32,196 Charger state changed from 0 to 1 WEM Umschaltung auf 3-phasig 2024-01-24 17:35:24,179 EvseCPC::set_control_pilot_disconnect(): connected => disconnected 2024-01-24 17:35:25,272 Charger state changed from 1 to 0 2024-01-24 17:35:29,154 EvseCPC::set_control_pilot_disconnect(): disconnected => connected 2024-01-24 17:35:30,296 Charger state changed from 0 to 1 WARP Ladevorgang gestartet 2024-01-24 17:36:59,381 Charger state changed from 1 to 2 2024-01-24 17:36:59,461 Tracked start of charge. 2024-01-24 17:37:00,505 Charger state changed from 2 to 3 WARP Ladevorgang beendet 2024-01-24 17:51:57,403 Charger state changed from 3 to 1 WEM Umschaltung auf 1-phasig 2024-01-24 17:52:14,145 EvseCPC::set_control_pilot_disconnect(): connected => disconnected 2024-01-24 17:52:14,420 Charger state changed from 1 to 0 2024-01-24 17:52:14,516 Tracked end of charge. 2024-01-24 17:52:19,109 EvseCPC::set_control_pilot_disconnect(): disconnected => connected 2024-01-24 17:52:20,627 Charger state changed from 0 to 1 Auto getrennt 2024-01-24 17:52:44,641 Charger state changed from 1 to 0 Hard- und Software des Bricklets inkl. Stückliste und Production Files sind in meinem GitHub-Repo (https://github.com/poohnet/evse-cpc-bricklet) zu finden. Bei Interesse kann ich selbstverständlich gerne weitere Details nennen... Gruß Thomas

Im Block steht (https://www.tinkerforge.com/de/blog/): Ausblick auf 2024 Im ersten Quartal planen wir den WARP3 Charger zu veröffentlichen (Foto ist von einem frühen Prototyp, da wird es noch Änderungen geben).

Korrektur: Ursprünglich war das nicht vorgesehen, aber es gibt den Standard ISO 15118, der meines Wissens für DC-Schnellader entwickelt wurde und dort notwendig ist, inzwischen aber auch optional bei AC-Wallboxen eingebaut werden kann. Leider verursacht die Unterstützung dafür zusätzliche Kosten und ist erst bei entsprechend hohem Absatz realistisch machbar. Da den hohen Kosten als einziger Vorteil Plug & Charge gegenübersteht, bieten die meisten AC-Wallboxen, wie auch der WARP Charger, das aktuell leider noch nicht an. Wir sind aber sehr interessiert daran und behalten das weiter im Auge, damit wir auch eine Unterstützung dafür anbieten können, sobald das realistisch machbar ist.

You can enumerate all connected bricks and bricklets without knowing their UIDs: https://www.tinkerforge.com/de/doc/Software/IPConnection_Python.html#enumerate

Hallo dasfuu, bei einer "normalen" Wallbox gibt es keine bidirektionale Kommunikation, daher ist dies erstmal nicht möglich (die Wallbox signalisiert dem Ladegerät im Auto einfach nur, wieviel Strom zur Verfügung steht). Schau dir aber mal das Projekt evcc.io an, das erfüllt genau deine Wünsche, indem über herstellerspezifische Schnittstellen online der Ladezustand des Autos abgefragt und die Wallbox entsprechend gesteuert wird. Das funktioniert perfekt mit vielen Wallboxen und auch dem WARP-Charger (den ich selbst jederzeit wieder kaufen würde)... Gruß Thomas

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.

Moin, Das Lastmanagement musst du nicht neu implementieren. Stattdessen kannst du über unsere API dem Lastmanager (lies: einer der Wallboxen) den verfügbaren Strom mitteilen, den er dann unter den Wallboxen verteilt. Die "fertige" Version des Lastmanagements, die eventuell diese Woche noch kommt, hat dafür noch ein paar hilfreiche Features wie einen Watchdog und Stromvoreinstellungen.

Hallo, wie gesagt wir haben auf dem Schirm. Wir haben aber eine längere Liste mit Feature-Requests die alle sehr sinnvoll sind. Wir versuchen gerade die abzuarbeiten, die von den meisten Nutzern gewünscht werden. Nummer 1 ist definitiv das Thema Lastmanagement ("X Wallboxen teilen sich einen Anschluss"). Da sind wir gerade bei und haben bereits Prototypen am laufen. Das ganze wird über ein Softwareupdate den Nutzern zur Verfügung gestellt.

Der aktuelle Stand ist, dass wir alle daran arbeiten, die vorbestellten Boxen zu bauen und zu verschicken. Wenn da Zeitlücken sind arbeite ich an der Firmware. Voraussichtlich wird das erste größere Feature, dass ich einbaue eine Zeitschaltung, danach geht es an die Implementierung des Lastmanagements. Da gibt es aber noch viele Entscheidungen zu treffen, wie das genau funktionieren wird, z.B. ob man gleich auf OCPP geht, oder erst eine Implementierung schreibt, die nur zwischen unseren Boxen funktioniert. Auf jeden Fall wird das aber eine reine Softwareimplementierung und die Boxen werden über WLAN miteinander kommunizieren.

Hallo riro ich habe das Outdoor Weather Bicklet gemeinsam mit dem TH-6148 Sensor von Tinkerforge im Einsatz. Der Sensor liefert Temperatur & relative Luftfeuchte und einen String wann der letzte Datensatz empfangen wurde. Wenn Du die Outdoor Weather Station hast, dürfte das vorgehen ähnlich sein, nur dass diese mehr Daten übermittelt als der TH-6148 Sensor. Als erstes muss Du den Sensor Identifier (für den TH-6148) oder den Station Identifier (für die WS-6147) ermitteln. Das kannst Du über den Brickviewer oder du legt ein entsprechendes „String-Item“ mit dem passenden Channel des Outdoor Weather bricklet an. Die benötigten Channel findest Du im Konfigurations-Menue des Outdoor Weather Brickelt (Thing) Es kann etwas dauern bis dir dann über das Sting-Item der passende Identifier angezeigt wird. Beispiel meines ITEM‘s zum auslesen der Sensoren ID Weiter mit anlegen/erzeugen des Sensor als „Thing“ Unter Paperui / Configuration / Thing, analog als ob du einen weitern Thinkerforge Dämon anlegen willst („MANUALLY ADD THING“) Hier werden dir alle möglichen Thing-Optionen des Tinkerforge-Binding aufgelistet. (siehe Bild unten) Wenn Du wie ich den TH-6148 Sensor hast, wähle diesen aus. Über das folgende Menü kannst Du nun die Grundkonfiguration des Sensor ausführen. 1) unter Bride Selection / Select a Bridge >> „brickletoutdoorweather ….“ auswählen 2) unter Configuration Parameter die ID des Sensor eintragen 3) speicher und schon wirst du ein neues Thing unter Configuration finden. Wenn Du nur Temperatur / Humidity / Last Change Daten haben möchtest benötigst Du keine Action da reichen entsprechende ITEM-Channel Verlinkungen in der ITEM Datei aus. Beim TH 6148 Sensor gibt es etwas zu beachten. Nach einem Batterie Tausch erzeugt er eine neu ID (gibt hierzu einen Post von Erik), und diese musst du dann über das „Konfiguraion‘s Menue“ des Thing TH-6148 anpassen (siehe oben Punkt2). An den rules oder der Item-Channel-Verlinkung musst Du nichts anpassen. Ich hoffe diese mini Anleitung hilft Dir viele Grüsse Stefan