Umbau Phasenumschaltung für WARP 1

[fepilins]

Hallo zusammen,

ich wäre an dem Umbau auch sehr interessiert, mit 5,85 kWp ist unsere PV Anlage die meiste Zeit leider zu klein für 2-phasiges Laden (eGolf 300). Ich würde mich gerne als Betatester der Anleitung anbieten. Als IT Systemelektroniker habe ich auch die entsprechende Fachkenntnis. Genial wäre auch die CP Trennung, da der eGolf diese wohl benötigt, jedenfalls fängt unser nicht wirklich zuverlässig wieder mit dem laden an.

Die Hardware würde ich dann gerne schon mal ordern, der Link vom Quad Relay ist inzwischen übrigens dieser hier

https://www.tinkerforge.com/de/shop/industrial-quad-relay-v2-bricklet.html

Gruß Felix

 

[ThomKa]

@fepilins Hallo Felix. Entschuldige erst einmal, dass die Antwort so lange auf sich warten ließ. Ferien, Urlaubszeit, Kids, usw 😉.

Also ich kann nur für meinen Teil der Anleitung für den Umbau antworten... Ab nächster Woche bin ich mehrere Wochen auf REHA. Dazu hat mein Lieferant mich gerade verladen und ich muss die Schütze neu bestellen. Somit kommen diese nicht mehr vor der REHA an. Eine Anleitung wird es damit wohl erst im SEP/OKT geben 🤷‍♂️. Das kann ich leider nicht beschleunigen.

@mattsches Matthias und ich sind nicht abgestimmt. Aber wenn ich es richtig verstanden habe, fehlt Matthias die Zeit für eine nötige Fehlerbehebung, Aktualisierung und damit auch für Deine Anfrage der CP-Trennung. Das muss uns allen klar sein, also denen die sich für den Nachbau von Matthias' Projekt entscheiden. ABER, ich habe bislang keine Alternative zu Matthias' Projekt gefunden (wenn die kompletten Messeinrichtungen schon vorhanden sind) und bin wirklich gerne bereit entsprechend zu warten. Zwischenzeitlich versuche ich mich noch in C einzuarbeiten, um später vielleicht unterstützen zu können. 

Solltest Du keine Messeinrichtung zur PV-Überschuss-Bestimmung haben, wäre die Lösung mit dem "TF Energy Manager" sicher eine Alternative. Dies wäre der Thread dazu.

Ach so... Einen hatte ich noch vergessen: Eventuell benötigst Du ja noch die Build-Umgebung. Dieser Thread beschreibt das Vorgehen unter WIN.

So long und bis !später!, Thomas

bearbeitet August 4, 2022 at 09:12 von ThomKa

[ThomKa]

Am 19.7.2022 um 12:21 schrieb floho:

Wo ist das Problem? Wenn man den Artikel sucht gibt es doch mehrere:

z.b: https://www.conrad.com/p/finder-227200121310-remote-switch-2-makers-230-v-ac-400-v-ac-1-pcs-2474635

Ich denke eher Finder bar noch kein Bild veröffentlicht und Sie nehmen eben ein ähnliches. 

Hat eigentlich schon irgendjemand die 32A Variante geliefert bekommen? Alle abgefragten Händler und zwischenzeitlich platzierte Bestellungen informieren mich, dass eine Lieferung erst in 03-2023 möglich sei 🤪. Kennt jemand noch einen Händler mit Bestand?

Der Hinweis von CONRAD, VOELKNER mit Lieferung ab 29.08. ist sinnlos. Die haben keinen Bestand und auch keine Bestellung im Zulauf und der Hersteller FINDER hat mittlerweile keine mehr an Lager und erwartet die Nächste Lieferung in 01-2023...

[fepilins]

@ThomKa Passt für mich soweit, Zeit ist nicht so der entscheidende Faktor, gerade bin ich noch gut damit beschäftigt meinen PV Speicher aufzubauen. Messeinrichtung ist schon vorhanden aber kein Platz mehr in den Verteilungen für Energymeter und Schütz. Derzeit regel ich den PV Überschuss mit evcc aus, aber ansonsten kann ich auch eine Logik in meine Haussteuerung bauen.

Für den Energy Meter müsste ich ja auch noch den Zähler in meiner WARP Pro v1 tauschen, da der bei 1-phasigem Anschluss ja nicht funktioniert. Ich müsste also so oder so an die Box ran und dann gehe ich den Weg es dort direkt einzubauen.

Die Software von @mattsches sag schon gut aus und ich habe durchaus Interesse mich da weiter einzuarbeiten. C Erfahrung ist schon etwas eingerostet, aber die meisten Dinge im Code verstehe ich noch. CP Trennung sehe ich auch erstmal als Übernächsten Schritt. In der WARP 2 ist diese ja schon vorhanden, ich kann aktuell nur nicht abschätzen wie Aufwändig die Portierung in die WARP 1 ist und ob es so einfach möglich ist den "Ausgang" umzubiegen.

 

[mattsches]

Am 15.7.2022 um 10:01 schrieb rtrbt:

Du solltest hier: sicherheitshalber https://www.tinkerforge.com/en/doc/Software/Bricklets/IndustrialQuadRelayV2_Bricklet_uC.html#c.tf_industrial_quad_relay_v2_set_monoflop

statt set_value verwenden, zumindest für die Channels bei denen du das Schütz durchschaltest. Das hat den Vorteil, dass falls der ESP aus irgendeinem Grund abschmiert oder hängt, das Quad Relay abschaltet, wenn der Monoflop abgelaufen ist.

@rtrbt: Ich dachte eigentlich, ich hätte das im Sack. Habe aber nun - mit einiger Verspätung - festgestellt, dass bei einem Reboot und auch wenn das Programm an anderer Stelle (HTTPS Request in meinem SOC-Modul) etwas länger braucht, alle vier Ausgänge des Bricklets angesteuert werden.

Mein Code sah so aus:

void PhaseSwitcher::write_outputs()
{
    static Config *evse_low_level_state = api.getState("evse/low_level_state", false);

    if (evse_low_level_state == nullptr)
        return;

    bool evse_relay_output = evse_low_level_state->get("gpio")->get(3)->asBool();
    bool channel_request[4] = {false, false, false, false};

    if (evse_relay_output && !contactor_error){
        if (enabled){
            switch (requested_phases)
            {
            case 0:
                break;
            case 1:
                channel_request[1] = true;
                break;
            
            case 2:
                channel_request[1] = true;
                channel_request[2] = true;
                break;

            default:
                channel_request[1] = true;
                channel_request[2] = true;
                channel_request[3] = true;
                break;
            }
        } else if (!enabled){
            channel_request[1] = true;
            channel_request[2] = true;
            channel_request[3] = true;
        } 
    }

    int retval;
    for (int channel = 0; channel <= 3; channel++) {
        retval = tf_industrial_quad_relay_v2_set_monoflop(&quad_relay_bricklet.device, channel, channel_request[channel], 1000);
        if (retval != TF_E_OK) {
            logger.printfln("Industrial quad relay set monoflop failed for channel %d (rc %d).", channel, retval);
            return;
        }
    }
}

Die Ausgänge werden also zyklisch beschrieben mit dem zuvor jeweils ermittelten Wert. channel_request[0] wird nur initialisiert, aber nie beschrieben (Ausgang wird nicht genutzt).

Wenn dieser Abschnitt so aktiv ist, gehen wie schon gesagt alle vier Ausgänge des Bricklets beim Reboot auf True und fallen wieder ab, sobald das Programm gestartet ist.

Nehme ich die letzte Schleife mit den Monoflop-Aufrufen raus und rufe das Monoflop einmalig in einer Testroutine auf, dann bleibt der Ausgang  für die parametrierte Zeit aktiv, fällt dann ab und bleibt auch beim Reboot aus.

Irgendwie stehe ich auf dem Schlauch, ich komme nicht drauf, wo mein Denkfehler liegt. Hast du mir vielleicht einen heißen Tipp?

Vorübergehend habe ich wieder auf tf_industrial_quad_relay_v2_set_value umgestellt. Aber das Monoflop wäre ja schon besser.

Danke & Gruß,

Matthias

bearbeitet August 6, 2022 at 09:37 von mattsches

[rtrbt]

Du solltest, wenn du in channel_request[channel] ein false hast eher mit set_value das Relay dauerhaft auf offen setzen. Monoflops funktionieren in beide Richtungen, d.h. wenn du tf_industrial_quad_relay_v2_set_monoflop(...0, false, 1000) aufrufst dann wird (egal was der aktuelle Zustand ist!) Channel 0 eine Sekunde öffnen und danach wieder schließen. Du hast also _immer_ einen Zustandsübergang am Ende des Monoflops, egal ob es am Anfang einen gab.

[ThomKa]

Moin zusammen. Habe noch eine passende Informationsquelle zum Thema gefunden. Ist vielleicht interessant, wenn man sich tiefer mit dem Thema auseinandersetzen möchte. Gruß, Thomas

https://www.mechatronik.uni-bayreuth.de/pool/dokumente/news/21-tpa-pulse.pdf

[mattsches]

@rtrbt: Vielen Dank für die Erklärung! Ich komme aus der (Maschinen-)Steuerungsprogrammierung. Monoflops kannte ich zwar als Begriff, doch in der Steuerungstechnik sind mir die nie begegnet. Ich werde das mal wie von dir vorgeschlagen einbauen, dann sollte ich das Schalten hoffentlich erledigt haben. Aktuell bin ich noch damit beschäftigt, eure Refactorings nachzuziehen...

[ThomKa]

Hallo zusammen,

für alle die mitlesen und die WARP mit Phasenumschaltung vom ioBroker ansteuern wollen, findet Ihr (m)eine Umsetzung in Blockly. Vielleicht hilft es dem ein oder anderen. Feedback und Verbesserungen gerne und jederzeit 😉.

Grundlegender Ablauf:

• Aktueller Strom-Einspeisewert wird von einem SmartMeter zur Verfügung gestellt.
• Dieser Wert wird in Intervallen geprüft und in einen mqtt-Übergabe-Datenpunkt geschrieben
• Die Werte werden wiederkehrend per mqtt an die WARP übertragen
• Die WARP steuert auf Basis der gesetzten Parameter die 3 Installationsschütze und schaltet diese zu/ab 
• Weiterführende Informationen können über den Adapter "WARP Charger" im iob verwendet/visualisiert werden

Im Bereich USERDATA wurden folgende Datenpunkte angelegt:

0_userdata.0.Warp.

Passender JSON-Inhalt: 0_userdata.0.Warp.json

Erläuterung:

• Hysterese: Notwendige Wertänderung, bevor der PV-Überschuss ermittelt/übertragen wird
• Intervall: Dauer bis zur nächsten Übermittlung
• Zeitraum: PV-Überschuss-Ermittlung/Übertragung nur zwischen 11:00 und 19:59 Uhr. Entlastet den RaspI ein wenig.
• pv-ueberschuss: Der letzte ermittelte PV-Überschuss-Wert. Dieser wird per influxDB und Grafana später visualisiert.

Das zu gehörige Blockly sieht wie folgt aus:

Passender Blockly-Export: WARP_PV-Überschuss_Blockly.json

Erläuterung:

• Im Abschnitt 1. werden die Variablen einmalig beim Start des Scripts geladen.
• Abschnitt 2. dient dazu den Hysterese-Wert im Betrieb ändern zu können, ohne das Script neu starten zu müssen.
• Im Abschnitt 3. wird ein CRON-Zeitplan einmalig beim Start des Scripts eingerichtet.
  Im Bsp. wird dann in der Zeit von 11:00 bis 19:59 Uhr (Zeitraum), alle 15 Sekunden (Intervall) der letzte PV-Überschuss-Wert (_alt) mit dem aktuellen PV-Überschuss-Wert (_neu) verglichen und geprüft ob die Werte größer der 100 W (Hysterese) abweichen. Sofern dies der Fall, wird der PV-Überschuss-Wert (_neu) an die WARP übergeben (mqtt.0.SH-248-TF-WARP.phase_switcher.available_charging_power). Abschließend wird der "_neu"-Wert als "_alt"-Wert gespeichert und die Intervalldauer abgewartet.
• Abschnitt 4. dient der Änderung der Vorgabewerte "Zeitraum" und "Intervall" im Betrieb ändern zu können, ohne das Script neu starten zu müssen.
  Dazu wird zu erst der noch laufende CRON-Zeitplan gestoppt, die neuen Vorgabewerte übernommen und dann der CRON-Zeitplan mit den neuen Vorgabewerten gestartet. Die restlichen Aufrufe sind identisch zu 3.

Unter mqtt sieht es dann so aus:

mqtt.0.SH-248-TF-WARP.phase_switcher.available_charging_power nimmt den aktuellen PV-Überschuss-Wert auf.

Im Adapter "WARP Charger" stehen folgende Informationen zur Verfügung:

warp.0.phase_switcher.state.

Gerade die Werte "active_phases" bzw. "requested_phases_pending" und die "available_charging_Power" können dann z.B. visualisiert werden.

Um die Informationen zu komplettieren noch die Ansicht in der WARP und Grafana:

Abgebildet findet sich eine übergebene PV-Überschuss von ~ 2,5 kW mit dazu passender, angeforderter Phasenanzahl von 1ner Phase. und dazu die Übersicht der letzten 30 Minuten in Grafana.

Die Darstellung zeigt bislang nur die angeforderte Phasen-Anzahl, da noch kein BEV zur Ladung existiert. Aber die Funktion kann somit geprüft werden.

 

Vielen Dank an der Stelle erneut an @mattsches. Du  hast da echt eine geile Lösung geschaffen 👍.

Einen Leitfaden zum elektro-technischen Umbau der WARP ist in Abstimmung mit @mattsches und @fepilins und wird die nächsten Wochen zur Verfügung gestellt.

Beste Grüße und viel Erfolg, Thomas

bearbeitet August 31, 2022 at 12:25 von ThomKa
Ergänzung

[fepilins]

Hallo zusammen,

ich versuche mich gerade daran die SW etwas anzupassen. Dazu wollte ich das Modul in dem aktuellem SW Stand einbinden. Ich bekomme aber noch folgende Fehler und stehe komplett auf dem Schlauch:

Compiling .pio/build/warp_ps/src/modules/phase_switcher/phase_switcher.cpp.o
src/modules/phase_switcher/phase_switcher.cpp: In member function 'void PhaseSwitcher::register_urls()':
src/modules/phase_switcher/phase_switcher.cpp:210:6: error: no matching function for call to 'WebServer::on(const char [40], http_method, PhaseSwitcher::register_urls()::<lambda(WebServerRequest)>)'
     });
      ^
In file included from src/api.h:29,
                 from src/device_module.h:28,
                 from src/modules/phase_switcher/phase_switcher.h:25,
                 from src/modules/phase_switcher/phase_switcher.cpp:17:
src/web_server.h:113:23: note: candidate: 'WebServerHandler* WebServer::on(const char*, httpd_method_t, wshCallback)'
     WebServerHandler *on(const char *uri, httpd_method_t method, wshCallback callback);
                       ^~
src/web_server.h:113:23: note:   no known conversion for argument 3 from 'PhaseSwitcher::register_urls()::<lambda(WebServerRequest)>' to 'wshCallback' {aka 'std::function<WebServerRequestReturnProtect(WebServerRequest)>'}
src/web_server.h:114:23: note: candidate: 'WebServerHandler* WebServer::on(const char*, httpd_method_t, wshCallback, wshUploadCallback)'
     WebServerHandler *on(const char *uri, httpd_method_t method, wshCallback callback, wshUploadCallback uploadCallback);
                       ^~
src/web_server.h:114:23: note:   candidate expects 4 arguments, 3 provided

Kann mich vielleicht jemand in die richtige Richtung stoßen?

Es geht um diese Aufrufe:

server.on("/phase_switcher/requested_power_history", HTTP_GET, [this](WebServerRequest request) {
        if (!initialized) {
            request.send(400, "text/html", "not initialized");
            return;
        }
        
        const size_t buf_size = PHASE_SWITCHER_RING_BUF_SIZE * 6 + 100;
        char buf[buf_size] = {0};
        size_t buf_written = 0;

        int16_t val;
        
        requested_power_history.peek(&val);
        // Negative values are prefilled, because the ESP was booted less than 48 hours ago.
        if (val < 0)
            buf_written += snprintf(buf + buf_written, buf_size - buf_written, "%s", "[null");
        else
            buf_written += snprintf(buf + buf_written, buf_size - buf_written, "[%d", (int)val);

        for (int i = 1; i < requested_power_history.used() && requested_power_history.peek_offset(&val, i) && buf_written < buf_size; ++i) {
            // Negative values are prefilled, because the ESP was booted less than 48 hours ago.
            if (val < 0)
                buf_written += snprintf(buf + buf_written, buf_size - buf_written, "%s", ",null");
            else
                buf_written += snprintf(buf + buf_written, buf_size - buf_written, ",%d", (int)val);
        }

        if (buf_written < buf_size)
            buf_written += snprintf(buf + buf_written, buf_size - buf_written, "%c", ']');
        
        request.send(200, "application/json; charset=utf-8", buf, buf_written);
    });

Es hat was hier mit zu tun, aber die Lösung habe ich gerade noch nicht

 

Gruß Felix

bearbeitet August 31, 2022 at 12:42 von fepilins

[photron]

Die Webservr::on() Methode erwartet jetzt, dass die Rückgabe des request.send() Aufrufs zurückgegeben wird.

server.on("/phase_switcher/requested_power_history", HTTP_GET, [this](WebServerRequest request) {
        if (!initialized) {
            // ÄNDERNUG HIER
            return request.send(400, "text/html", "not initialized");
        }
        
        const size_t buf_size = PHASE_SWITCHER_RING_BUF_SIZE * 6 + 100;
        char buf[buf_size] = {0};
        size_t buf_written = 0;

        int16_t val;
        
        requested_power_history.peek(&val);
        // Negative values are prefilled, because the ESP was booted less than 48 hours ago.
        if (val < 0)
            buf_written += snprintf(buf + buf_written, buf_size - buf_written, "%s", "[null");
        else
            buf_written += snprintf(buf + buf_written, buf_size - buf_written, "[%d", (int)val);

        for (int i = 1; i < requested_power_history.used() && requested_power_history.peek_offset(&val, i) && buf_written < buf_size; ++i) {
            // Negative values are prefilled, because the ESP was booted less than 48 hours ago.
            if (val < 0)
                buf_written += snprintf(buf + buf_written, buf_size - buf_written, "%s", ",null");
            else
                buf_written += snprintf(buf + buf_written, buf_size - buf_written, ",%d", (int)val);
        }

        if (buf_written < buf_size)
            buf_written += snprintf(buf + buf_written, buf_size - buf_written, "%c", ']');
        
        // ÄNDERNUG HIER
        return request.send(200, "application/json; charset=utf-8", buf, buf_written);
    });

 

[fepilins]

🤦‍♂️ Ouh man, das wars. Danke, bin was die Programmierung in diesem Umfeld angeht noch auf noob Level.

[deepflyer911]

Grüße zusammen,

bin soweit vorbereitet, dass der Hardwareumbau starten kann. Würde nun gerne bereits zuvor die passende Firmware für die Phasenumschaltung instalieren. Allerdings ist es für mich ein komplettes Buch mit sieben Siegeln. Auch mit der Anleitung von Mattches auf github komme ich nicht wirklich weiter. Da scheitert es bei mir schon, dass der Link zur esp32-firmware nicht funktioniert und ich nichtmal weiß was damit gemeint ist...

Gibt es hier jemanden, der mir da unter die Arme greifen kann?

[mattsches]

Anbei mal mein aktueller Entwicklungsstand, wie ich ihn gerade auf Github eingecheckt habe. Ich habe einige Änderungen vorgenommen, um das Umschaltverhalten etwas zu optimieren. Das Ganze gibt es aber wie schon mehrmals erwähnt ohne Gewährleistung und ohne jedes Versprechen auf zukünftige Updates. Die baue ich zwar immer wieder, doch werde mich nicht festlegen, in welcher Frequenz und wie lange ich das mache. Mein Beitrag hier im Forum richtet sich vorrangig an diejenigen, die sich in der Lage sehen, zur Not selbst Hand anzulegen.

Daher nochmal ausdrück die Warnung - auch an andere, die hier vielleicht mitlesen: Verwendung auf eigene Gefahr!

Und noch ein Hinweis: Wenn der Umbau gemäß meinen Angaben oder der demnächst von @ThomKa erscheinenden, sehr guten Anleitung vorgenommen wurde, kann die Standard-Firmware die Schütze nicht mehr ansteuern. Der Weg zurück ist natürlich nicht verbaut, aber er erfordert den Umbau zurück auf das vierpolige Schütz mit 230 V-Spule.

Wen das alles nicht abhält: Die angehängte Firmware lässt sich ganz normal über das Web-Frontend einspielen. Außer Log-Einträgen, dass die Phasenumschaltung und die Ladestandsabfrage (funktioniert nur für Fiat) deaktiviert wurden, wird man jedoch keinen Effekt feststellen, solange der Umbau nicht erfolgt ist. Die entsprechenden Seiten im Frontend sind dann gar nicht erst sichtbar. Denn die Firmware erkennt, wenn die beiden zusätzlichen Bricklets nicht angeschlossen sind, und aktiviert die Softwaremodule erst gar nicht.

Noch eine Frage: Du schreibst

Am 1.10.2022 um 22:17 schrieb deepflyer911:

Auch mit der Anleitung von Mattches auf github komme ich nicht wirklich weiter. Da scheitert es bei mir schon, dass der Link zur esp32-firmware nicht funktioniert und ich nichtmal weiß was damit gemeint ist...

Welchen Link meinst du denn genau?

warp_firmware_2_0_7_633aea44_merged.bin

[deepflyer911]

vor 2 Stunden schrieb mattsches:

Noch eine Frage: Du schreibst

Welchen Link meinst du denn genau? 

Moin Mattsches,

herzlichen Dank für die Antwort. Ich meine den Link in der readme.md

"For building the firmware, clone the repository and symlink the phase_switcher directories to the backend and frontend directories in the esp32-firmware repository:"

Gruß

[ThomKa]

@deepflyer911 Hi, da Mattsches die FW nun direkt in den Thread gepackt hat, ist der Build ja nicht mehr nötig.

Angefügt findet Du nun auch die aktuelle Version des Leitfadens. 

Für Rückmeldungen und Verbesserungen sind wir immer offen.

Beste Grüße, Thomas 

@mattsches Immer noch "great work" für Deine Realisierung. Ich bin immer noch der Meinung TF sollte es in den Standard übernehmen...

 

351148638_1118196972_Leitfaden_Umbau_WARP1_PV-berschussladen_Phasenschaltung(1).pdf

[deepflyer911]

vor 7 Minuten schrieb ThomKa:

@deepflyer911 Hi, da Mattsches die FW nun direkt in den Thread gepackt hat, ist der Build ja nicht mehr nötig.

Angefügt findet Du nun auch die aktuelle Version des Leitfadens. 

Für Rückmeldungen und Verbesserungen sind wir immer offen.

Beste Grüße, Thomas 

@mattsches Immer noch "great work" für Deine Realisierung. Ich bin immer noch der Meinung TF sollte es in den Standard übernehmen...

 

351148638_1118196972_Leitfaden_Umbau_WARP1_PV-berschussladen_Phasenschaltung(1).pdf 2 MB · 0 downloads

Hey ThomKa,

 

ja das Problem hatte sich durch die Bereitstellung von Mattsches erledigt. Kann dir nur beipflichten, ein ganz tolles Projekt von Mattsches mit Potential zur Standartisierung seitens TF. Aber auch deine Anleitung ist anz großes Kino! Danke dafür.

Gruß

[deepflyer911]

Grüße zusammen. Habe die Installation abgeschlossen. Wallbox ist wieder aktiv und zeigt im Webinterface keine Probleme.

Ist es richtig, dass man im Webinterface keine Ladung starten kann? Doppelter Tastendruck an der Box aktiviert die unmittelbare Ladung mit maximaler Power, richtig?

[mattsches]

Hast du Autostart aktiviert? Dann startet die Ladung automatisch, sobald es die Leistungsvorgabe zulässt (also bei 6 A * 230 V = 1380 W und nach Ablauf der eingestellten Verzögerungszeit).

Schnellladen geht durch Drücken des Tasters für >2 Sekunden.

Ich habe zwischenzeitlich aber ein paar Änderungen vorgenommen, um das Umschaltverhalten zu verbessern. Ich hänge hier mal meinen aktuellen Entwicklungsstand rein. Der ist allerdings noch ungetestet (war heute nicht zuhause). Wann was nicht tut, einfach wieder auf den alten Stand 633aea44 zurück flashen.

warp_firmware_2_0_7_6362e2b2_merged.bin

[deepflyer911]

Moin Mattsches,

 

werde die neue Version testen.

Musste feststellen, dass die Box ohne den Taster der Frontplatte nicht startet. ;-/

Läuft jetzt also grundsätlzlich mal im Direktbetrieb bei voller Leistung.

[mattsches]

vor 12 Stunden schrieb deepflyer911:

Musste feststellen, dass die Box ohne den Taster der Frontplatte nicht startet. ;-/

Läuft jetzt also grundsätlzlich mal im Direktbetrieb bei voller Leistung.

Du meinst, dass du die Schnellladung nicht über das Web Frontend starten kannst? Ja, das ist so. Habe ich mir vor einiger Zeit als Idee aufgeschrieben, aber noch nicht umgesetzt.

Oder startet der normale (=nicht schnell/Überschuss-)Ladevorgang nicht trotz Leistungsvorgabe? Dann könntest du mal schauen, ob nach dem Einstecken unter "Ladecontroller" bei "Externe Steuerung" noch "blockiert" steht. Wenn ja, dann bitte mal die Leistungsvorgabe checken (ausreichend?). Wenn ja, dann mal die "Externe Steuerung" freigeben und schauen, ob der Ladevorgang startet.

So soll das natürlich nicht sein, ich hatte die Situation auch schon. Zwischenzeitlich nicht mehr, aber der Fix verursachte dann andere Probleme.

bearbeitet November 4, 2022 at 08:36 von mattsches

[rtrbt]

14 hours ago, deepflyer911 said:

Musste feststellen, dass die Box ohne den Taster der Frontplatte nicht startet. ;-/

Wenn der Taster nicht angeschlossen ist, ist das für die Wallbox so als ob der Taster permanent gedrückt ist (bzw. als ob der Schlüsselschalter auf deaktiviert steht).

[NicolaiD]

Vielen Dank für die Arbeit und die tolle Idee. Werde nun die Teile bestellen und mich dann um den Zusammenbau und die Leistungsanforderung mittels NodeRed meinem Vikton Venus kümmern. Wider was schönes zu basteln.

 

[deepflyer911]

Am 3.11.2022 um 20:42 schrieb mattsches:

Hast du Autostart aktiviert? Dann startet die Ladung automatisch, sobald es die Leistungsvorgabe zulässt (also bei 6 A * 230 V = 1380 W und nach Ablauf der eingestellten Verzögerungszeit).

Schnellladen geht durch Drücken des Tasters für >2 Sekunden.

Ich habe zwischenzeitlich aber ein paar Änderungen vorgenommen, um das Umschaltverhalten zu verbessern. Ich hänge hier mal meinen aktuellen Entwicklungsstand rein. Der ist allerdings noch ungetestet (war heute nicht zuhause). Wann was nicht tut, einfach wieder auf den alten Stand 633aea44 zurück flashen.

warp_firmware_2_0_7_6362e2b2_merged.bin 1 MB · 2 downloads

Moin Mattsches,

 

hatte heute Gelegenheit, die neue Version getestet. Dabei fiel mir auf, dass die Freigabe für Externe Steuerung bzw Autostart in der EVSE blockiert war. Entsprechend startete auch keine Ladung. Esrt durch manuelle Freigabe der exterenen Steuerung ging es los.

Da ich mit der vorherigen Version keine Ladung durchführen konnte, fehlt mir der Vergleich. Kennst du dieses Verhalten?

[mattsches]

Ja, der Fehler ist mir bekannt. Wenn man bei ausreichender Ladung (und Ablauf der Verzögerungszeiten) erst einsteckt und Autostart aktiv hat, dann startet das EVSE nicht durch, weil ich ihm Sollwert 0 A als Vorgabe schicke ("Externe Steuerung"). Ich hatte das schon gefixt, aber das hatte andere unschöne Seiteneffekte.

Ich habe das nun nochmal überarbeitet, kannst du bitte mit der  angehängten Version nochmal testen, ob es nun besser ist? Ich bin morgens unterwegs und kann daher die Kiste mittags nicht anstecken, wenn was vom Dach kommt.

Danke!

warp_firmware_2_0_7_6369622d_merged.bin