ESP8266 instable si plusieurs police sont chargé

Bonjour a tous,

Je suis en train d’essayé de me faire un affichage sur un écran a encre électronique via ESPHome.
Juste que la pas de problème, mon ecran n’est pas reconnu nativement, mais il support est présent sur un PR donc j’arrive a afficher ce que je veux dessus.

Mon problème arrive lorsque j’essaie de charger plusieurs tailles différente sur la police « Roboto ».

En effet, si je decommande la font roboto_20, je me retrouve a avoir un comportement totallement eratique de mon ESP8266 (perte de connexion wifi, plus de refresh de l’ecran, etc…)

J’ai essayé de retiré tout ce qui était possible de mon ESP (capteurs, recupération de valeur depuis HA, etc…) au cas ou c’était un problème de surcharge, mais cela ne change rien.
D’ailleur, je n’ai pas besoin d’utilisé le roboto_20 pour que cela produise le problème.

Voici avez une idée ?
Merci par avance pour votre aide.

PS: ma config complete

esphome:
  name: esp-home-test
  friendly_name: esp_home_test

external_components:
 - source: github://pr#6226
   components: [waveshare_epaper]

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "**"

ota:
  - platform: esphome
    password: "**"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esp-Home-Test Fallback Hotspot"
    password: "**"

captive_portal:
    
color:
  - id: red
    hex: "FF0000"
  - id: black
    hex: "FFFFFF"
  - id: white
    hex: "000000"

font:
  - file: "gfonts://Roboto"
    id: roboto_10
    size: 10
    glyphsets: GF_Latin_Core
    ignore_missing_glyphs: True
 #- file: "gfonts://Roboto"
 #  id: roboto_20
 #   size: 20
 #  glyphsets: GF_Latin_Core
 #  ignore_missing_glyphs: True

spi:
  mosi_pin: GPIO04  # aka SDA # D2
  clk_pin: GPIO05  #aka SCL # D1

display:
  - platform: waveshare_epaper
    id: eink_display
    model: 2.90in3c
    cs_pin: GPIO15 # D8
    dc_pin: GPIO13 # D7
    reset_pin: GPIO12 # D6 
    busy_pin: GPIO14 # D5
    rotation: 270
    reset_duration: 2ms
    update_interval: 60s
    lambda: |-

      // --- Températures ---
      it.print(1, 1, id(roboto_10), "Haut");
      it.printf(10, 10, id(roboto_10), "%.1f°C", 20.5);
      #it.printf(10, 10, id(roboto_20), "%.1f°C", 20.5);

      it.filled_rectangle(80, 5, 5, 35, id(red));

      it.print(102, 1, id(roboto_10), "Bas");
      it.printf(112, 10, id(roboto_10), "%.1f°C", 22.2);

      it.filled_rectangle(175, 5, 5, 35, id(red));

      it.print(200, 1, id(roboto_10), "Bas");
      it.printf(210, 10, id(roboto_10), "%.1f°C", 12.6);

      // --- Séparateur ---
      it.filled_rectangle(5, 35, 285, 5, id(red));

     

Salut,

Perso j’ai plusieurs fonts (dont roboto20) sur plusieurs ESP et ça fonctionne sans souci

La seule différence notable, c’est que je prends un nombre plus restreint de glyphs (gain en mémoire):

        glyphs:"éêèëùïö#€œº"

Option A : réduire la mémoire utilisée :ballot_box_with_check:

Voici quelques astuces si tu veux rester sur ESP8266 :

  1. Réduire le nombre de tailles de police
  • Une seule taille est la plus sûre.
  • Utilise par exemple Roboto 12 ou Roboto 14 au lieu de 10 + 20.
  1. Remplacer gfonts:// par des polices bitmap précompilées

Tu peux les générer toi-même avec lv_font_conv ou utiliser une police bitmap plus légère comme :

font:
  - file: "fonts/bitmap_font.bdf"
    id: roboto_14
    size: 14
  1. Réduire la fréquence de mise à jour de l’écran
  • Tu as : update_interval: 60s
  • Essaie update_interval: 180s ou plus long, pour limiter les usages RAM/CPU.
  1. Éviter les rectangles trop complexes ou grands affichage ePaper lent et coûteux sur ESP8266

Option B : migrer vers un ESP32 :white_check_mark: