Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Absturz in der Startphase #5

Closed
ReinhardOelze opened this issue Apr 5, 2022 · 14 comments
Closed

Absturz in der Startphase #5

ReinhardOelze opened this issue Apr 5, 2022 · 14 comments

Comments

@ReinhardOelze
Copy link

Hallo Nico,
zunächst mal meine Anerkennung für die aufwändige Arbeit.
Ich habe versucht, das Projekt bei mir zum Laufen zu bringen und scheitere aktuell mit einem Absturz in der Boot-Phase des Systems (siehe Screenshot unten).
Nach deiner Anleitung habe ich alle erforderlichen Bibliotheken installiert und das Projekt übersetzt. Dabei ist aufgefallen, dass das Precompiler-Symbol MODBUSIP_PORT nicht mehr existiert, sondern jetzt MODBUSTCP_PORT zu verwenden ist. Weitere "breaking changes" habe ich bis zur Compilierfähigkeit nicht gefunden. Lediglich ein paar Compilerwarnungen mit "ISO C++ forbids converting a string constant to 'char*'" erscheinen. Installierte Hardware ist lediglich das 2,8" Display-Board und der ESP32 von AZ-Delivery. Eine Verbindung zum Wetter habe ich aktuell nicht eingetragen.

Das Programm startet durch bis zum Aufbau des grafischen Displays. Wifi-Connect ist OK, Connect zum E3DC ist OK und liefert korrekte Daten, das leere Bild mit der E3DC-ähnlichen Abbildung erscheint, dann kommt der Absturz mit dem Reboot. Hast du eine Idee?

Beste Grüße
Reinhard

2022-04-05 08_21_06-COM3

@nischram
Copy link
Owner

nischram commented Apr 5, 2022

Hallo Reinhard,

danke fürs Lob. Freut mich das du mein Projekt nutzen willst.
Eine ganz konkrete Idee für das Problem habe ich noch nicht. Aber irgendwie habe ich das Gefühl, dass die Wetter-Geschichte doch damit zu tun hat. Ich habe keine super Lösung dafür eingebaut die Wetterfunktion auszusetzen. Ich frage aus der parameter den Beispiel-Key ab, ob der noch dem Beispiel entspricht. So könnte die Wetteranzeige bei dem Display das Problem sein. Du könntest es mal testen indem du Folgende Zeile Auskommentierst.
Zeile 175 aus der EMD_1.ino
Vorher:

              tft.drawRGBBitmap(136, 251, percent,9,9);
            }
          #endif       
          overwriteLcdText(60, 304, 140, 8, ILI9341_DARKGREY, ILI9341_WHITE, FontMonospaced_bold_10,"%s %s", datum, zeit);
          drawWeatherSingleIcon();    
        }
       break; // case SCREEN_AKTUEL
      }
    case SCREEN_PV: {

Nachher:

              tft.drawRGBBitmap(136, 251, percent,9,9);
            }
          #endif       
          overwriteLcdText(60, 304, 140, 8, ILI9341_DARKGREY, ILI9341_WHITE, FontMonospaced_bold_10,"%s %s", datum, zeit);
          // drawWeatherSingleIcon();    
        }
       break; // case SCREEN_AKTUEL
      }
    case SCREEN_PV: {

Wenn das nicht hilft, könntest du vielleicht ein paar zusätzliche Ausgaben einbringen um besser zu sehen wo es abstürzt oder kurze Pausen um den Punkt besser anhalten und erkennen zu können.
Ausgaben:
Serial.println("Ausgabe 1");
Pausen für 1 Sekunde:
delay(1000);

Beispiel für Ausgabe (ab Zeile 124):

            readDHT();
          }
        #endif       
        if (millis() - printMillis > 1000 || printMillis == 0){ 
          printMillis = millis(); 
          #ifdef DEBUG
            overwriteLcdText(100, 269, 45, 11, ILI9341_DARKGREY, ILI9341_YELLOW, FontMonospaced_bold_13,"%5d",readRebootCounter());
            overwriteLcdText(100, 280, 45, 11, ILI9341_DARKGREY, ILI9341_YELLOW, FontMonospaced_bold_13,"%5d",mbDebugCounter);
          #endif   
          Serial.println("Ausgabe 1");
          overwriteLcdTextWorth(6, 93, 82, 12, ILI9341_DARKGREY, ILI9341_WHITE, FontMonospaced_bold_16,"W", "%6d",solarPower);
          Serial.println("Ausgabe 2");
          overwriteLcdTextWorth(148, 93, 82, 12, ILI9341_DARKGREY, ILI9341_WHITE, FontMonospaced_bold_16,"W", "%6d",gridPower);
          Serial.println("Ausgabe 3");
          overwriteLcdTextWorth(6, 284, 82, 12, ILI9341_DARKGREY, ILI9341_WHITE, FontMonospaced_bold_16,"W", "%6d",batPower);

Das sich Modbus geändert hat war mir noch gar nicht aufgefallen denn ich habe einige Zeit an dem Projekt nichts erweitert, werde es aber testen und ggf. ins nächste Update bringen.
Ich gehe aber nicht davon aus, dass es mit dem Problem zu tun hat denn die Abfrage von E3DC klappt ja, und du hast es richtig gesehen der Fehler scheint genau den aufzutreten wenn das Display diese Werte darstellen soll.
Auch die Warnungen sollten keinen Einfluss haben, aber auch hier könnte ich mal prüfen ob die bei mir auch kommen um sie ggf. zu beheben.

Vielleicht kannst du den Fehler näher eingrenzen und wir kommen wenn du dich wieder meldest dem Problem auf die Schliche...

Viel Erfolg!
Gruß Nico

@ReinhardOelze
Copy link
Author

Hallo Nico,
vielen Dank für deine schnelle Nachricht.
Inzwischen bin ich auch ein paar Schritte weitergekommen. Da die Arduino-IDE leider kein schrittweises Debugging zulässt, bleibt nur die "Hello-World-Methode" mit der seriellen Ausgabe.
Zunächst hatte ich die Aufrufe in Verdacht, die auch schon eine Compiler-Warnung hervorgerufen hatten.
Am Ende war es der Aufruf von "checkMB()", der den Absturz hervorgerufen hat.

[code]
        if ((millis() - lastMbMillis > IntervalModbus * 1000) || lastMbMillis == 0) {
          lastMbMillis = millis();
          mainMbRead();
          //checkMb();
        }
[/code]

Nach dem Auskommentieren läuft die Loop und die Anzeige ist erneuert sich korrekt.

Immer noch etwas merkwürdig ist der Umstand, dass die Anzeige bei der Netzleistung mitunter "astronomische" Werte anzeigt.
image
image

Ich hatte zunächst vermutet, dass es mit der Doppelregisterverwendung des E3DC-Modbus und deren Umwandlung in einen Vorzeichen-Integerwert zu tun haben könnte und habe in der Bibliothek (modbus.h) ab Zeile 206 mal was angepasst.

[code]
void mbCalcInt32(uint16_t *reg1, uint16_t *reg2, int *value){
  int positiv, negativ;
  int32_t uValue = 0;
	
  uValue = *reg2 << 16;
  uValue += *reg1;
  memcpy(value, &uValue, 4);
/*
	return;
	
//    if(*reg2 < 32768){
    if(*reg2 < 32767){
      //positiv = *reg2 * 65536 + *reg1;
      positiv = *reg2 * 65535 + *reg1;
      negativ = 0;
    } else {
      //negativ = 4294967296 - *reg2 * 65536 - *reg1; 
      negativ = 4294967295 - *reg2 * 65535 - *reg1; 
      positiv = 0;
    }
    *value = positiv - negativ;
    *reg1 = 0;
    *reg2 = 0;
	*/
}
[/code]

Subjektiv habe ich den Eindruck, das ist jetzt weniger, aber eben nicht weg. in 20 Zyklen kommt das wohl ein- bis zweimal vor. Offensichtlich ist da noch Potential für weitere Untersuchungen...

Beste Grüße
Reinhard

@nischram
Copy link
Owner

nischram commented Apr 7, 2022

Hallo Reinhard,

freut mich das du es eingrenzen konntest. Ja stimmt die "Hello World" Methode ist nicht schön, aber effektiv, nur leider recht zeitinzentiv weil die uploads zum teil doch einige Zeit dauern. Aber beim Programmieren lebt man halt oft vom "try and error".

Da in der Funkton "checkMB" in der "modbus.h" nicht so viel passiert, hätte ich eine Idee oder Vermutung. Es wird am Ende falls mehrere Fehler aufgetreten sind ein reboot eingeleitet. Meine Idee, viellicht hast du in der parameter.h den Wert für den Modbus-Reboot versehentlich auf 0 gesetzt.
Korrekt wäre ein Wert irgendwo zwischen 3 oder höher. Zeile 71:
#define MB_REBOOT 5
Aber so schlimm wäre es nicht wenn checkMB auskommentiert bleibt, nur würde dann bei Problemen mit Modbus das Display nicht neu gestartet.
Wobei ich gerade noch gesehen habe das die Funktion "checkMB" als int erstellt ist aber es gibt kein "return". So sollte die Funktion auf void geändert werden. Je nach Compiler läuft so etwas durch aber wer weiß vielleicht stürzt es zum Teil auch ab.

Die Probleme mit den unrealistischen Werten, kenne ich von meinem Display auch. Es wird wohl genau wie du vermutest hast, mit doppelten Registern zusammenhängen. Ich denke immer dann wenn es einen Wechsel der Werte von positiv nach negativ innerhalb der Registerabfragen kommt, erscheinen die hohen Werte. Da kommt mir die Idee, das ich bei mir mal beobachten muss ob die hohen Werte auch kommen wenn längere Zeit eine Überschuss oder Bezug ansteht. Bei dem Wetter heute, wird es aber wohl Bezug sein (und Sonne ist jetzt ehe weg). Denn dann gibt es keinen Wechsel im Vorzeichen. Aber aktuell regelt die Batterie immer bei +/- 0 rum.

Ich habe nicht noch eine Idee für eine Anpassung im Bereich der modbus.h die den Fehler ausblenden würde.
Aber jetzt wo ich das testen will, kommen bei mir beim kompilieren jede Menge Fehler. Ich musste meine ArdruinoIDE letztens neu installieren. Ich muss den Fehler mal erst suchen.
Hier meine Idee, vielleicht kannst du es ja schon mal testen:

void mbCalcInt32(uint16_t *reg1, uint16_t *reg2, int *value){
    int positiv, negativ;
    if(*reg2 < 32768){
      positiv = *reg2 * 65536 + *reg1;
      negativ = 0;
    } else {
      negativ = 4294967296 - *reg2 * 65536 - *reg1; 
      positiv = 0;
    }
    if (positiv - negativ > 65520 || positiv - negativ < -65520)
      *value = 0;
    else 
      *value = positiv - negativ;
    *reg1 = 0;
    *reg2 = 0;
}

Ich melde mich wieder wenn ich es bei mir wieder am laufen habe und noch was gefunden habe.

Viele Grüße Nico

PS: wenn mein aktueller Fehler weg ist sind die Warnungen bestimmt auch alle behoben, denn die spuckt er mir auch auch aber läuft dann nicht weiter.

@ReinhardOelze
Copy link
Author

ReinhardOelze commented Apr 8, 2022

Hallo Nico,
danke für die Tipps. Auch ich bin wieder einen Schritt weiter gekommen.
Die Ausreißer hängen offensichtlich damit zusammen, dass die Einzelregister jeweils mit einem Delay vom E3DC abgeholt werden. Zwischen den einzelnen Zugriffen kann sich der Wert dort schon verändert haben, so dass die beiden Registerwerte nicht mehr zusammenpassen.

Ich habe mal testweise das Auslesen des "gridPower"-Wertes zusammengelegt. Die Probleme sind nun weg.
Die mb.readHreg-Funktion ist mit Default-Parametern ausgestattet, die man bei der Anwendung überschreiben kann. Ich habe dabei dann die zwei Register mit einem Zugriff ausgelesen.
Hier kommt mal der Code aus modbus.h angewendet zunächst nur auf benanntes Register.


ModbusIP mb;  //ModbusIP
IPAddress mbIP_E3DC;
int mbDelay = 45;

union DoubleRegister
{
    int32_t  dr;    // occupies 4 bytes
    uint16_t sr[2]; // occupies 4 bytes
}; 

DoubleRegister registerBuffer;
uint16_t magicbyte = 0;
uint16_t solarPowerReg1        = 0;
uint16_t solarPowerReg2        = 0;


In der Anwendung sieht das dann so aus:


void mainTaskMbRead(){
    if(INTERVALL_MODBUS >= 10 ) {
      mb.connect(mbIP_E3DC);
      delay(mbDelay);
    }
    mb.readHreg(mbIP_E3DC, REG_MAGIC -1, &magicbyte);delay(mbDelay);
    mb.task();
    mb.readHreg(mbIP_E3DC, REG_SOLAR +REG_OFFSET, &solarPowerReg1);delay(mbDelay);
    mb.task();
    mb.readHreg(mbIP_E3DC, REG_SOLAR +REG_OFFSET +1, &solarPowerReg2);delay(mbDelay);
    mb.task();
    /*
    mb.readHreg(mbIP_E3DC, REG_GRID +REG_OFFSET, &gridPowerReg1);delay(mbDelay);
    mb.task();
    mb.readHreg(mbIP_E3DC, REG_GRID +REG_OFFSET +1, &gridPowerReg2);delay(mbDelay);
    mb.task();
    */
    mb.readHreg(mbIP_E3DC, REG_GRID +REG_OFFSET, &registerBuffer.sr[0], 2);delay(mbDelay);
    mb.task();
    gridPowerReg1 = registerBuffer.sr[0];
    gridPowerReg2 = registerBuffer.sr[1];
    mb.readHreg(mbIP_E3DC, REG_BAT +REG_OFFSET, &batPowerReg1);delay(mbDelay);
    mb.task();


Damit das ganze dann in Ordnung kommt, müsste das Konzept von modbus.h wohl dahingehend nochmal überarbeitet werden.

Viele Grüße
Reinhard

@nischram
Copy link
Owner

nischram commented Apr 8, 2022

Hallo Reinhard,

wie schön das Projekte hier im Github auch immer wieder von Ideen anderer leben. Dein Ansatz ist sehr gut und mit Sicherheit der Grund für das Problem. Ich habe es gleich getestet und auch ohne meine Anpassung von gestern ist jetzt kein falscher Wert mehr gekommen. Somit baue ich dein Vorschlag natürlich sofort, in die Software ein und werde eine neue Version hochladen.
Wie gut das ich gestern noch mein Problem lösen konnte. Das Problem mit den Warnungen werde ich aber doch wohl nicht weg bekommen denn di sind alle in der "OpenWeatherOneCall" Bibliothek, selbst wenn ich es behebe Hilfe es hier im Projekt nicht.
Trotzdem musste ich ein "return 1" in der "OpenWeatherOneCall.cpp" einbauen, denn sonst ist mein Compiler nicht durchgelaufen. Die Funktion "parseWeather()" ist als "int" erstellt aber hat kein return.

Ich mache mich mal an die Arbeit und baue deine Idee ein...
Danke für die guten Informationen und die Zusammenarbeit.
Viele Grüße Nico

nischram added a commit that referenced this issue Apr 8, 2022
- Issue #5 Doppelregister werden jetzt ohne delay abgefragt
- Kleine Anpassungen um Warnungen beim kompilieren zu vermeiden
 Fehlerbehebung in der Darstellung im Homescreen nach dem Screensaver
nischram added a commit that referenced this issue Apr 8, 2022
…266" anders benannt

- Issue #5 "MODBUSIP_PORT" geändert in "MODBUSTCP_PORT"
@nischram
Copy link
Owner

nischram commented Apr 8, 2022

Hallo,
so das wars schon. Habe deine Idee für alle Doppelregister umgesetzt. >> V1.02
Vielleicht kannst du meine Anpassungen mal testen.

Nach deiner Anleitung habe ich alle erforderlichen Bibliotheken installiert und das Projekt übersetzt. Dabei ist aufgefallen, dass das Precompiler-Symbol MODBUSIP_PORT nicht mehr existiert, sondern jetzt MODBUSTCP_PORT zu verwenden ist.

Dieses Problem konnte ich erst nicht nachstellen. Ich hatte nicht sofort gemerkt dass nach dem Update nicht sofort die richtige Bibliothek verwendet wurde.

Mehrere Bibliotheken wurden für "ModbusIP_ESP8266.h" gefunden
 Benutzt: /Users/nico/Documents/Entwicklung/Arduino/libraries/modbus-esp8266-3.0.3
 Nicht benutzt: /Users/nico/Documents/Entwicklung/Arduino/libraries/modbus-esp8266

So musste ich die Version V1.03 noch nachschieben.

Zudem habe ich noch ein paar Anpassungen, bezüglich Fehler die mir jetzt mit neuer Version der ArduinoIDE aufgefallen sind, eingebaut.
Im Display gab es unten nach dem der Bildschirmschoner beendet war, fehlerhafte Einblendungen.

Viele Grüße Nico

@ReinhardOelze
Copy link
Author

Hallo Nico,
ich bin ja beeindruckt, du bist ja echt schnell.
So habe ich dann auch gleich die letzte Version heruntergeladen und es ausprobiert.
Leider ist jetzt bei mir was mit dem Display nicht mehr in Ordnung.

image

Übers Wochenende komme ich nicht dazu, das mal näher zu untersuchen. Ich habe erstmal die vorherige Version wieder eingespielt.

Viele Grüße
Reinhard

@nischram
Copy link
Owner

Hey Reinhard,

ich hab es am Wochenende auch nicht geschafft. Das Problem hatte ich bei mir nicht sofort, aber zwischendurch kam der Fehler auch. Somit konnte ich es schon eingrenzen.
Der registerBuffer.sr[0] wird wohl nicht jedes mal gefüllt oder besser es bleiben Reste enthalten. Ich habe jetzt mal auf die Schnelle vor jeder Abfrage eingebaut, dass die Variablen wieder auf "0" gesetzt werden. Dann geht es, es kommen keine Fehlerhaften anzeigen mehr.

Etwa so habe ich es gemacht:

    mb.readHreg(mbIP_E3DC, REG_MAGIC -1, &magicbyte);delay(mbDelay);
    mb.task();
    registerBuffer.sr[0] = 0;
    registerBuffer.sr[1] = 0;
    mb.readHreg(mbIP_E3DC, REG_SOLAR +REG_OFFSET, &registerBuffer.sr[0], 2);delay(mbDelay);
    mb.task();
    solarPowerReg1 = registerBuffer.sr[0];
    solarPowerReg2 = registerBuffer.sr[1];
    registerBuffer.sr[0] = 0;
    registerBuffer.sr[1] = 0;
    mb.readHreg(mbIP_E3DC, REG_GRID +REG_OFFSET, &registerBuffer.sr[0], 2);delay(mbDelay);
    mb.task();
    gridPowerReg1 = registerBuffer.sr[0];
    gridPowerReg2 = registerBuffer.sr[1];

Ich finde die Lösung nur noch nicht so schön, ich muss mal prüfen ob ich es irgendwie in eine Funktion baue, damit es nicht so oft drin ist.
Oder hast du eine Gute Idee, denn deine Vorschläge haben mir gezeigt, dass du auch Fit bist im Programmieren?

Viele Grüße Nico

nischram added a commit that referenced this issue Apr 12, 2022
- Issue #5 Doppelregister nochmal umgebaut
- Softwareversion umgezogen von parameter.h (parameter.temp.h) nach EMD_1.ino
- Fehler für Warnung in der update.h behoben
@nischram
Copy link
Owner

Hey,

habe jetzt einiges in V1.04 und der modbus.h umgebaut. Ich habe dein Prinzip mit "DoppelRegister" genutzt für alle Variablen die doppelt gebraucht werden. Jetzt fülle ich die Register direkt und nicht erst "registerBuffer.sr[0]" und so muss ich den nicht vorab leeren. Trotzdem hatte ich vorher schon ein leeren der Variablen in der Funktion "mbCalcInt32()" die ich jetzt auch auf die neuen "DoppelVariablen" umgebaut habe.

Wenn du trotzdem eine Idee hast wie es schöner oder besser geht, bin ich für alles offen und lerne gerne dazu. 😉

Viele Grüße

@ReinhardOelze
Copy link
Author

Hi Nico,
danke für die Blumen. In der Tat verdiene ich meinen Lebensunterhalt mit Software-Entwicklung. Allerdings sind meine C++-Erfahrungen etwas eingerostet. Seit ca. 15 Jahren arbeite ich mit C# und Visual Studio.

Ich habe deine Änderungen heruntergeladen und getestet. Alles läuft bei mir so weit so gut. Einen Vorschlag hätte ich noch:

void mainMbRead(){
    Serial.println("_______________________________________ ");
    serialPrintClock();
    mainTaskMbRead();
    #ifdef DEBUG
      Serial.printf("Reboot Counter   : %5d\n",readRebootCounter());
      Serial.printf("Debug  Counter   : %5d\n",mbDebugCounter);
    #endif
    mbCalcInt32(solarPowerReg, &solarPower);
    gridPower = gridPowerReg.dr;
    //mbCalcInt32(gridPowerReg, &gridPower);
    mbCalcInt32(batPowerReg, &batPower);
    mbCalcInt32(homePowerReg, &homePower);
    mbCalcInt16(&batSocReg, &batSoc);
    mbCalcAutarkieEigenv(&autarkieReg, &autarkie, &eigenverbrauch);

Die DoubleRegister Struktur enthält bereits eine typgerechte Speicherüberlagerung. Ich habe das hier mal wieder für den Wert von gridPower beispielhaft eingetragen. gridPower = gridPowerReg.dr kann direkt zugewiesen werden und der Funktionsaufruf von mbCalcInt32 wird damit unnötig. Auf meinem ESP32 funktioniert das. Eine anschließende 0-Zuweisung auf die Registervariable war bei mir nicht erforderlich.

Viele Grüße
Reinhard

nischram added a commit that referenced this issue Apr 13, 2022
- Issue #5 Vorschlag für die Nutzung der DoubleRegister übernommen
- Anpassung im ModbusTimeout, dieser hat zu lange gedauert
@nischram
Copy link
Owner

Hallo Reinhard!

Cool, so einfach kann Programmierung sein 😉! Zuvor hatte ich das Prinzip mit der Struktur von "DoubleRegister" noch nicht ganz verstanden. Aber ich glaube jetzt kann ich folgen.
Zumindest hat es geklappt, ich habe alle Variablen umgebaut und es läuft.
Zusätzlich habe ich Gersten noch festgestellt, dass die Applikation ewig versucht Modbus neu zu verbinden, wenn die IP zum Speicher mal nicht klappt. So habe ich die Funktion und das Timeout etwas umgebaut.

Danke für deine Guten Tipps und deine Mithilfe!

Viele Grüße Nico

@ReinhardOelze
Copy link
Author

Hi Nico,
... gerne, wenn es so gut klappt, macht es Spaß.
Vielleicht noch ein kleiner Nachtrag:
Ich hatte bei der Batterieleistung nach dem Start immer noch gelegentlich mal die Situation, dass die Anzeige des Wertes kaputt war. Erklären kann ich mir das nur schwer, da ich doch annehmen würde, dass die Register durch den E3DC bei jeder Anfrage vollständig gefüllt werden.
Ich habe daher im modbus.h mal die Doppelregisterwerte ebenfalls mit 0 initialisiert, wie du es mit allen anderen Werten ja schon während der Deklaration machst. Danach habe ich das Problem bislang nicht mehr beobachtet.

void initModbus(const char * ipAdress){
  solarPowerReg.dr = 0;
  gridPowerReg.dr = 0;
  batPowerReg.dr = 0;
  homePowerReg.dr = 0;
  extPowerReg.dr = 0;
  wbAllPowerReg.dr = 0;
  wbSolarPowerReg.dr = 0;
  
  mbIP_E3DC.fromString(ipAdress);
  Serial.print("Modbus Init      :  wait...");
  if(INTERVALL_MODBUS > INTERVALL_HM) IntervalModbus = INTERVALL_HM;
  else IntervalModbus = INTERVALL_MODBUS;

Viele Grüße
Reinhard

nischram added a commit that referenced this issue Apr 15, 2022
- Issue #5 Nachtrag für die Initialisierung der DoubleRegister übernommen
@nischram
Copy link
Owner

Hey,

stimmt es macht Spaß, wenn die Zusammenarbeit klappt. Ich freu mich immer wenn ich dazu lernen kann 😉.

Dieses mal hat es nur ein wenig gedauert, mein Mac hat von Mi auf Do ein Update gemacht und danach wollte die ArduinoIDE nicht mehr, es kam immer die Fehlermeldung exec: "python": executable file not found in $PATH. Ich musste als Abhilfe in der ~/Library/Arduino15/packages/esp32/hardware/esp32/1.0.6/platform.txt jeweils "python" gegen "python3" tauschen.

Dein Problem konnte ich noch nicht beobachten, wenn aber dein Nachtrag die Abhilfe ist sieht man es ja auch nur wenn der ESP startet. Da es kein Nachteil sein kann habe ich es übernommen.

Danke noch mal und schöne Ostertage (wenn nicht an Ostern noch neue Ideen komme 😊).
VG Nico

@ReinhardOelze
Copy link
Author

Schöne Ostertage für dich und deine Familie.
VG Reinhard

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants