Ablauf bei Änderungen an EVSE-Bricklet

[mattsches]

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!

 

[rtrbt]

23 minutes ago, mattsches said:

Eine Codeänderung müsste ich dann im EVSE-Repo vornehmen. Stimmt das so?

Das stimmt soweit.

Du musst die Firmware dann bauen, dann sollte in evse-bricklet/software/build eine evse-bricklet-firmware.zbin rausfallen. Das ist im Endeffekt eine Zip-Datei. Darin gibt es die evse-bricklet-firmware.bin, das ist die eigentliche Firmware. Die kannst du mit xxd -i evse-bricklet-firmware.bin > evse_firmware.h in den Header umwandeln. Wichtig! Bevor du das machst, mach den Header auf und kopiere die ersten 8 Zeilen raus, lass dann xxd laufen, paste die 8 Zeilen wieder und passe die Versionsnummer an.

Die Wallbox-(lies ESP-)Firmware ist so gebaut, dass sie beim booten vom EVSE die installierte Firmware-Version ausliest, und wenn das eine andere ist als die, die in der ESP-Firmware eingebettet ist, diese überflasht. Wenn du also die Versionsnummer erhöhst, wird das EVSE automatisch umgeflasht.

Du hast aber folgende Alternativen:

1. Lass die Versionsnummer so, bette deine Firmware ein und drück dann nach dem ersten Booten im Webinterface unter Ladecontroller -> Low-Level-State auf neu flashen
2. Wenn du [wallbox_ip]/hidden_proxy/enable aufrufst, kannst du dich mit dem Brick Viewer auf die Wallbox verbinden und das EVSE wie jedes andere Bricklet auch flashen. Da _musst_ du dann aber die Versionsnummer so lassen, wie sie in der eingebetteten Firmware ist, weil die Wallbox ansonsten die eingebettete Firmware wieder drüber flasht.

[mattsches]

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.

[rtrbt]

Kurzes Update: Ich habe den Prozess etwas vereinfacht, du kannst jetzt Firmwares einbetten, indem du die .zbin-Datei in den Ordner des Moduls legst. Die prepare.py erstellt daraus beim Bauprozess den Header, der reinkompiliert wird.

Falls du deine Änderungen in ein eigenes Modul auslagerst, musst du dir die prepare.py aus einem der Module klauen, die Firmwares einbetten, also aus EVSE (2.0), NFC oder SDM72DM.

[mattsches]

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.

bearbeitet October 21, 2021 at 19:26 von mattsches

[rtrbt]

Du hast da gerade das Problem, dass ich seit der letzten veröffentlichten Firmware Änderungen in der esp32-lib gemacht habe. Die lib wird von PlatformIO automatisch heruntergeladen, aber nur die Version, die in der platformio.ini steht: https://github.com/Tinkerforge/warp-charger/blob/a7ebde3cebb4f00e4b80c6146b424597353efbc4/software/platformio.ini#L84 Ich aktualisiere die Versionen aber typischerweise nur bei Releases und ersetze den Eintrag (siehe den Kommentar unter der Zeile), wenn ich Änderungen an der esp32-lib habe, durch den Pfad zu meinem lokalen Checkout der esp32-lib. Du kannst aber stattdessen auch das #warp2-1.0.2 durch eine Commit-ID oder durch #master ersetzen.

Wenn du dann den Master-Branch neu runterziehen willst, kannst du die Lib mit

pio lib -e warp2 uninstall --no-save esp32-lib

deinstallieren, beim nächsten Bauen lädt PlatformIO dann die aktuelle Variante runter.

[mattsches]

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

[mattsches]

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:

1. 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> {

    

2. 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.

3. 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!

 

 

[rtrbt]

Moin Matthias,

Zu Frage 1 und 2:

Wenn du die Firmware nicht aktualisieren willst, kannst du dir den ganzen DeviceModule-Kram sparen. Das hatte ich so generalisiert, damit die doch recht vielen Firmwares alle gleich eingebettet werden und Devices gleich behandelt werden (EVSE, EVSE 2.0, RS485 und NFC).

Du musst dann nur händisch das Device initialisieren, so wie das DeviceModule::setup_device() tut, nur ohne den ensure_matching_firmware-Teil. Also UID raussuchen mit find_uid_by_did, dann die create-Funktion, z.B. tf_industrial_quad_relay_v2_create aufrufen.

Der Großteil der anderen Logik ist nur dafür da, die Firmware zu flashen und eventuell darauf zu reagieren, dass die Firmware gerade geflasht wird (deshalb der loop-Check ob das Device im Bootloader-Modus ist).

17 hours ago, mattsches said:

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?

Mach das am besten über api.callCommand, ja. Du kannst händisch auf dem EVSE arbeiten, das kannst du dir z.B. im NFC-Modul ansehen, aber über die API ist es robuster, für den Fall dass gerade auch andere Teile der Software mit dem EVSE interagieren.

Grüße,
Erik

[mattsches]

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

[rtrbt]

Damit ich das kurz eingeworfen habe: Wir haben letzte Woche die Struktur der Firmware vereinfacht. Du findest den aktuellen Kram jetzt nicht mehr im warp-charger-Git sondern hier: https://github.com/Tinkerforge/esp32-firmware

Das ist in Endeffekt der Inhalt der esp32-lib, und der software-Verzeichnisse von esp32-brick und warp-charger zusammengelegt. Im Idealfall kannst du deine Änderungen darauf übernehmen und alles funktioniert wie bisher weiter, nur mit weniger Verrenkungen, weil nicht mehr der Zustand von 3 Git-Repos auseinanderlaufen kann.

[mattsches]

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. 🙂