ESPHome: Reinstallation aber wie?

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.

Thomas Braun

@klassisch sagte in ESPHome: Reinstallation aber wie?:

Und da kann ich leider gar nicht mehr helfen.

Dann verzapf aber auch nicht so'n Blödsinn wie da oben mit den 'angstvollen Updates'.
Ja, die header files wie die hier vermissten

esp_arduino_version.h: No such file or directory
esp32-hal-touch.h: No such file or directory

müssen passen. Das ist aber auch unter Windows erforderlich.
Für mich deutet das alles auf eine 'strubbelige Installation' der IDE hin.

Dieter_P

@thomas-braun @klassisch

was soll ich dazu tippen? Ich eier jetzt schon hier zu sehen seit 1 Monat daran rum. Mich kekst sowohl die nachhaltig angeditschte Installation auf dem RPI die sich mit BackitUp nun unwiederruflich weiter pflanzt mächtig an, dann aber auch die Situation wie & warum, aber am Ende um pragmatisch zu bleiben brauche ich ESPHome mit der Funktion wodurch ich auch in Kauf genommen hab so ein Betakram zu installieren und warum soll ich jetzt mit der Schilderung meiner wahrgenommen Faktenlage das Risiko auf mich nehmen die letzten 2 die mir Ansätze zum Umgang geben nachhaltig zu verärgern?
Ich sag mal so, Ihr könnt da sicher am wenigsten zu. Die Schwarz/Weiß Betrachtung bzgl. Updates und auf diesen ESPHome-Fall bezogen ist mir jedenfalls so zu einseitig und einfach dargestellt.

Lieber heute als morgen würde ich das rauswerfen und hätte es auch schon getan wenn Alternativen mit Doku und mir helfendem Support möglich wäre. Ich sehe meine RPI Installation immer noch als in der Doku zu findenden Standard. Die Migration über BackitUp von Buster auf Bullseye begründet wiederum durch ein Update auf influxdb2 (64-Bit) funktioniert für mich aktuell so nicht und das ist mein Problem. Wer ein Problem hat versucht es zu lösen. Annahmen und Anschuldigungen in dieser Richtung ziehe ich mir dann nur noch begrenzt an und würde mich lieber darüber freuen bei der Lösung etwas zu lernen und das auch der Community als Lösung zu hinterlassen.

Wal

@dieter_p ,
nach welcher Anleitung installierst du PlatformIO, würde mich mal interessieren.
Habe mal eine Anleitung zum Tasmocompiler gemacht und da wurde platformio im root Verzeichnis vom Installer-Skript installiert.

Edit: kommt drauf an wo das Skript ausgeführt wird, eben gelesen.
Wollte aber wissen ob du die drei Links wie in der Anleitung erzeugt hast oder die automatisch erzeugt wurden.

Dieter_P

@wal

Besten Dank!

Als ich ESPHome das erste mal installiert habe (schon ein paar Tage her) ging das nach einer Anleitung hier aus dem Forum. 100% kann ich das aber nicht mehr nachvollziehen. Danach mehrfach durch Backitup Neuinstallationen durchgeführt und ich brauchte dank Restore keinen manuellen Schritte mehr durchführen da alles funktionierte.

Das änderte sich nun bei Migration von Buster auf Bullseye auf dem RPI.

Auf meinem 2ten System (Debian) brauchte ich nie etwas manuell zu installieren und alleine die Installation von ESPHome über git funktionierte und das bis heute auch über Neuinstallation/Backitup Restore hinweg.

Da auch in der Doku (Requirements) nichts für mich zu zusätzlichen manuellen Installationen vermerkt ist, ist da überhaupt etwas zu tun?

Ganz dunkel glaube ich mich noch an eine manuelle Installation von python zu erinnern aber Platform IO habe ich nie manuell installiert.

Auf Platform IO bin ich über die Meldungen im Log des Kompiliervorgangs aufmerksam geworden.

Sehr gut möglich das dort Ordner Referenzen nicht mehr stimmen und dazu wäre es doch ratsam den alten Kram löschen zu können und ESPHome inkl. Platform IO neu zu installieren. Das mir aber selbst zusammen zu googeln über diverse Ergebnisse erzeugt ziemlich sicher ein Ergebnis was ThomasBraun beschrieben hat. Versuche mich aber gerne und bin für Stichpunkte um den "richtigen Weg" zu finden sehr dankbar

Wal

@dieter_p ,
platformio wird durch die ESPHome Git Installation mit installiert.
Da es dort aber kein Issues für RPI OS 64 gibt, denke ich das die Installation auch Ordnungsgemäß funktioniert.
Ich weiß das hilft dir jetzt auch nicht weiter, aber mangels ESPEasy Erfahrung kann ich jetzt auch nicht helfen.

Dieter_P

@wal

Danke.

Wieso ESPEasy? Hätte ich herzlich gerne genutzt aber ESPEasy unterstützt noch keine Bluetooth Funktionen.

klassisch

@Dieter_P keine Angst, Du verärgerst uns nicht.

Ich kann halt nur sagen, wie ich mich durchs "Leben schlage" und wozu mich meine Erfahrungen und mein Prgmatismus geführt haben. Das ist aber nicht allgemeingültig und muß nicht immer so gelten. Es kann sich mal alles verbessern und plötzlich fehlerarm funktionieren.
Der liebe Thomas, den ich wirklich sehr schätze, hat eben eine andere Erfahrungswelt, in der er prima lebt. Und wir streiten uns nicht wirklich.

Ich kann sogar noch einen Schritt weitergehen: Bevor ich ein Projekt mit ESPHome realisiere, schaue ich, ob es auch mit ESPEasy geht. Oder mit einem Tasmota Fertig-Bin - also ohne Compilieren. Denn auch dazu müßte ich wieder eine Umgebung installieren.
Mir geht es halt vorwiegend um das Ziel und weniger um den Weg dorthin. Und dabei gilt für mich "Minimalist" "Keep it simple and stupid"

Dieter_P

@klassisch
bestens. nach dann breche ich jetzt mal in Richtung Zielumgebung auf und versuch mal ob ich da den neuen "Fremdkörper" aus nem anderen ESPHome reinbekomme.

Wäre schon mal ein erster Erfolg. Dann noch den nicht-funktionalen ESPHome teil aus dem BackitUp Backup zu elimieren wäre natürlich ein Traum.

NEWS

ESPHome: Reinstallation aber wie?

Support us

699

32.4k

81.4k

1.3m