Habe das Update ESPHome 2025.7.1 installiert und nun lässt sich mein “Wasseruhr Empfänger” esp32 mit cc1101 nicht mehr compilieren.
Er steigt mit folgender Meldung aus:
Compiling .pioenvs/water1/FrameworkArduino/wiring_shift.c.o
Archiving .pioenvs/water1/libFrameworkArduino.a
Linking .pioenvs/water1/firmware.elf
RAM: [== ] 17.6% (used 57832 bytes from 327680 bytes)
Error: The program size (1973168 bytes) is greater than maximum allowed (1835008 bytes)
💡 TIP: Your ESP32 with Arduino framework has run out of flash space.
To fix this, switch to the ESP-IDF framework which is more memory efficient:
1. In your YAML configuration, modify the framework section:
esp32:
framework:
type: esp-idf
2. Clean build files and compile again
Note: ESP-IDF uses less flash space and provides better performance.
Some Arduino-specific libraries may need alternatives.
*** [checkprogsize] Explicit exit, status 1
Flash: [==========] 107.5% (used 1973168 bytes from 1835008 bytes)
== [FAILED] Took 731.33 seconds ==
Habe dann gemäss der Empfehlung das framework geändert, dass führt dann zu dem nächsten Fehler:
Compiling .pioenvs/water1/src/esphome/components/wmbus/translatebits.cpp.o
In file included from src/esphome/components/wmbus/rf_cc1101.h:9,
from src/esphome/components/wmbus/rf_cc1101.cpp:1:
src/esphome/components/wmbus/cc1101_rf_settings.h:3:10: fatal error: ELECHOUSE_CC1101_SRC_DRV.h: No such file or directory
****************************************************************************************
* Looking for ELECHOUSE_CC1101_SRC_DRV.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:ELECHOUSE_CC1101_SRC_DRV.h"
* Web > https://registry.platformio.org/search?q=header:%1B%5Bm%1B%5BKELECHOUSE_CC1101_SRC_DRV.h
*
****************************************************************************************
3 | #include <ELECHOUSE_CC1101_SRC_DRV.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Compiling .pioenvs/water1/src/esphome/components/wmbus/types.cpp.o
*** [.pioenvs/water1/src/esphome/components/wmbus/rf_cc1101.cpp.o] Error 1
== [FAILED] Took 595.58 seconds ===
Hat jmd. das gleiche Problem und vielleicht die Lösung?
Ja, ich hatte auf meinem ESP32 sinngemäß die gleiche Meldung von wegen “Zu wenig Speicherplatz”. Keine Ahnung ob bzw. was sich da innerhalb von ESPHome geändert hat…
Ich hab´s dann tatsächlich mit Google Gemini lösen können und konnte ein paar Sachen auskommentieren. Habe zum Beispiel das Fallback - WLAN und das Captive Portal rausgehauen, womit es schon gelangt hat.
Seit der Version ESPHome 2025.7.1 geht das Compilieren bei mir bei einem Gerät leider auch nicht mehr, allerdings mit der Fehlermeldung:
Compiling .pioenvs/kuechenstation/lib360/ESPAsyncTCP/SyncClient.cpp.o
src/main.cpp: In function 'void setup()':
src/main.cpp:390:99: error: no matching function for call to 'esphome::Automation<int, const char*, const char*>::Automation(esphome::logger::LoggerMessageTrigger*&)'
390 | automation_id_2 = new Automation<int, const char *, const char *>(logger_loggermessagetrigger_id);
| ^
In file included from src/esphome/components/sensor/filter.h:6,
from src/esphome/components/sensor/sensor.h:7,
from src/esphome/components/absolute_humidity/absolute_humidity.h:4,
from src/esphome.h:3,
from src/main.cpp:3:
src/esphome/core/automation.h:286:12: note: candidate: 'esphome::Automation<Ts>::Automation(esphome::Trigger<Ts ...>*) [with Ts = {int, const char*, const char*}]'
286 | explicit Automation(Trigger<Ts...> *trigger) : trigger_(trigger) { this->trigger_->set_automation_parent(this); }
| ^~~~~~~~~~
src/esphome/core/automation.h:286:39: note: no known conversion for argument 1 from 'esphome::logger::LoggerMessageTrigger*' to 'esphome::Trigger<int, const char*, const char*>*'
286 | explicit Automation(Trigger<Ts...> *trigger) : trigger_(trigger) { this->trigger_->set_automation_parent(this); }
| ~~~~~~~~~~~~~~~~^~~~~~~
src/esphome/core/automation.h:284:32: note: candidate: 'constexpr esphome::Automation<int, const char*, const char*>::Automation(const esphome::Automation<int, const char*, const char*>&)'
284 | template<typename... Ts> class Automation {
| ^~~~~~~~~~
src/esphome/core/automation.h:284:32: note: no known conversion for argument 1 from 'esphome::logger::LoggerMessageTrigger*' to 'const esphome::Automation<int, const char*, const char*>&'
src/esphome/core/automation.h:284:32: note: candidate: 'constexpr esphome::Automation<int, const char*, const char*>::Automation(esphome::Automation<int, const char*, const char*>&&)'
src/esphome/core/automation.h:284:32: note: no known conversion for argument 1 from 'esphome::logger::LoggerMessageTrigger*' to 'esphome::Automation<int, const char*, const char*>&&'
Bei allen älteren ESPHome Versionen gab es keine Probleme.
Werde mich jetzt mal ransetzen und durch Löschen von Code versuchen den fehlerhaften Bereich im Code zu finden…
Update 18.07.2025 19:30:
Sehr merkwürdig. Dieser kleine Codeabschnitt scheint den Fehler zu verursachen. Ohne ihn ist der Fehler weg.
logger:
on_message:
level: WARN
then:
- logger.log: 'Restart due to vl53l0x error!'
Hatte ich bis gerade auch…
Bei mir ist es ein simpler BT Proxy.
Ich glaube Ihr müsst eine Partitionstabelle anlegen und in YAML mit der Pfadangabe darauf verweisen:
Ich habe das Problem nicht und auch keine Idee, wo das Problem herkommt.
Vielleicht hilft es aber bei der Fehlersuche, wenn ihr euch den Freien Speicher mal anzeigen lasst und ev. vor dem Update und nach dem Update vergleicht.
Bei ESPHome finden scheinbar gerade einige tiefgreifende Änderungen statt, die einem mit aktuellen Projekten auf die Füße fallen können.
Z.B. lief mein ePaper Display nach einem Update nicht mehr.
Ich hatte dann ein Ticket auf GitHub aufgemacht, in dem dann herauskam, dass die CPU Frequenz bei Arduino-Plattform von ursprünglich 240 MHz auf 160 MHZ reduziert wurde. Nachdem ich die Frequenz wieder heraufgesetzt hatte, funktionierte es wieder.
Ja ESPHome springt grad auf ESP-IDF 5, sind jetzt bei 5.3.2 und wollen im August auf 5.4.2
Das kann unter Umständen auch mehr Platz benötigen.
Ich hatte auch Probleme mit einem meiner Displays da ist es der PSRAM, der mit 120Mhz dafür sorgt das das Display dann beim Reboot crasht. Aber nur dann, Strom kurz weg und starten lassen funktioniert. Habs jetzt auf 80Mhz laufen.
Ich trecke den Gaszähler mit einem Reedkontakt und bis Version 2025.6.3 hat es auch super funktioniert !
Seit Update auf 2025.7.0 oder auch höher bis 2025.7.2 geht nichts mehr.
Habe keine Fehlermeldung. Die Impulse werden nicht mehr weitergezählt obwohl angezeigt.
Dafür habe ich Nachkommastellen obwohl die Vorgaben bei mir 0 oder 2 Stellen sind werden die ignoriert und nicht gerundet.
Das ist zwar keine Hilfe:
Ja, die Update-Politik von ESPHome ist zu einer echten Seuche geworden!
Nach fast jedem Update funktioniert irgendwas nicht. Die Breaking-Changes Liste ist teils unmöglich lang.
Ich bin daher schon vor längerer Zeit dazu übergegangen, ESPHome-Updates nur noch in rd. 6-Monats-Zyklen einzuspielen.
Falls man nicht gerade neue Hardware- oder spezielle Features braucht, lohnen sich Updates quasi nie.
Wie oben schon mal erwähnt, scheinen einige Probleme durch die standardmäßige Reduzierung der Prozessorgeschwindigkeit auf 160 MHz begründet zu sein. Ich würde daher auf alle Fälle mal probieren, die Geschwindigkeit wieder auf 240 MHz hochzusetzen. Bei umfangreichen Projekten scheinen die 160 MHz nicht immer auszureichen, um alle Aufgaben zeitgerecht abzuarbeiten.
esp32:
board: esp-irgendwas
# Bei Arduion seit Version 2025.5.* 160MHz
cpu_frequency: 240MHz
Ansonsten würde ich einfach ein GitHub Ticket aufmachen. Die reagieren nach meiner Erfahrung recht schnell und kompetent.
Zur Info: Habe jetzt Update auf ESPHome 2025.10.2. Jetzt lässt sich die yaml für den Wasseruhr sensor wieder compilieren und auf dem esp32 laden. Scheinbar haben die Entwickler das Problem der zu grossen Datei gelöst. Seit gestern abend läuft die Wasseruhrkontrolle auf ESPHome 2025.10.2 soweit ohne Fehler.
