ESPHome: Reinstallation aber wie?

Homoran

@dieter_p sagte in ESPHome: Reinstallation aber wie?:

Mir geht es um den Adapter in der Version 0.2.4 da er keine volle Funktion mehr hat

Da ich den Adapter und ESPs nicht gut genug kenne, weiß ich nicht, ob der Adapter alleine werkelt, oder auf ein extern3s Programm zugreift.

Dieter_P

@homoran said in ESPHome: Reinstallation aber wie?:

@dieter_p sagte in ESPHome: Reinstallation aber wie?:

Mir geht es um den Adapter in der Version 0.2.4 da er keine volle Funktion mehr hat

Da ich den Adapter und ESPs nicht gut genug kenne, weiß ich nicht, ob der Adapter alleine werkelt, oder auf ein extern3s Programm zugreift.

Thx, da bin ich überfragt was da alles ineinandergreift
Lt. Doku/Angaben ist Python in entsprechender Version notwenig, was in v3.9.2 der Fall ist. NodeJS >12 ist auch installiert.

Edit: Jetzt nochmal die Instanz gelöscht, dann den Adapter deinstalliert und das Verzeichnis /opt/iobroker-data/esphome.0/ gelöscht.
Danach den Adapter und Instanz wieder installiert aber gleiches Ergebnis.
Jegliche Kompilierung jeglicher Platformen schlägt mir den oben beispielhaft gezeigten Verweisen zu fehlenden Headern fehl.

Dieter_P

Leider komme ich so aktuell nicht weiter. Also ist die einzige Alternative die mir einfällt eine möglichst saubere Neuinstallation hinzu bekommen aber ohne sonstige Daten außerhalb von ESPHome zu verlieren.

Etwas skeptisch bin ich da das jetzige System eine Neuinstallation von Raspi OS Bullseye (Upgrade auf 64Bit) ist wo ich nur mittels Backitup ein Restore eingespielt habe und "Kleinigkeiten" wie die MariadB und influxdb manuell installiert habe, was man halt so macht bei einem Restore. Das Ergebnis ist die fehlerhafte Umgebung für ESPHome trotz passender Python Installation lt. Doku.

Wie sollte ich nun eine Neuinstallation ohne Restore von ESPHome durchführen oder macht das keinen Sinn, da eh das Gleiche wie aktuell vorliegt dabei rauskommt?

Thx

Dieter_P

Auch wenn ich hier Monologe halte, vielleicht ergibt sich dennoch ein Tip.

Ich habe wie gesagt 2 Umgebungen und 1 (die Live Umgebung) funktioniert nicht bzgl. Kompilierung.

Unterschied die Live-Umgebung läuft auf einem RPI4 mit Raspi OS Bullseye und die funktionieren Umgebung auf Debian.

Nach intensiver Suche bin ich darüber gestolpert, dass der Author wohl nur auf Debian getestet/entwickelt hat und angemerkt wurde, dass pip auf Raspi OS fehlen würde. Habe dies bei mir geprüft und pip fehlte. Installiert und ESPHome nochmal neu installiert, aber immer noch keine Kompilierung möglich.

Gibt es dazu Erkenntnisse? In der Doku ist weder zu RaspiOS noch zu pip etwas vermerkt.....

Aktuelle Logs:

INFO Reading configuration /opt/iobroker/iobroker-data/esphome.0/esphome-web-9fb8e8.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing esphome-web-9fb8e8 (board: m5stack-core-esp32; framework: arduino; platform: platformio/espressif32 @ 5.2.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
Dependency Graph
|-- AsyncTCP-esphome @ 1.2.2
|-- WiFi @ 2.0.0
|-- FS @ 2.0.0
|-- Update @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 2.1.0
|   |-- AsyncTCP-esphome @ 1.2.2
|-- DNSServer @ 2.0.0
|-- ESPmDNS @ 2.0.0
|-- noise-c @ 0.1.4
|   |-- libsodium @ 1.10018.1
|-- FastLED @ 3.3.2
Compiling .pioenvs/esphome-web-9fb8e8/libbf3/FastLED/FastLED.cpp.o
Compiling .pioenvs/esphome-web-9fb8e8/libbf3/FastLED/bitswap.cpp.o
Compiling .pioenvs/esphome-web-9fb8e8/libbf3/FastLED/colorpalettes.cpp.o
In file included from .piolibdeps/esphome-web-9fb8e8/FastLED/led_sysdefs.h:48,
                 from .piolibdeps/esphome-web-9fb8e8/FastLED/FastLED.h:41,
                 from .piolibdeps/esphome-web-9fb8e8/FastLED/FastLED.cpp:2:
/home/iobroker/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:32:10: fatal error: esp_arduino_version.h: No such file or directory

*****************************************************************************
* Looking for esp_arduino_version.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:esp_arduino_version.h"
* Web  > https://registry.platformio.org/search?q=header:esp_arduino_version.h
*
*****************************************************************************

 #include "esp_arduino_version.h"
          ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
*** [.pioenvs/esphome-web-9fb8e8/libbf3/FastLED/FastLED.cpp.o] Error 1
Compiling .pioenvs/esphome-web-9fb8e8/libbf3/FastLED/colorutils.cpp.o
In file included from .piolibdeps/esphome-web-9fb8e8/FastLED/led_sysdefs.h:48,
                 from .piolibdeps/esphome-web-9fb8e8/FastLED/FastLED.h:41,
                 from .piolibdeps/esphome-web-9fb8e8/FastLED/bitswap.cpp:2:
/home/iobroker/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:32:10: fatal error: esp_arduino_version.h: No such file or directory

*****************************************************************************
* Looking for esp_arduino_version.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:esp_arduino_version.h"
* Web  > https://registry.platformio.org/search?q=header:esp_arduino_version.h
*
*****************************************************************************

 #include "esp_arduino_version.h"
          ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
*** [.pioenvs/esphome-web-9fb8e8/libbf3/FastLED/bitswap.cpp.o] Error 1
In file included from .piolibdeps/esphome-web-9fb8e8/FastLED/led_sysdefs.h:48,
                 from .piolibdeps/esphome-web-9fb8e8/FastLED/FastLED.h:41,
                 from .piolibdeps/esphome-web-9fb8e8/FastLED/colorpalettes.cpp:4:
/home/iobroker/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:32:10: fatal error: esp_arduino_version.h: No such file or directory

*****************************************************************************
* Looking for esp_arduino_version.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:esp_arduino_version.h"
* Web  > https://registry.platformio.org/search?q=header:esp_arduino_version.h
*
*****************************************************************************

 #include "esp_arduino_version.h"
          ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
*** [.pioenvs/esphome-web-9fb8e8/libbf3/FastLED/colorpalettes.cpp.o] Error 1
In file included from .piolibdeps/esphome-web-9fb8e8/FastLED/led_sysdefs.h:48,
                 from .piolibdeps/esphome-web-9fb8e8/FastLED/FastLED.h:41,
                 from .piolibdeps/esphome-web-9fb8e8/FastLED/colorutils.cpp:7:
/home/iobroker/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:32:10: fatal error: esp_arduino_version.h: No such file or directory

*****************************************************************************
* Looking for esp_arduino_version.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:esp_arduino_version.h"
* Web  > https://registry.platformio.org/search?q=header:esp_arduino_version.h
*
*****************************************************************************

 #include "esp_arduino_version.h"
          ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
*** [.pioenvs/esphome-web-9fb8e8/libbf3/FastLED/colorutils.cpp.o] Error 1
========================== [FAILED] Took 5.33 seconds ==========================

Thomas Braun

@dieter_p sagte in ESPHome: Reinstallation aber wie?:

Passt das build environment?
Debian (und damit auch Raspberry OS) ist eigentlich für python eine 1a Plattform. Viele python-Pakete gibt es schon vorkompiliert. So auch natürlich pip. Nennt sich
python3-pip

apt policy python3-pip

sagt bei dir?

Dieter_P

@thomas-braun said in ESPHome: Reinstallation aber wie?:

@dieter_p sagte in ESPHome: Reinstallation aber wie?:
apt policy python3-pip
sagt bei dir?

pi@iobroker:~ $ apt policy python3-pip
python3-pip:
  Installiert:           20.3.4-4+rpt1+deb11u1
  Installationskandidat: 20.3.4-4+rpt1+deb11u1
  Versionstabelle:
 *** 20.3.4-4+rpt1+deb11u1 500
        500 http://archive.raspberrypi.org/debian bullseye/main arm64 Packages
        500 http://archive.raspberrypi.org/debian bullseye/main armhf Packages
        100 /var/lib/dpkg/status
     20.3.4-4+deb11u1 500
        500 http://deb.debian.org/debian bullseye/main arm64 Packages
        500 http://deb.debian.org/debian bullseye/main armhf Packages

bzgl. Environment liegt da auch meine Vermutung nach DEM Hinweis.

kenne aber nur:
Prerequisites:

* NodeJS >= 12.x
* Python >=3.7, <4.0
* API is activated in YAML
* For admin tabs (optional)
    * ESPHome Dashboard IP is provided in instance settings

pi@iobroker:~ $ node -v
v16.19.1
pi@iobroker:~ $ python --version
Python 3.9.2

Danke für Deine Unterstützung!

Dieter_P

@thomas-braun

durch weitere Suche in den Issues auf Github bin ich nun auf diesen Beitrag gestoßen:

https://forum.iobroker.net/topic/54265/esphome-error-process-exited-with-code-25/115

Mein BackiTUp Backup kommt von einem RPI4 32-Bit Buster und nun wurde ein neues 64-Bit Bullseye installiert und mit BackitUp das Restore eingespielt.

Seitdem habe ich die Fehler bemerkt und Ähnlichkeiten zum Beitrag kann ich weniger erkennen, da es dort meistens schon um die Installation geht. Diese funktioniert ja.

Pip fehlte zwar aber ist nun vorhanden und dennoch keine Funktion.

Überall wird eine Neuinstallation (64-Bit) als Lösung beschrieben, aber verspricht das Erfolg, wo mein Problem im Prinzip sofort nach der Neuinstallation auftrat?

Wenn ich einfach Gleiches mach, kommt üblicherweise Gleiches auch wieder raus. Was kann ich tun?

Dieter_P

Spaß macht es leider nicht, da die Fragen sich nicht klären.

Habe nun meinen quasie letzte Option gespielt und neue/andere Hardware mit Debian 11 64-Bit aufgesetzt und dort mittels BackitUp ein Restore von dem 64-Bit RPI eingespielt wo ESPHome nur Fehler wirft beim Kompilieren.

Ergebnis: Auch unter Debian mit dem frischen System und Restore funktioniert es nicht.

Dieses System wieder platt gemacht und auf einem frischen IObroker ESPHome installiert und den yaml File zum kompilieren gegeben.
Das funktioniert ohne jegliche Probleme.

Somit ist meine Umgebung (derzeit auf RPI) nicht in Ordnung aber schlimmer, das Problem wird definitiv mit BackitUp mitgesichert und übertragen.
Soweit ich weiß kopiert Backitup auch diverse Ordner und spielt sie bei einem Restore zurück. Welche genau und was ich tun kann???

Wie bekomme ich ein Restore der Daten aber so als ob ESPHome nie in Berührung mit dem System war?

klassisch

Bei meiner letzten Neuinstallation von ioBroker - allerdings unter Windows - hat sich der Adapter nicht mehr bauen lassen.
Irgendwelche dependencies.
Als Windows Nutzer hatte ich ohnehin nie das Dashboard und compiliere meine ESPHome yaml - schon bevor es den Adapter gab - unter Windows.
Das hat auch das letzte Mal noch funktioniert. Habe dann alle meine ESPs mit MQTT-Schnittstelle neu übersetzt und per OTA geflasht.
War eine rel. schnelle Aktion und läuft. Nicht elegant, aber pragmatisch.

Dieter_P

@klassisch

Auch wenn mich das vom Prinzip total kekst an so etwas hab ich da auch schon gedacht. Ich habe eine funktionierende Installation wo ich drauf kompilieren kann. Problem, dass ich dann den ESP32 ca. 70km durch die Gegend kutsche um dann zu merken, das ich irgendwo was vermurkst hab.

Ich muß ja zumindest die Wifi credentials der Zielumgebung dort hart im yaml File hinterlegen und kann nicht über:

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

gehen da es unterschiedliche Wifis sind. Aber wie läuft das mit dem encrytion key kann ich den portieren?

Oder Alternativ muß ich mir eine portable virtuelle Maschine bauen die ich dann zum kompilieren vor Ort nutzen kann, grrr alles ein Workaround und keine schöne Lösung

klassisch

@dieter_p Ich nutze include files. Da sind die credentials hinterlegt. Die werden im yaml etwa so referenziert:

<<: !include includes-MQTT.yaml

In diesem File stehen die credentials, früher auch der api-Zugang und heute eben der MQTT-Zugang und noch so ein paar andere gemeinsame Sachen wie web-port, nup server und der fallback Hotspot AP

# Standards and Secrets for ESPHome
wifi:
  ssid: "targetWiFi"
  password: "extremelysecret:-)"
  domain: .
# domain . may be not correct, but works with firtzbox
# the domain is to support mDNS for flashing and logging
#  domain: .fritz.box
# .fritz.box worked for me, the default .local did not   
  

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
   ssid: "ESPHomeFallback"
   password: "randomstuff"

# Example configuration entry
web_server:
  port: 80

  # Example configuration entry
time:
  - platform: sntp
    id: sntp_time
    servers: "191.178.1.1"
    timezone: DE
#      display time
#      it.strftime(0, 0, id(font), "%Y-%m-%d %H:%M", id(time).now());  


# api for use with MQTT and/or ioBroker
#api:
#    password: 'topsecret:-)'

# Attention: When logged Incorrect Password: enter PWD do not stre but terminate instance and start again https://forum.iobroker.net/post/621511

    # Example configuration entry
mqtt:
  broker: 192.168.178.99

Vielleicht kannst Du im anderem WiFi mit dem Fallback Hotspot-AP die dortigen WiFi credentials eingeben?

Falls nicht, einfach 2 dieser include files machen.
Und dann entweder im yaml das passende include referenzieren, testen und zur Vorbereitung für das remote WiFi mit dem anderen include file übersetzen.
Entweder durch ändern der Referenz im yaml oder durch umkopieren der include files. Quodlibet

Dieter_P

@klassisch

Vielen Dank! Da ich es nicht weiß, die include Files legst du dort ab (gleicher Ordner) wo auch die yaml Files per Standart gespeichert sind?

klassisch

@dieter_p ja, die liegen neben den yamls. Ist nicht sehr elegant. Wäre schöner in einem anderen Ordner. So ging es aber auf Anhieb und dann blieb es eben so....

Dieter_P

@klassisch danke muss da Mal etwas mit probieren

Dieter_P

@klassisch
Thx. hab jetzt eine virtuelle Maschine (Debian) fertig auf der ich kompilieren kann. Ob ich danach das Erfolgreich in eine andere ESPHome Umgebung eingebunden bekomme, muß ich nochmal vor Ort an der Zielumgebung testen.

Jetzt hier mit 2 Iobrokern aktiv den ESP in beiden zu verwenden klappt nicht so 100% aber das kann auch eigenes Chaos sein.

Was mir nochmal aufgefallen ist, auf der neuen virtuellen Umgebung hat er mich aufgefordert Platform IO zu aktualisieren. Das hab ich jetzt nicht gemacht um mir nix zu zertstören. Auf der anderen Umgebung schlugen aber alle Platform IO Befehle fehl die sich auf ein Update etc bezogen. Da im Log der Kompilierung Platform IO 5.2 angezeigt wurde habe ich eine Installation/Upgrade versucht hiernach aber das hilft auch nicht wirklich und von Platform IO 6.1 weit und breit nicht zu sehen.

klassisch

@dieter_p Hilft Dir jetzt leider nichts: Aus solchen Gründen schaffe ich mit funktionierenden Versionen, bis ich zum Update gezwungen werde. Man schimpft gerne über Win Updates. Aber die gehen fast immer und wenn nicht, dann liest man das überall udn wartet ein paar Wochen. Was ich als Laie da aber in der Linux Welt, Python, nodeJs etc erlebe, ist eine andere Nummer. "Die Angst updatet mit". Wie beim Bohren in die Wand eines alten Hauses mit unbekannter Leitungsverlegung: "Die Angst bohrt mit".
Hauptsache Du hast eine Maschine, auf der Du die Dinger flashen kannst, notfalls über USB. Dann Datenausgabe über MQTT und nicht mehr über api. So hatte zumindest ich den wenigsten Ärger und die größte Erfolgswahrscheinlichkeit.

Thomas Braun

@klassisch sagte in ESPHome: Reinstallation aber wie?:

"Die Angst updatet mit"

Quatsch. Schau dir mal an wie konservativ Patches z. B. bei Debian in deren Repositories aufschlagen. Die durchlaufen erstmal zwei Vorinstanzen, bevor die auf die Allgemeinheit losgelassen werden. Und auch dann wird da eigentlich nie eine neue Version hochgedrückt, sondern lediglich die notwendigen Änderungen in Form eines 'backports' in die ursprüngliche Version reingewebt.

Genauer nachzulesen z. B. hier:
https://www.michlfranken.de/debian-editionen-vergleich/

Man schimpft gerne über Win Updates. Aber die gehen fast immer und wenn nicht, dann liest man das überall udn wartet ein paar Wochen.

Und wo ist jetzt der Unterschied? ChangeLogs werden bei freier Software i.d.R. viel besser und öffentlicher dokumentiert. Und 'gehen ebenfalls immer'. Jedenfalls gewiss nicht weniger häufig als Updates unter anderen Systemen.
Wenn etwas 'nicht geht' dann steht das auch 'überall zu lesen'. Gut, nicht im Kleinkleckersdorfer Tagblatt oder der Bild, aber auf den größeren Linux/IT-Seiten steht das auch.

Wobei jetzt ESPHome noch nichtmal was mit dem Betriebssystem direkt zu tun hat.

klassisch

@thomas-braun schön, daß Du Dich meldest. Kenne und schütze Dich ja als kompetenten und hilfreichen Spezialisten. Vielleicht kannst Du @Dieter_P helfen, wenn er seine logfiles der "klemmenden" Maschine postet?
Ich kannes leider nicht, weil ich mich bei diesen Sachen immer nur bis zum "jetztz funktionierts hinreichend" durchwurstle, ohne die Feinheiten dieser Pakete durchdrungen zu haben.

Thomas Braun

@klassisch sagte in ESPHome: Reinstallation aber wie?:

Vielleicht kannst Du @Dieter_P helfen, wenn er seine logfiles der "klemmenden" Maschine postet?

Keine Ahnung. Mit ESP hab ich halt noch nie was am Hut gehabt.
Nur letzte Woche mal ein Board für opendtu umgeflasht, da aber die vorkompilierten Binairy Files genommen. Ging jedenfalls einwandfrei, nachdem ich das 'esptool' ganz easy aus den Debian-Quellen gefischt hatte.
Über platformio wäre das auch irgendwie gegangen, hatte aber keinen Bock da das ganze Environment zum Kompilieren hochzuzimmern.

Wenn halt 'irgendwas' 'irgendwie' von 'irgendwoher' installiert wird (wie es gerne aus Gewohnheit von Win-Usern gemacht wird), dann muss es auch nicht wundern, wenn so ein 'Frankensteinlinux' kaputt geht.

klassisch

@thomas-braun Bei mir läuft es ja, oder lief zumindest bei der letzten Benutzung unter Win. @Dieter_P hatte halt bei einer Debian Maschine Erfolg und bei der anderen Fehlermeldungen. Und da kann ich leider gar nicht mehr helfen.
ESPtool läuft auch unter Win, wenn man mal die richtige Python-Version erwischt und richtig verpfadet hat. Das nutze ich schon seit es die ESP8266 gibt. Hatte damals die Teile noch selbst programmiert in C. Sicher nicht vorbildlich, aber jahrelang rebootfrei lauffähig -solange WLAN da ist.
Heutzutage sind die "Fertiglösungen" wie ESPEasy, Tasmota (habe ich schon lange nicht mehr genutzt) oder "Bausteinlösungen" wie ESPHome bequemer und wahrscheinlich auch besser.

NEWS

ESPHome: Reinstallation aber wie?

Support us

1.5k
Online

30.9k
Users

77.6k
Topics

1.2m
Posts

NEWS

ESPHome: Reinstallation aber wie?

Support us

1.5kOnline

30.9kUsers

77.6kTopics

1.2mPosts

1.5k
Online

30.9k
Users

77.6k
Topics

1.2m
Posts