# Dev-Branch

**URL:** <https://forum.espuino.de/t/dev-branch/1835>\
**Category:** Software\
**Tags:** in-progress\
**Created:** [10. März 2023 um 22:45 UTC](https://forum.espuino.de/t/dev-branch/1835 "2023-03-10T22:45:15Z")\
**Posts on this page:** 20\
**Page:** 6

<div class="post-metadata">

**Author:** ![tueddy](https://forum.espuino.de/user_avatar/forum.espuino.de/tueddy/32/22_2.png) [@tueddy](https://forum.espuino.de/u/tueddy)\
**Post date:** [28. April 2023 um 21:40 UTC](https://forum.espuino.de/t/dev-branch/1835/101 "2023-04-28T21:40:51Z")

</div>

> [@Joe91](#):
>
> Was wäre wenn wir den aktuellen Dev-Branch richtung master bringen

Auf keinen Fall wenn hier noch Probleme bestehen & die sind ja bekannt. Und am Ende entscheidet das Papa, weil die Probleme fallen dann im Zweifel auf ihn zurüclk

> Bin aber auch dabei erstmal noch einen weiteren Branch dafür anzulegen.

Nicht im ESPuino-Reposity, wer soll zusätzlich einen DEV-DEV-Branch testen & warten? Bringt es voran & macht es rund, wir sind gespannt, berichtet gern hier.

Wünsche Euch ein schönes langes Wochenende mit Euren Kids & der Familie!

---

<div class="post-metadata">

**Author:** ![laszloh](https://forum.espuino.de/user_avatar/forum.espuino.de/laszloh/32/1975_2.png) [@laszloh](https://forum.espuino.de/u/laszloh)\
**Post date:** [29. April 2023 um 11:47 UTC](https://forum.espuino.de/t/dev-branch/1835/102 "2023-04-29T11:47:20Z")

</div>

Ich würde hier auch ein zweigleisiges Vorgehen vorschlagen:

1. Kurzfristige Lösung, damit das System läuft
2. Eine langfristige, die das Problem handhabbar macht und auch in Zukunft anwendbar ist

  

### zu Nr 1

Für jetzt ist der Gewinn von 200 Byte IRAM sicherlich eine Lösung, ich befürchte aber, dass das auf lange Sicht kein Stabiles vorgehen sein wird. Das bedeutet, dass wir bei dem nächsten Feature im IRAM (und sei es nur ein Interrupt-Handler) wieder am Start stehen.

Auch mit einer Branch eine aktiven Projekt (wie FastLED) ist es „meh“. Solche Branches sehe ich immer als problematisch an, da diese dann up-to-date gehalten werden müssen (was mit Aufwand verbunden ist und ich zumindest bin faul ☺).

> [@tueddy](#):
>
> Kann da bisher keine Nebenwirkungen wie Flackern feststellen. Das klappt auch für das evt. kommende Arduino 2.0.8. Warum macht man es sich nicht einfach einfach? Ich würde jetzt nicht gleich das ganze Build-System umstellen. Wer kann das noch testen, mit allen Features aktiviert?

Da musst du aufpassen, eine Interrupt Funktion im Flash hat [einige Anforderungen](https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/spi_flash/spi_flash_concurrency.html#iram-safe-interrupt-handlers) an das System, die erfüllt werden müssen. Interrupts nicht im IRAM werden zB deaktiviert, wenn die Caches deaktiviert sind (das zB bei einem Schreibzugriff auf dem Flash → NVS write zB der Fall ist).

Die Funktionen in FastLED füttern das RMT-Modul mit den Daten, die es auf den WS2812 Pin rausjagt. Wenn die Funktionen nicht im IRAM liegen, kann es aufgrund des Caches zu Verzögerungen kommen und der RMT leer laufen → flackern oder falsche Farben bei langen LED-Ketten.

Bei unserem System wahrscheinlich nur ein theoretisches Problem, ich habe aber zB schon Projekte mit knapp 300 LEDs / Strip aufgesetzt, da sieht man sowas mit dem freien Auge 🙂 .

  

### zu Nr 2

1A, ich habe die Branch mal ausgecheckt und werde es testen 🙂, sobeld das Build durch ist, werde ich berichten.

Eine Idee wäre es für den Start die [default config](https://github.com/espressif/arduino-esp32/blob/237a3fe96c451e5da88e8cfe9d850961f9bbe036/tools/sdk/esp32/sdkconfig) von Arduino als Absprungsbasis zu nehmen und da alle Änderungen einzupflegen.  
Damit haben wir dann nicht das Problem, dass unsere Version der IDF nicht laufen will.

---

<div class="post-metadata">

**Author:** ![Joe91](https://forum.espuino.de/letter_avatar_proxy/v4/letter/j/5fc32e/32.png) [@Joe91](https://forum.espuino.de/u/Joe91)\
**Post date:** [29. April 2023 um 11:51 UTC](https://forum.espuino.de/t/dev-branch/1835/103 "2023-04-29T11:51:25Z")

</div>

Bin da ganz bei dir 🙂  
**Hinweis:** Ich habe in dem Branch gerade noch eingebaut, dass die Target-Files automatisch gelöscht werden wenn Änderungen vorgenommen wurden. Dadurch muss man eigentlich auf nichts mehr achten und kann fröhlich an den Einstellungen in der sdkconfig.default drehen…

Ich meine @fschrempf hat genau diese Config verwendet um es zum Laufen zu bekommen und dann über die menuconfig diese nochmal neu geparsed. Kann ich aber nochmal überprüfen…

---

<div class="post-metadata">

**Author:** ![fschrempf](https://forum.espuino.de/user_avatar/forum.espuino.de/fschrempf/32/1740_2.png) [@fschrempf](https://forum.espuino.de/u/fschrempf)\
**Post date:** [29. April 2023 um 12:15 UTC](https://forum.espuino.de/t/dev-branch/1835/104 "2023-04-29T12:15:57Z")

</div>

> [@laszloh](#):
>
> Für jetzt ist der Gewinn von 200 Byte IRAM sicherlich eine Lösung, ich befürchte aber, dass das auf lange Sicht kein Stabiles vorgehen sein wird. Das bedeutet, dass wir bei dem nächsten Feature im IRAM (und sei es nur ein Interrupt-Handler) wieder am Start stehen.
> 
> Auch mit einer Branch eine aktiven Projekt (wie FastLED) ist es „meh“. Solche Branches sehe ich immer als problematisch an, da diese dann up-to-date gehalten werden müssen (was mit Aufwand verbunden ist und ich zumindest bin faul ☺).

Schön, dass da jemand meine Meinung teilt. Exakt diese Argumente habe ich oben bereits versucht zum Ausdruck zu bringen. 😄

> [@laszloh](#):
>
> Die Funktionen in FastLED füttern das RMT-Modul mit den Daten, die es auf den WS2812 Pin rausjagt. Wenn die Funktionen nicht im IRAM liegen, kann es aufgrund des Caches zu Verzögerungen kommen und der RMT leer laufen → flackern oder falsche Farben bei langen LED-Ketten.

Genau. Das deckt sich ebenfalls mit dem was ich oben geschrieben habe:

> [@fschrempf](#):
>
> Wo es eher ein Problem sein könnte ist wenn man irgendwelche Echtzeit-Anforderungen hat. Z. B. bei Schnittstellen wie SPI, etc. wo es zu hohen Latenzen kommen kann, wenn während der Übertragung ein Cache Miss auftritt und vom Flash geladen werden muss. Aber den Fall gibt es bei uns (außer vielleicht bei den LEDs) eher nicht.

> [@laszloh](#):
>
> Eine Idee wäre es für den Start die [default config](https://github.com/espressif/arduino-esp32/blob/237a3fe96c451e5da88e8cfe9d850961f9bbe036/tools/sdk/esp32/sdkconfig) von Arduino als Absprungsbasis zu nehmen und da alle Änderungen einzupflegen.  
> Damit haben wir dann nicht das Problem, dass unsere Version der IDF nicht laufen will.

Genau das habe ich gemacht. Daher sollte das Resultat (bis auf kleinere Unterschiede durch verschiedene ESP-IDF Versionen?) das selbe sein wie bisher.

---

<div class="post-metadata">

**Author:** ![tueddy](https://forum.espuino.de/user_avatar/forum.espuino.de/tueddy/32/22_2.png) [@tueddy](https://forum.espuino.de/u/tueddy)\
**Post date:** [29. April 2023 um 20:23 UTC](https://forum.espuino.de/t/dev-branch/1835/105 "2023-04-29T20:23:28Z")

</div>

Die besprochenen kurzfristigen Änderungen sind jetzt im DEV-Branch verfügbar.

- Wenn alle Features aktiviert ist dieser DEV-Branch wieder kompilierbar
- Bluetooth ist wie zuvor wieder standadmässig aktiviert
- Aktuelle Version ist jetzt Arduino 2.0.8, & Platform-Package 6.2.0

In der Platform.ini ist das angepasste FS rausgeflogen da jetzt in 2.0.8 offiziell enthalten.  
Die Biliotheken FastLED, RC522 & RC522-I2C (benutzt die ein Mensch auf diesem Planet?) sind zunächst geforkt mit Verweis auf die ursprüngliche Version. Wenn das überflüssig wird das dann entsprechend geändert/zurückgenommen.

---

<div class="post-metadata">

**Author:** ![tueddy](https://forum.espuino.de/user_avatar/forum.espuino.de/tueddy/32/22_2.png) [@tueddy](https://forum.espuino.de/u/tueddy)\
**Post date:** [1. Mai 2023 um 10:44 UTC](https://forum.espuino.de/t/dev-branch/1835/106 "2023-05-01T10:44:54Z")

</div>

Mir ist jetzt noch ein kleiner Bug aufgefallen:  
Der Code kompiliert nicht mehr wenn kein RFID-Reader definiert ist. Das könnte der Fall sein wenn man ohne Leser testet oder für Leute die das Programm als reinen Webplayer verwenden.

Zum Pausieren der Tasks beim Web-Upload werden jetzt die Methoden `Led_TaskPause()`/`Led_TaskResume()` und `Rfid_TaskPause()`/`Rfid_TaskResume()` anstelle direkter Zugriff auf die Task-Handles verwendet.

Wäre fein wenn noch jemand drüberschaut:

> <https://github.com/biologist79/ESPuino/pull/235>
>
> All non-essential tasks such as audio player, RFID and LED are paused to speed u…p the web upload.
> Until now, a global task handle was used for this. However, this no longer compiles if no RFID-reader is selected. This could be the case for testing or special applications such as a pure web player.
> This PR allows compiling even without an RFID reader and does not need global declarations. It also clear all LEDs instead of just freezing..

---

<div class="post-metadata">

**Author:** ![kkF](https://forum.espuino.de/user_avatar/forum.espuino.de/kkf/32/1845_2.png) [@kkF](https://forum.espuino.de/u/kkF)\
**Post date:** [2. Mai 2023 um 21:34 UTC](https://forum.espuino.de/t/dev-branch/1835/107 "2023-05-02T21:34:19Z")

</div>

Kann es sein, dass der dev-Branch nun nicht mehr mit dem Target ESP32-S3 kompiliert?  
Ich bekomme mindestens diese 3 Fehler (ENABLE\_BLUETOOTH natürlich auskommentiert):

```auto

.pio/libdeps/esp32-s3-devkitc-1/ESP32-A2DP/src/BluetoothA2DPSink.cpp:248:53: error: 'FUNC_GPIO0_CLK_OUT1' was not declared in this scope

.pio/libdeps/esp32-s3-devkitc-1/ESP32-A2DP/src/BluetoothA2DPSink.cpp:252:53: error: 'FUNC_U0TXD_CLK_OUT3' was not declared in this scope

.pio/libdeps/esp32-s3-devkitc-1/ESP32-A2DP/src/BluetoothA2DPSink.cpp:1255:33: error: 'I2S_MODE_DAC_BUILT_IN' was not declared in this scope

```

---

<div class="post-metadata">

**Author:** ![tueddy](https://forum.espuino.de/user_avatar/forum.espuino.de/tueddy/32/22_2.png) [@tueddy](https://forum.espuino.de/u/tueddy)\
**Post date:** [2. Mai 2023 um 21:51 UTC](https://forum.espuino.de/t/dev-branch/1835/108 "2023-05-02T21:51:58Z")

</div>

Hi @kkF , ja der ESP32-S3 hat kein ja lieder kein Classic-Bluetooth, also streamen auf den ESPuino bzw. BT-Kopfhörer ist mit diesem Chip eider nicht möglich. Trotzdem sollte es kompilieren.  
Ich kann das Profil `[env:esp32-s3-devkitc-1]` erfolgreich kompilieren, dazu muss die A2DP-Bibliothek zus. auskommentiert werden. Klappt es dann?

```auto
;	https://github.com/pschatzmann/ESP32-A2DP.git#5f87ad2

```

---

<div class="post-metadata">

**Author:** ![kkF](https://forum.espuino.de/user_avatar/forum.espuino.de/kkf/32/1845_2.png) [@kkF](https://forum.espuino.de/u/kkF)\
**Post date:** [2. Mai 2023 um 22:02 UTC](https://forum.espuino.de/t/dev-branch/1835/109 "2023-05-02T22:02:26Z")

</div>

Ah, vielen Dank. Dann klappt es tatsächlich.

---

<div class="post-metadata">

**Author:** ![tueddy](https://forum.espuino.de/user_avatar/forum.espuino.de/tueddy/32/22_2.png) [@tueddy](https://forum.espuino.de/u/tueddy)\
**Post date:** [6. Mai 2023 um 19:40 UTC](https://forum.espuino.de/t/dev-branch/1835/110 "2023-05-06T19:40:29Z")

</div>

Um mal einen DEV-Branch Zwischenstand zu geben, habe ich mal alles, was hier bereits fertig ist, so aufgeschrieben, als müsste ich es jemandem verkaufen. Dann wird aus jedem Bugfix ein Feature 😉 :

Verbesserungen:

- Verbesserte LED Animationen, z.B. weichere Übergänge bei Lautstärkeänderungen & Playlistfortschritt
- Beschleunigter Web-Upload, dafür werden u.a. LED, RFID und Audio Tasks pausiert
- Faktor \> 20 beschleunigte Playlist-Erstellung (keine/geringere Verzögerung beim Abspielen)
- Laden der Dateianzeige im Webinterface reagiert deutlich flüssiger
- Alle Audioformate aus der AudioI2S-Bibliothek werden jetzt unterstützt, auch aus der Web-Oberfläche (OPUS, M3U8 & weitere)
- Abspielen von M3U-Enhanced Playlists
- Eine Modifikationsbefehl kann direkt aus der Weboberfläche ausgeführt werden, z.B. Nachtmodus oder Bluetooth-Wechsel
- Unterstützung von zusätzlichen Neopixel-LEDs für Taster z.B. Nachtmodus & dimmen
- Web-Oberfläche: Eigenes Icon für Playlists
- Bluetooth-Modus kann durch Auflegen einer unbekannten Karte verlassen werden
- Neues Profil für den ESP32-S3

Fehlerkorrekturen:

- Beim Webupload fehlten teilweise einige Bytes oder wurden vertauscht → fehlerhafte Audiodateien
- Absturz beim Abspielen einer .mp3 Datei (Groß-/Kleinschreibung der Dateiendung ist jetzt egal)
- Fehlende Übersetzungen hinzugefügt
- [Bug in Verbindung mit dem LED Ring und Multibutton](https://forum.espuino.de/t/bug-in-verbindung-mit-dem-led-ring-und-multibutton/1825)

Code-Optimierungen:

- Umstellung auf das aktuelle Arduino Framework 2 (IDF 4.4)
- Speicheroptimierungen und Behebung von Speicherlecks für Langzeitbetrieb
- C++17 Compiler mit aktivierten Warnmeldungen
- Komplett überarbeiteter LED-Code
- Komplett überarbeitete Log-Ausgabe
- Überarbeiteter Code für Hallsensor (magenetische Hockey-Tags)
- Entfernung von PROGMEM &pgmspace
- Einheitlicher Codestyle

Abgekündigt:

- ESP-Muse wird nicht mehr unterstützt

Bekannte Probleme:

- Mit allen aktivierten Features sind wir nahezu am Ende des verfügbaren IRAM-Speichers.

Fehlt noch was?

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [6. Mai 2023 um 20:03 UTC](https://forum.espuino.de/t/dev-branch/1835/111 "2023-05-06T20:03:07Z")

</div>

Wow, danke @tueddy !  
Ich hatte gestern auf einem ganz frischen ESP32 (habe ich für eine Bestellung gelötet) ein Problem mit dem DEV-Branch. Ich war leider ziemlich in Eile und hab’s mir leider nicht in die Zwischenablage gelegt. Aber es gab sporadische Neustarts was irgendwie in diese Richtung ging: [Move to CRGBArray and CRGBSets · biologist79/ESPuino@cfdac70 · GitHub](https://github.com/biologist79/ESPuino/commit/cfdac7043aba7aebe70c09fcf5ab45e26b9b5829). Also irgendwelcher Neopixel-Kram.  
Ich schau mal, ob ich das nochmal nachgestellt kriege. Ins WLAN bin ich auch nicht gekommen, so dass ich dann final doch wieder den Master-Branch geflasht habe. Wobei das auch nicht weiter wild ist, weil das flashe ich bei Bestellungen immer drauf.

---

<div class="post-metadata">

**Author:** ![joker](https://forum.espuino.de/letter_avatar_proxy/v4/letter/j/5f9b8f/32.png) [@joker](https://forum.espuino.de/u/joker)\
**Post date:** [6. Mai 2023 um 20:09 UTC](https://forum.espuino.de/t/dev-branch/1835/112 "2023-05-06T20:09:18Z")

</div>

> [@tueddy](#):
>
> ehlt noch was?

Dieser behobene Bug oder habe ich das überlesen?

> [@Bug in Verbindung mit dem LED Ring und Multibutton](https://forum.espuino.de/t/bug-in-verbindung-mit-dem-led-ring-und-multibutton/1825):
>
> Hy, Folgendes Verhalten ist mir in Verbindung mit dem dynamischen Buttonlayout aufgefallen. Ich habe auf den Multibutton 23 (Play+Rotary) CMD\_TELL\_IP\_ADDRESS gelegt zusätzlich ist lange Rotary drücken immer noch Shutdown Wenn ich Play+Rotary drücke, dann kommt der rote Countdown zum Shutdown auf dem Neopixel. Ich denke, dieser sollte gar nicht angezeigt werden, da die gewünschte Funktion nicht Shutdown ist. Drückt man die Kombination kurz, erscheint der Countdown bis man die Tasten loslässt…

---

<div class="post-metadata">

**Author:** ![tueddy](https://forum.espuino.de/user_avatar/forum.espuino.de/tueddy/32/22_2.png) [@tueddy](https://forum.espuino.de/u/tueddy)\
**Post date:** [6. Mai 2023 um 20:33 UTC](https://forum.espuino.de/t/dev-branch/1835/113 "2023-05-06T20:33:40Z")

</div>

@joker Danke ist notiert!  
@biologist Wenn da etwas reproduzierbar ist dann her damit. Die Umstellung CRGBArray → CRGBSets ist ja recht neu, da können auch mal neue Fehler auftreten. Aber dafür ist der DEV-Branch ja da…

---

<div class="post-metadata">

**Author:** ![compactflash](https://forum.espuino.de/user_avatar/forum.espuino.de/compactflash/32/428_2.png) [@compactflash](https://forum.espuino.de/u/compactflash)\
**Post date:** [6. Mai 2023 um 21:29 UTC](https://forum.espuino.de/t/dev-branch/1835/114 "2023-05-06T21:29:06Z")

</div>

> [@biologist](#):
>
> Aber es gab sporadische Neustarts was

> [@biologist](#):
>
> Ins WLAN bin ich auch nicht gekommen

Beides habe ich auch festgestellt , kann es aber noch nicht gezielt nachstellen. Deshalb werde ich auch das nächste Update kommende Woche bei meiner Enkelin mit dem Master machen, obwohl ich gerne das

> [@tueddy](#):
>
> Faktor \> 20 beschleunigte Playlist-Erstellung

hätte.

---

<div class="post-metadata">

**Author:** ![tueddy](https://forum.espuino.de/user_avatar/forum.espuino.de/tueddy/32/22_2.png) [@tueddy](https://forum.espuino.de/u/tueddy)\
**Post date:** [7. Mai 2023 um 09:40 UTC](https://forum.espuino.de/t/dev-branch/1835/115 "2023-05-07T09:40:28Z")

</div>

> [@biologist](#):
>
> Ins WLAN bin ich auch nicht gekommen

Habe mal mit „Erase Flash“ Alles zurückgesetzt und dann die WLAN-Zugangsdaten neu eingegeben. Hat auf Anhieb geklappt.

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [7. Mai 2023 um 14:04 UTC](https://forum.espuino.de/t/dev-branch/1835/117 "2023-05-07T14:04:20Z")

</div>

> [@tueddy](#):
>
> Habe mal mit „Erase Flash“ Alles zurückgesetzt und dann die WLAN-Zugangsdaten neu eingegeben. Hat auf Anhieb geklappt.

Was halt strange ist: Der ESP32 war nagelneu. Also lediglich einmal mit DEV geflasht.  
Ich schaue mal, ob ich das nochmal nachstellen kann. Mit Arduino2 habe ich allerdings „traditionell“ schon immer mehr Probleme mit WLAN gehabt.

---

<div class="post-metadata">

**Author:** ![tueddy](https://forum.espuino.de/user_avatar/forum.espuino.de/tueddy/32/22_2.png) [@tueddy](https://forum.espuino.de/u/tueddy)\
**Post date:** [7. Mai 2023 um 20:28 UTC](https://forum.espuino.de/t/dev-branch/1835/118 "2023-05-07T20:28:50Z")

</div>

Im Bluetooth Lautsprechermodus hatte sich ein Fehler eingeschlichen der zum Crash führt.  
Bitte einmal drüberschauen oder besser- Testen. Wenn es grünes Licht gibt würde ich das zeitnah übernehmen:

> <https://github.com/biologist79/ESPuino/pull/236>
>
> Starting bluetooth audio in speaker mode (BT-sink) crashes, this is a regression… coming from refactoring the logging ;-(

---

<div class="post-metadata">

**Author:** ![Joe91](https://forum.espuino.de/letter_avatar_proxy/v4/letter/j/5fc32e/32.png) [@Joe91](https://forum.espuino.de/u/Joe91)\
**Post date:** [8. Mai 2023 um 15:12 UTC](https://forum.espuino.de/t/dev-branch/1835/119 "2023-05-08T15:12:56Z")

</div>

Durch die ganzen merge-commits ist das auf Github eher unübersichtlich.  
Habe dein Branch aber gerade in meinen Branch gemerged und damit kurz Bluetooth-Wiedergabe so wie das normale Abspielen und das hin und her wechseln zwischen BT und WLAN getestet.  
Da ich keine Bluetooth-Lautsprecher hier habe konnte ich diesen Modus nicht testen.  
Von den Diffs her passt es aber (ist ja wirklich sehr überschaubar)…

---

<div class="post-metadata">

**Author:** ![fschrempf](https://forum.espuino.de/user_avatar/forum.espuino.de/fschrempf/32/1740_2.png) [@fschrempf](https://forum.espuino.de/u/fschrempf)\
**Post date:** [8. Mai 2023 um 20:28 UTC](https://forum.espuino.de/t/dev-branch/1835/120 "2023-05-08T20:28:36Z")

</div>

> [@tueddy](#):
>
> Bitte einmal drüberschauen oder besser- Testen.

Ich hätte da noch einen alternativen Vorschlag (allerdings noch ungetestet): [Bluetooth.cpp: Fix logging crash in sink mode · fschrempf/ESPuino@0c6c64e · GitHub](https://github.com/fschrempf/ESPuino/commit/0c6c64e9bb19e8d10981bdce70c91fe4295d8da0).

---

<div class="post-metadata">

**Author:** ![laszloh](https://forum.espuino.de/user_avatar/forum.espuino.de/laszloh/32/1975_2.png) [@laszloh](https://forum.espuino.de/u/laszloh)\
**Post date:** [8. Mai 2023 um 21:07 UTC](https://forum.espuino.de/t/dev-branch/1835/121 "2023-05-08T21:07:04Z")

</div>

@fschrempf Oh, das ist nice. Commit funktioniert auf der aktuellen `dev`, kann aber nur die Sink-Seite esten. Sehe aber kein Grund, wieso Source sich anders verhalten sollte.

[Vorherige Seite](https://forum.espuino.de/t/dev-branch/1835.md?page=5)

[Nächste Seite](https://forum.espuino.de/t/dev-branch/1835.md?page=7)
