mattsches

Stimmt, da hste Recht. Interessant ist, dass bei dir auf 20 kW skaliert wird, obwohl der Ladestrom auf 16 A abgeregelt ist, was ja 11 kW ergeben würde als Obergrenze. Ich habe bei mir über die DIL-Schalter 13 A eingestellt, und das Diagramm wird auf ca. 8900 W skaliert. Das nur als Beobachtung...

Nur aus reiner Neugier: Ist das Laden von Mitarbeiterfahrzeugen nicht ohnehin möglich, ohne einen Geldwerten Vorteil versteuern zu müssen? https://shbb.eu/ladestrom-vom-arbeitgeber-bleibt-steuerfrei/

Hallo Doncarlos, komisch, bei mir wird das Diagramm automatisch auf Maximum skaliert (siehe Anhang). Das mit der Leistungsvorgabe habe ich in meiner Phasenumschaltung so gemacht. Wenn die aktiv ist, kann ich die gewünschte Ladeleistung über die API in W vorgeben. Daraus werden dann die zu schaltenden Phasen ermittelt und der Strom. Nachdem die tatsächliche Netzspannung von 230 V abweichen kann und der Zähler in meiner WARP1 die Spannung nicht misst, weicht die tatsächliche Ladeleistung meist etwas ab.Kann auch sein, dass das Auto nicht exakt den vorgegebenen Strom zieht (der ja auch nur ein Maximalwert ist). Mir ist das egal, wir reden von 100 bis 200 W. Mein Erweiterungsmodul habe ich auf Github abgelegt: https://github.com/mattsches1/phase_switcher. Allerdings ist es aktuell hart an den Umbau zur Phasenumschaltung gekoppelt. Wenn du nur die Leistungsvorgabe haben magst, könnte man das dort auskoppeln. Ich wollte/werde das Projekt hier im Forum noch ausführlicher vorstellen. Aktuell komme ich nur nicht dazu, weil ich schon am nächsten Thema bastle und da zum Unmut meiner Frau die ganze Zeit reinfließt (Vorgabe des Ziel-Ladestands). Dauert also noch ein bisschen. Gruß, Mattsches EDIT: Ich vergaß zu erwähnen, dass mein Modul aktuell nur auf WARP1 läuft.

Soweit ich das erkenne, hat der e-Golf300 einen Zweiphasenlader. 2400 W / 230 V / 2 = 5,2 A - das kommt in etwa hin, wenn der Golf selbst auf 5 A abregelt.

Ja, jetzt funktioniert es. Danke!

Ein kleiner Fehler ist mir noch aufgefallen: Zeile 374 ff. von pio_hooks.py müsste heißen specialize_template(os.path.join("web", "main.scss.template"), os.path.join("web", "src", "main.scss"), { '{{{module_pre_imports}}}': '\n'.join(['@import "scss/modules/pre_{0}";'.format(x.under) for x in pre_scss_entries]), '{{{module_post_imports}}}': '\n'.join(['@import "scss/modules/post_{0}";'.format(x.under) for x in post_scss_entries]) }) das "scss/" beim Import hat noch gefehlt.

Sehr cool, vielen Dank für die schnelle Implementierung! Ihr seid einfach top, so macht das Spaß!

Vergleiche mal die beiden Pfade. Deine mosquitto.conf wird gar nicht geladen, sondern die aus dem entsprechenden Unterverzeichnis. Dort musst du die beiden Zeilen eintragen.

Hallo zusammen, ich habe ein etwas spezielles Anliegen. Ich baue ja gerade die Phasenumschaltung für meinen WARP1 (Details folgen noch, wie schon an anderer Stelle erwähnt). Dafür habe ich eine eigene Unterseite im Frontend angelegt und dort ein Diagramm mit drei Kurven eingefügt. Kurve 2 und 3 möchte ich natürlich auch stylen, so wie das aktuell noch ausschließlich für Kurve 1 geschieht. In pio_hooks.py, Z. 309 ff. gibt es eine Schleife, die SCSS-Dateien der Module umkopiert. Allerdings bleibt das so lange wirkungslos, wie die Datei nicht in der main.scss importiert wird. Ich wollte meine Ergänzung gerne minimalinvasiv machen, also mit so wenigen Änderungen am Originalrepo wie möglich. Insofern fände ich es elegant, wenn pio_hooks.py die Datei nicht nur umkopiert, sondern auch gleich in die main.scss aufnimmt, falls dort nicht schon vorhanden. Zum Beispiel so ab Z. 318: main_scss = os.path.join('web', 'src', 'scss', 'main.scss') with open(main_scss) as f: file_content = f.read() f.close() assert file_content, main_scss + ' could not be read' scss_module_import = '@import "modules/' + os.path.splitext(scss_name)[0] if not scss_module_import in file_content: with open(main_scss, 'a') as f: f.write('\n') f.write(scss_module_import + '";') f.close() Was meint ihr? Ich wollte einen Pull Request erstellen, doch irgendwiee bin ich zu doof dazu. Viele Grüße, Matthias

Die zusätzlichen Bricklets habe ich ähnlich montiert, wie der ESP32-Brick und auch das RS485-Bricklet angebracht werden: Löcher in die Kunststoffplatte, Gewinde reingeschnitten und mit Distanzhülsen dort festgeschraubt. Das schaut dann so aus (links unten Industrial Quad Relay, rechts daneben Digital In, oben rechts RS485):

Was meinst du mit vertikaler Hutschienenbefestigung? Du brauchst zum Schalten des CP ein zusätzliches Relais, das auf dem "alten" EVSE Bricklet nicht drauf ist. Aber das könntest du über ein Bricklet ergänzen, wie Bastian oben geschrieben hat: Ich baue gerade in meinen WARP1 eine Phasenumschaltung ein, indem ich das vierpolige Schütz durch drei zweipolige ersetze und diese über zusätzliche Bricklets ansteuere und überwache (Industrial Digital Out 4 und In 4). Bislang habe ich da keine CP-Trennung vorgesehen, weil ich die bei unserem Auto nicht zu brauchen scheine. Aber am 4 DO Bricklet ist noch ein Relais frei, das man für diesen Zweck einsetzen können sollte. Ich werde hier im Forum informieren, wenn ich einen halbwegs stabilen Stand habe. Danke bei der Gelegenheit an Eric und Bastian bzw. die ganze Tinkerforge-Truppe für den ausgezeichneten Support und die schnellen Reaktionen hier im Forum! Das ist echt top! 👍

Hallo ihr beiden, sorry für die Verspätung - ich bin noch ganz in mein Änderungsprojekt hier versunken. Danke für die Hinweise bzgl. Firmwareupdate über Brickv! Das beruhigt mich. Wenn ich das nächste Mal die Firmware schrotte, probiere ich das mal aus.

So, nach langer Zeit mal wieder eine Rückmeldung: Ich habe erst anlässlich der V1.3.2 umgestellt auf das neue Repo. Das hat an sich prima geklappt, die Struktur finde ich auch deutlich übersichtlicher. Zudem wird das Frontend jetzt nicht mehr gebaut, wenn man dort keine Änderungen gemacht hat. Früher war das meine ich nicht so. Ich finde das sehr cool, das Bauen geht dadurch meist wesentlich schneller. Die Umstellung der Lokalisierungstexte musste ich noch nachturnen, aber auch hier finde ich die jetzige Lösung wesentlich eleganter. Ähnlich die Änderungen des HAL (Stichwort tf_base58_encode statt find_uid_by_did), aber auch das ging. Man kann sich ja alles schön zusammenklauen. Also: Alles bene. Ich bastle weiter. 🙂

Hi, bei meinen Softwareumbauten (Phasenumschaltung) habe ich es durch meine jüngste Änderung geschafft, die Firmware so zu schrotten, dass das Webinterface nicht mehr hochkommt (FUBAR - fucked up beyond all recognition ;-) ). Nach Abziehen der zusätzlichen Bricklets (ich schalte meinen Code nur scharf, wenn die gefunden werden) konnte ich die Kiste wieder erreichen - puh. Ich habe also keine unmittelbare Not mehr. Aber: Ich konnte und kann den ESP32-Brick nicht im Brick Viewer finden. Erst habe ich es in der Ubuntu-VM probiert, dann auch direkt auf meinem Windows Host. Alles installiert, Rechner zwischenzeitlich auch neu gestartet - findet nichts. Im Geräte-Manager taucht der CP2102N auch als unbekanntes Gerät auf. Scheint, als habe es bei der Treiberinstallation ein Problem gegeben oder als sei kein Treiber mit installiert worden. Im brickd Log finden sich auch entsprechende Einträge. Habt ihr eine Idee, was ich tun kann? Wie gesagt, ich habe keine unmittelbare Not. Man kann sagen, ich hatte Glück, dass meine Setup-Routine greift. Aber es beunruhigt mich, brickv aktuell nicht als Rückfalloption für ein Zurücksetzen zu haben, wenn dieser Weg mal nicht funktionieren sollte. Vielen Dank schon mal! brickd.log

Hi Eric, vielen Dank auch für die Rückmeldung und die allgemein super Unterstützung! Ich habe mich gestern mit meinem eigenen Klassentemplate für die beiden Bricklets herumgeschlagen. Ich hatte mich daran festgebissen, denselben Weg zu nehmen, den ich in deinem device_module gesehen hatte. Heute morgen ist der Groschen gefallen, der Konstruktor innerhalb meiner phase_switcher-Klasse war das Problem. Nun arbeite ich mich weiter vor. Kann sein, dass ich mich wegen api.callCommand nochmal melde, wenn ich das nicht alleine auf die Kette bekomme. Aber erstmal habe ich ordentlich Futter für die leider wenige zur Verfügung stehende Zeit. Schöne Grüße, Matthias

Hallo Erik, ich arbeite mich hier Stück für Stück weiter vor. Leider habe ich immer nur abends ein bisschen Zeit, bis halt die Augen zufallen. Aber es geht voran. Darf ich nochmal mit ein paar Grundsatzfragen kommen? Ich arbeite ja an einer Phasenumschaltung in meiner WARP1 (mittels dreier Schütze statt des einen vierpoligen; Details dazu werde ich bei Erfolg hier dann vorstellen). Dazu habe ich ein Industrial Quad Relay und ein Industrial Digital In 4 Bricklet ergänzt (für Ansteuerung und Überwachung der Schütze). Für meine Funktionsergänzung habe ich ein neues Modul "phase_switcher" eingefügt und mit dem Industrial Quad Relay verknüpft (wenn man das so nennen kann): phase_switcher.h: class PhaseSwitcher : public DeviceModule<TF_IndustrialQuadRelayV2, industrial_quad_relay_v2_bricklet_firmware_bin, industrial_quad_relay_v2_bricklet_firmware_bin_len, tf_industrial_quad_relay_v2_create, tf_industrial_quad_relay_v2_get_bootloader_mode, tf_industrial_quad_relay_v2_reset> { public: PhaseSwitcher(); void setup(); void register_urls(); void loop(); private: void setup_industrial_quad_relay(); void update_all_data(); (...) }; phase_switcher.cpp: (...) PhaseSwitcher::PhaseSwitcher() : DeviceModule("industrial_quad_relay", "industrial_quad_relay", "phase_switcher", std::bind(&PhaseSwitcher::setup_industrial_quad_relay, this)) { phase_switcher_state = Config::Object({ {"active_phases", Config::Uint8(1)} // 0 - no phase active, 1 - one phase active, 2 - two phases active, 3 = three phases active }); } (...) Dank deiner Tipps zum EVSE-Bricklet konnte ich die Firmware des Industrial Quad Bricklets bauen und einbinden, und die Ansteuerung der Ausgänge funktioniert soweit (was mich schonmal sehr freut). Nun meine Fragen: Wie bekomme ich das Digital In Bricklet mit in das Modul hinzu? Mittels Mehrfachvererbung, in der Art? class PhaseSwitcher : public DeviceModule<TF_IndustrialQuadRelayV2, industrial_quad_relay_v2_bricklet_firmware_bin, industrial_quad_relay_v2_bricklet_firmware_bin_len, tf_industrial_quad_relay_v2_create, tf_industrial_quad_relay_v2_get_bootloader_mode, tf_industrial_quad_relay_v2_reset>, DeviceModule<TF_IndustrialDigitalIn4V2, industrial_digital_in_4_v2_bricklet_firmware_bin, industrial_digital_in_4_v2_bricklet_firmware_bin_len, tf_industrial_digital_in_4_v2_create, tf_industrial_digital_in_4_v2_get_bootloader_mode, tf_industrial_digital_in_4_v2_reset> { Gibt es auch die Option, ein Bricklet ins Modul einzubinden, ohne die Firmware einbetten zu müssen? Bei den beiden von mir genutzten Bricklets werde ich die Firmware vermutlich nicht anpassen müssen, die könnten einfach so werkeln. Aus meinem Modul heraus muss ich den Ladevorgang im EVSE starten und stoppen und den Stromsollwert vorgeben. Mache ich das über die API (api.callCommand) oder gibt es dazu einen besseren Weg? Vielen Dank und schöne Grüße, Matthias P.S. Auch wenn die Angelegenheit herausfordernder ist als gedacht, finde ich euer System echt cool, vor allem die Offenheit!

Ach stimmt, klar...! Hätte ich drauf kommen können, wer lesen kann, ist klar im Vorteil. Jetzt baut alles sauber durch. Besten Dank!

Cool, vielen Dank dafür! Jetzt muss ich mal sehen, wie ich voran komme. Ich kann leider nur ab und zu abends was machen, mehr lassen Job und Familie nicht zu. Aber ich werde berichten. EDIT: Auf dem aktuellen Codestand bekomme ich nun folgenden Compilerfehler: src/modules/evse/evse.h:25:10: fatal error: device_module.h: No such file or directory Kann es sein, dass die Header-Datei nicht eingecheckt ist? Im Repo finde ich sie tatsächlich nicht.

Top, vielen Dank für die schnelle und ausführliche Antwort! Jetzt habe ich eine Vorstellung. Muss mal schauen, ob ich das EVSE überhaupt anfassen muss. Die Ansteuerung der Schütze wird über ein Industrial Relay Bricklet laufen, insofern ist dafür der ESP zuständig. Evtl. werde ich aber die Funktion des Tasters noch erweitern, um die externe Laderegelung überstimmen und ein sofortiges Schnellladen starten zu können.

Hallo, ich möchte gerne Anpassungen an der Firmware meines WARP1 vornehmen, perspektivisch, um eine Phasenumschaltung direkt in der Wallbox zu realisieren (durch Ersetzen des vierpoligen Schützes durch drei zweipolige). Ich bin gerade noch dabei, die Toolchain aufzusetzen und mich in die Struktur einzuarbeiten. Das Bauen der WARP-Firmware mit Platformio funktioniert grundsätzlich, zumindest wenn ich den Stand der Version 1.2.4 auschecke (für WARP + ESP32). Nun meine Frage: Wenn ich für meine Änderungen auch die Firmware des ESVE ändern müsste, wie würde ich das machen? In der WARP-Firmware scheint sie mir binär eingebunden zu sein. Eine Codeänderung müsste ich dann im EVSE-Repo vornehmen. Stimmt das so? Und wenn ja, wie bekomme ich diese geänderte Version dann in meine WARP-Firmware? Sorry, wenn das vielleicht Anfängerfragen sind. Ich bin in der Tat mit Platformio bislang nicht vertraut. Wäre klasse, wenn ihr mir einen Tipp hättet. Besten Dank dafür schon einmal!

Hallo, über das Problem bin ich gerade auch etwas länger gestrauchelt, bis ich dann die obigen Post gefunden habe. Vorschlag: Eine zusätzliche Zeile mit diesem Hinweis in der Reame.txt in warp-charger/software wäre enorm hilfreich. Denn an die habe ich mich beim Aufsetzen der Build-Toolchain gehalten. Zuvor hatte ich mit dem Setup-Skript für die Build-Umgebung meine Probleme. Unter Ubuntu 21.04 (VirtualBox Image von osboxes.org) kam es immer zu einem "Authentication error", während und nachdem das Skript lief bzw. gelaufen war. Eine Anmeldung am System war nicht mehr möglich, irgendwas war so gründlich zerschossen, dass ich die VM komplett zurücksetzen musste. Gefixt bekam ich das schlussendlich, indem ich nach dem nach dem sudo apt-get update ein sudo apt-get -y dist-upgrade zugefügt habe (Zeile 14/15).

Die Box presst gar nichts. Die Box ist im Prinzip ein vierpoliges Schütz, das alle angeschlossenen Phasen ans Auto durchschaltet. Plus Elektronik für Überwachung und Kommunikation, um dem Auto den maximalen Ladestrom (pro Phase) mitzuteilen. Der ist der kleinste Wert aus maximalem Strom der Box (=des angeschlossenen/mitbestellten Ladekabels) Einstellung der DIP-Schalter in der Box (=der Zuleitung) Vorgabe über den Webserver oder eine der APIs der Box Bei einer 16A-Box wird das Auto also alle durch den Lader nutzbaren Phasen (beim Golf nach deiner Aussage zwei) mit max. 16 A belasten.