ESP8266 - TASMOTA Probleme

[M. K. (Gast)]

Moin,
mit tasmotizer die tasmota-de.bin auf einen NodeMCU gespielt.
WLAN eingetragen, IP abgerufen und über Browser auf den ESP gegangen.
Super, geht ganz kurz, dann ist der nicht mehr erreichbar.
10 mal Power Reset, aber da geht nix mehr.

Der ESP verliert absolut zuverlässig immer und immer wieder seine 
Config.
Ich kann mich dann hin und wieder tatsächlich mit dem ersatzweise 
aufgespannten tasmota-xxxx Wlan verbinden und die AP Einstellungen 
komplett neu machen, was dann wieder für sehr kurze Zeit funzt bis der 
wieder alles vergessen hat.

Was mache ich falsch, hat das schon mal jemand gehabt und was tue ich 
dagegen?

Ist das eigentlich normal das die Tasmota FW nicht auf Pings (Angry IP) 
reagiert?
Ist ätzend das immer immer die Router Seite rausfinden zu müssen, ob 
überhaupt und wenn ja mit welcher ip sich der ESP verbunden hat.

[Klaus R. (klara)]

M. K. schrieb:
> Ich kann mich dann hin und wieder tatsächlich mit dem ersatzweise
> aufgespannten tasmota-xxxx Wlan verbinden und die AP Einstellungen
> komplett neu machen, was dann wieder für sehr kurze Zeit funzt bis der
> wieder alles vergessen hat.

Ich denke die Config wird überschrieben.
mfg Klaus

[Oliver S. (phetty)]

Stromversorgung etwas schwach?
Ansonsten auch auf der seriellen Schnittstelle beobachten was passiert.

[Chris K. (kathe)]

Wie Oliver schon gesagt hat Stromversorgung zu schwach.
Wird wohl Power Recovery sein.
https://tasmota.github.io/docs/Device-Recovery/

[M. K. (Gast)]

Chris K. schrieb:
> Wie Oliver schon gesagt hat Stromversorgung zu schwach.
> Wird wohl Power Recovery sein.

Und dann verliert der seine permanent gespeicherten WLAN settings?
Hängt auch derzeit am Laptop bzw. Powerbank, also ist da nix schwach.

Ich habe jetzt mal bei dem Tasmotizer Setup über COM Port das Modul 
gleich auf Generic geändert, statt das später im Webinterface zu 
versuchen.
K.A. was das default Modul ist, aber da scheint ihm was nicht zu 
schmecken.
Scheint jetzt stabil zu laufen.

[M. K. (Gast)]

Ach nö ...
Es lief nun 1Std ganz gut und ich war bei den MQTT Settings.
Nun wieder alles jungfräulich frisch und der ESP hat keine Ahnung das er 
jemals konfiguriert worden ist.

Selbst WENN es ein Power Problem wäre, was ich nicht glaube da er am 
Laptop hängt und der Com Port nicht einmal abgemeldet wurde, kann der 
dösel doch nicht jede Konfiguration verlieren, nur weil es mal auf der 
Power gezuckt hat.

Der resettet anscheinend unmotiviert regelmäßig.
Reset cause ist 2 (Reset pin), aber da ist definitiv nix.
Scheint eher nach ein paar Minuten ohne aktion zu geschehen.
Für mich sieht das aus als ob die FW selbst sich das Gehirn löscht und 
neu beginnt.

Erkennt hier jemand was aus dem Mitschnitt auf der Seriellen?
(Das geht unendlich so weiter, also nur ein kurzer Mitschnitt)

00:00:06 QPC: Reset<\r>
<\n>
00:01:02 RSL: stat/tasmota_E83CAC/RESULT = {"POWER":"ON"}<\r>
<\n>
00:01:02 RSL: stat/tasmota_E83CAC/POWER = ON<\r>
<\n>
00:01:03 APP: Restarting<\r>
<\n>
<\r>
<\n>
 ets Jan  8 2013,rst cause:2, boot mode:(3,0)<\r>
<\n>
<\r>
<\n>
load 0x4010f000, len 3584, room 16 <\r>
<\n>
tail 0<\r>
<\n>
chksum 0xb0<\r>
<\n>
csum 0xb0<\r>
<\n>
v2843a5ac<\r>
<\n>
~ld<\n>00:00:00 CFG: Loaded from flash at F5, Count 23<\r>
<\n>
00:00:00 QPC: Count 1<\r>
<\n>
00:00:00 Project tasmota Tasmota Version 8.5.1(tasmota)-2_7_4_1<\r>
<\n>
00:00:00 WIF: WifiManager active for 3 minutes<\r>
<\n>
00:00:00 HTP: Web server active on tasmota_E83CAC-7340 with IP address 192.168.4.1<\r>
<\n>
00:00:06 QPC: Reset<\r>
<\n>
00:03:02 APP: Restarting<\r>
<\n>
<\r>
<\n>
 ets Jan  8 2013,rst cause:2, boot mode:(3,0)<\r>
<\n>
<\r>
<\n>
load 0x4010f000, len 3584, room 16 <\r>
<\n>
tail 0<\r>
<\n>
chksum 0xb0<\r>
<\n>
csum 0xb0<\r>
<\n>
v2843a5ac<\r>
<\n>
~ld<\n>00:00:00 CFG: Loaded from flash at F4, Count 24<\r>
<\n>
00:00:00 QPC: Count 1<\r>
<\n>
00:00:00 Project tasmota Tasmota Version 8.5.1(tasmota)-2_7_4_1<\r>
<\n>
00:00:00 WIF: WifiManager active for 3 minutes<\r>
<\n>
00:00:00 HTP: Web server active on tasmota_E83CAC-7340 with IP address 192.168.4.1<\r>
<\n>
00:00:06 QPC: Reset<\r>
<\n>
00:04:12 APP: Restarting

[M. K. (Gast)]

Megafuck!
https://tasmota.github.io/docs/Device-Recovery/

FW ist der Meinung das es keine gültige Config hat, weil es den MQTT 
Broker nicht erreichen kann. (da bastel ich noch dran)
Daher löscht es in seiner unendlichen Weisheit gleich einfach sämtliche 
Konfiguration. Sein Modulprofil, die IOs, WLAN + Passwort.
Selbstzerstörung in 3 ... 2 ... 1 PENG

Daher auch der endlos Loop mit regelmässigen resets.

Ja das macht Sinn und richig Freude!

[Stefan F. (Gast)]

Flash Speicher reagieren empfindlich auf instabile Stromversorgung. Dann 
können sogar Lesezugriffe zerstörend wirken.

Das der Laptop als Netzteil dient, bedeutet nicht viel. Denn dazwischen 
hast du noch zwei Steckverbinder und ein Kabel, an denen es liegen kann.

Überprüfe die Versorgungsspannung mit einem Oszilloskop, dann hast du 
Gewissheit.

[Chris K. (kathe)]

Sollte es wirklich die Power sein einfach mal folgendes aus er oben 
verlinkte Doku durchführen
Fast Power Cycle Device Recovery

Implemented for situations where a device cannot be reset to firmware 
defaults by other means (no serial access, no button). It resets ALL 
Tasmota settings (equal to Reset 1) after 7 power cycles.

SetOption65 must be set to 0 (default) in order for this feature to be 
enabled.

Warning

If you have a weak power grid or frequent power brownouts its best to 
disable this feature with SetOption65 1 immediately or you'll end up 
with firmware default devices after a brownout event.

Sollte man nicht Funktionen erst aktivieren wenn die Vorraussetzungen 
gegeben sind?

[M. K. (Gast)]

Der ESP nimmt die Config an, verbindet sich mit dem WLAN, wirft mir eine 
schöne Meldung raus wie toll er sich doch mit meinem AP versteht und 
dann 37sek später:
15:22:29 RSL: stat/tasmota_E83CAC/RESULT = {"Reset":"Reset and 
Restarting"}<\r><\n>
15:22:29 CFG: Use defaults<\r><\n>
15:22:30 APP: Restarting<\r><\n>

An der Uhrzeit sehe ich, das es noch der Zustand vor Reset ist, denn 
danach hat er 00:00
Die FW ENTSCHEIDET sich dafür zu resetten und die defaults zu benutzen.
Nur warum er das tut kann ich nicht nachvollziehen.

Der Tasmotizer stürzt auch gerne ab, beim Versuch die FW neu zu 
beschreiben.
Config Setup mit -1 byte geschrieben, hört sich auch nicht gerade gut 
an.
Oft genug versuchen, dann gehts auch mal.
Fehlermeldungen und Errorcodes werden auch toootal überbewertet.
Der User wird das schon irgendwann mal herausfinden warum ihm das Ding 
ständig zwischen die Beine grätscht.

Aber okay, Oszi hab ich grad nicht hier, weil unterwegs.
Der ESP verhält sich auch mit jeder Minute merkwürdiger.
Zuhause liegt der nächste und dem werde ich mal einen fetten Elko 
spendieren bevor ich mich wieder in dieses Drama stürze.

Chris K. schrieb:
> Sollte man nicht Funktionen erst aktivieren wenn die Vorraussetzungen
> gegeben sind?
HAHAHAHAHA, ich schmeiss mich wech ...
Ich bin totaler Neuling mit Tasmota, MQTT und Konsorten und habe einfach 
nur genau das getan was in den Tuts beschrieben wird.
tasmota.bin draufbügeln und los.
Wo sollen den diese Optionen sein, wenn man sich keine eigene FW 
compiliert, sondern erstmal mit etwas Narrensicheren anfangen will, weil 
man das gerade NICHT kaputtkonfigurieren will?

Also scheint die einzige zuverlässige Methode zu sein alles hardcoded im 
eigenen compilat zu hinterlegen, weil das dämliche Ding dann ganz 
einfach nichts mehr kaputt verschlimmbessern kann.

Gehts ein paar mal nicht wie geplant, werfe alles weg was man dir 
beigebracht hat und gehe auf eine standardconfig zurück die auf jeden 
Fall NICHT funktionieren wird. Wie kommt man auf solche Ideen?

Das hört sich doch mal nach einer grundsoliden Lösung für ein smarthome 
an 😂🤣😂🤢

[Stefan F. (Gast)]

M. K. schrieb:
> Also scheint die einzige zuverlässige Methode zu sein alles hardcoded im
> eigenen compilat zu hinterlegen,

Wenn die Stromversorgung instabil ist, verliert der Flash Speicher wie 
gesagt manchmal Daten. Also ist das auch keine Lösung.

Finde lieber die Ursache und behebe das Problem dort.

[Heinz R. (heijz)]

Als Alternative evtl. das hier:

https://github.com/letscontrolit/ESPEasy/releases

Damit kannst zumindest mal ausschließen das der ESP defekt oder das 
Netzteil zu schwach ist...

[M. K. (Gast)]

Stefan ⛄ F. schrieb:
> Wenn die Stromversorgung instabil ist, verliert der Flash Speicher wie
> gesagt manchmal Daten.

Nur das sie das bei mir nicht manchmal tut, sondern es kaum 5min läuft 
und das nun schon >20mal passiert ist innerhalb eines Tages.
Wäre das ein Verlust durch Lesevorgänge + Power fail, müsste auch das 
sonstige Flash korrumpiert werden.

Lesevorgänge der Konfiguration werden wohl kaum permanent während des 
Betriebes stattfinden und mitten während des Laufs zur einem geplanten 
und über das Logging dokumentierten Neustart führen, nachdem dann alles 
wieder auf Standard steht.

Ich bin wie gesagt blutiger Anfänger bei ESP und Tasmota.
Deswegen wollte ich ja eine Lösung mit der man auch als DAU zu 
Ergebnissen kommt.

Das einzige Mal als es ziemlich lange lief, hatte ich noch keinen MQTT 
Server konfiguriert. Der lief auf WIN10 mit 2Clicks und funzt auch wie 
ich mit MQTT FX testen konnte
Kaum das ich damit beim ESP anfing, gings dann los.
Bei Mosquitto ist kein Benutzername + Passwort definiert, MQTT FX hat 
damit auch kein Problem.
Beim ESP wird die Verbindung abgelehnt, abscheinend weil ich das nicht 
ohne Zugangsdaten konfigurieren kann.
Er versucht das ein paar mal und startet dann mit den defaults neu.
Also ziemlich offensichtlich das die Tasmota FW das mutwillig tut.
Stellt sich für mich natürlich die frage was in einer größeren 
Installation passiert wenn der MQTT Broker oder der WLAN AP mal 
abkoffert.
Robbe ich dann durch Haus und konfiguriere alle ESPs neu?

Mosquitto akzeptiert jetzt alles, nur der ESP ist mittlerweile so 
hinüber das es damit keinen Sinn mehr macht.
Also alles neu heute Abend, wenn ich wieder in meiner Werkstatt bin.

Es mag sein, das die ESP Versorgung nicht Bombe ist, auch mit neuem 
Kabel und Betrieb an der Powerbank nicht(???), aber das sollte nicht zu 
solchem Verhalten führen.
Ich tippe also stark auf die Tasmota FW, die meint verkonfiguriert zu 
sein und mir den Zugriff über die defaults wieder herstellen will.
Das Gegenteil von 'gut' ist eben 'gut gemeint'.

Ich hatte auf eine einfache Lösung gehofft, muss mich jetzt aber wohl 
doch mit den 1000 Optionen beschäftigen.

Unterdessen versuche ich seit gestern Mittag mein Mint Tricia dazu zu 
zwingen node in einer aktuelleren Version als 8 zu installieren um 
IObroker nutzen zu können. Davon 6Std compilieren der 12er Version nur 
um ganz am Ende mit einer Fehlermeldung abzubrechen die zu cryptisch ist 
als das ich mir irgendwas daraus ableiten kann.
Die 10er ging dann, aber nodejs ist noch 8 ...
Für die Linux Cracks sicher 'same procedure als ervery day', für mich 
ein zäher Kampf mit dem System, den ich jedesmal verliere.

Ich muss die Abhängigkeiten selbst erkennen, die Fehlermeldungen 
interpretieren und versuchen aufzulösen.
Seitenweise Kommandos eingeben die ich mir auf Websites zusammensuche, 
weil die offizielle Doku bei IObroker nicht funzt.
Hat was mit veralteten Paketquellen zu tun, aber egal was ich mir da 
abbreche, MINT schaft es immer wieder sich darum herumzuwuseln und mir 
die verkackte 8er Version zu installieren.

Eigentlich wollte ich mir das einfacher machen und erstmal mit Linux auf 
einem alten Laptop arbeiten, um nicht gleich in der Raspi Zero W Hölle 
zu landen.
Aber hier gilt: Alles ausser einfach.

Das hört sich immer alles so easy an wenn Ihr hier Eure Systeme 
automatisiert.
Mal schnell Tasmota drauf, Mosquitto + IObroker und fertig ist der Lack.
Pustekuchen, das ist harter Stoff für jemanden der sich bisher nicht 
groß um Linux und die Inkompatibilitäten der 100 Distributionen 
gekümmert hat.

Heinz R. schrieb:
> Als Alternative evtl. das hier:
> https://github.com/letscontrolit/ESPEasy/releases

Ist nett, danke.
Aber ich muss mich auf ein System festlegen und mich da durchboxen, 
sonst lande ich bei ESPeasy wieder nur in der nächsten Ecke wo was nicht 
geht.

[Stefan F. (Gast)]

M. K. schrieb:
> Lesevorgänge der Konfiguration werden wohl kaum permanent während des
> Betriebes stattfinden

Da würde ich lieber einen Blick in den Quelltext werfen, anstatt falsch 
zu vermuten und damit zu riskieren, in die völlig falsche Richtung 
weiter zu suchen.

M. K. schrieb:
> Es mag sein, das die ESP Versorgung nicht Bombe ist...
> aber das sollte nicht zu solchem Verhalten führen.

Da kennst du die ESP Chips aber schlecht. Sie sind diesbezüglich sehr 
Anspruchsvoll.

M. K. schrieb:
> Er versucht das ein paar mal und startet dann mit den defaults neu.
> Also ziemlich offensichtlich das die Tasmota FW das mutwillig tut.

Steht ja auch so in der Doku. Du kannst das deaktivieren.

M. K. schrieb:
> Ich hatte auf eine einfache Lösung gehofft, muss mich jetzt aber wohl
> doch mit den 1000 Optionen beschäftigen.

Fange mit der Stromversorgung an, überprüfe sie mit einem Oszilloskop. 
Nach meiner Erfahrung ist das in 99% aller Fälle der Knackpunkt. In der 
Zeit wo du den Langen Mecker-Beitrag geschrieben hast, hätte ich schon 
längst kein Messprotokoll fertig.

M. K. schrieb:
> Das hört sich immer alles so easy an wenn Ihr hier Eure Systeme
> automatisiert.

Das ist die gleiche Nummer wie mit Koch-Shows und Youtube Clips. Da 
werden komplexe Sachen gerne als "Kinderleicht" und "ganz schnell" 
dargestellt. Weil sich die Leute gerne bescheissen lassen. Wenn du du 
(so wie ich) schreibst, dass Brot-Backen mindestens 4 Stunden dauert, 
dann will das keiner lesen. Dafür bekommt man keine Likes, egal wie wahr 
es ist.

[M. K. (Gast)]

Stefan ⛄ F. schrieb:
> M. K. schrieb:
>> Er versucht das ein paar mal und startet dann mit den defaults neu.
>> Also ziemlich offensichtlich das die Tasmota FW das mutwillig tut.
>
> Steht ja auch so in der Doku. Du kannst das deaktivieren.

Also genau das Verhalten, das ich beobachte, steht auch so in der Doku 
und lässt sich per optionen abschalten.

ABER:
Stefan ⛄ F. schrieb:
> Fange mit der Stromversorgung an, überprüfe sie mit einem Oszilloskop.

Warum, wenn bereits alles danach aussieht, das es die Optionen sind um 
die ich mich kümnmern muss?

> In der
> Zeit wo du den Langen Mecker-Beitrag geschrieben hast, hätte ich schon
> längst kein Messprotokoll fertig.

Erfahrungsbericht, statt Meckerbeitrag und wenn Du den Thread gelesen 
hast: Ich bin gerade unterwegs und habe somit keinen Zugriff auf mein 
Oszi.
Das ich mit Messungen und Puffer Elko heute Abend weitermache, habe ich 
auch geschrieben, also was sollte jetzt Dein Beitrag?

[Stefan F. (Gast)]

M. K. schrieb:
>> Fange mit der Stromversorgung an, überprüfe sie mit einem Oszilloskop.

> Warum, wenn bereits alles danach aussieht, das es die Optionen sind um
> die ich mich kümmern muss?

Ich habe ich so verstanden, dass du noch weitere Probleme hast, nicht 
nur den Neustart nach 7 Fehlversuchen. Aber bei der Menge Text kann man 
auch mal den Überblick verlieren.

> Das ich mit Messungen und Puffer Elko heute Abend weitermache,
> habe ich auch geschrieben, also was sollte jetzt Dein Beitrag?

Ich wollte dir nur helfen, unter den 1000 Optionen mit einer anzufangen, 
die am vielversprechendsten ist.

[M. K. (Gast)]

Am Ende wird alles gut und wenn es noch nicht gut ist, ist es noch nicht 
das Ende 🤦‍♂️

Ja, da sind noch mehr Probleme, deswegen mache ich mit dem jetzt nicht 
weiter.
Anscheinend ist das ESP Modul sch..ße gelötet.
Das führt zu den Abstürzen des Tasmotizers und das manchmal die Config 
noch nicht mal geschrieben wird.
Ein dreifach HURRA! auf bleifreies Lot.
Sogar das umlaufend gelötete HF Gehäuse ist abgeplatzt als das Teil 
runtergefallen ist.

Mein ursprüngliches Problem scheinen aber die Optionen zu sein.
Ich werde aber der Power besondere Aufmerksamkeit widmen.

[Stefan F. (Gast)]

M. K. schrieb:
> Anscheinend ist das ESP Modul sch..ße gelötet.
> Das führt zu den Abstürzen

Ist das wieder eine Vermutung auf die du gekommen bist, weil es 
unzuverlässig funktioniert? Hoffentlich nicht.

Mit gezielten Messungen kommst du sicher eher voran.

[M. K. (Gast)]

Stefan ⛄ F. schrieb:
> Ist das wieder eine Vermutung auf die du gekommen bist, weil es
> unzuverlässig funktioniert? Hoffentlich nicht.

30J Hardwareentwicklungserfahrung und ein kräftiges Drücken auf das ESP 
Modul haben mich zu dieser Einschätzung gebracht.

Stefan ⛄ F. schrieb:
> Mit gezielten Messungen kommst du sicher eher voran.
UND ICH BIN IMMER NOCH NICHT IN MEINER WERKSTATT UND HABE IMMER NOCH 
KEINEN ZUGRIFF AUF MESSMITTEL.

Herje, das scheint echt schwer für Dich zu sein das zu akzeptieren...

[Stefan F. (Gast)]

M. K. schrieb:
> Herje, das scheint echt schwer für Dich zu sein das zu akzeptieren...

Sei doch nicht so ungeduldig! Mach deine Messungen wenn die Zeit dazu 
gekommen ist und melde dich dann wieder. In der Zwiswchenzeit hast du 
doch sicher erfreulicheres zu tun als über diese blöden ESP Module zu 
grübeln. Oder?

[Joachim S. (oyo)]

M. K. schrieb:
> Ich tippe also stark auf die Tasmota FW, die meint verkonfiguriert zu
> sein und mir den Zugriff über die defaults wieder herstellen will.
> Das Gegenteil von 'gut' ist eben 'gut gemeint'.

Ich würde tippen, dass Deine Vermutung korrekt ist. Also dass das 
ursprüngliche Problem nicht mit der Stromversorgung zu tun hat, sondern 
damit, dass Tasmota aus irgendeinem Grund die Konfiguration auf 
Werkseinstellungen zurücksetzt, und zwar bewusst. Dann ist dieses 
Verhalten bei genauer Betrachtung aber wahrscheinlich gar nicht so doof, 
sondern sogar sinnvoll. Die Tasmota-Entwickler haben sich vermutlich in 
etwa Folgendes gedacht:

Ein frisch mit dem Tasmota-Standard-Binary geflashtes ESP-basiertes 
Gerät weiss absolut gar nichts über seine Umgebung und muss vom Anwender 
erst einmal komplett konfiguriert werden. Wenn er dabei irgendeinen 
winzigen Fehler macht, könnte er das Gerät ganz schnell bricken, so dass 
man (ohne neu flashen, was bei vielen ESP8266-basierten Geräten durchaus 
problematisch ist) gar nicht mehr mit dem Gerät kommunizieren kann, um 
den Fehler in der Konfiguration irgendwie zu beheben. Es gibt auch keine 
allgemein verfügbare Möglichkeit, dass der Benutzer die Konfiguration 
dann manuell z.B. durch langes Drücken eines Buttons zurückzusetzen 
kann.
Also lasst uns das doch folgendermassen lösen: Die frisch geflashte 
Tasmota-Firmware im Werkszustand muss erst einmal vom Anwender 
konfiguiert werden. Wenn dabei irgendetwas schief geht und die Firmware 
merkt, dass etwas mit der Konfiguration nicht zu stimmen scheint, dann 
setze die Firmware nach einer gewissen Zeit auf den Werkszustand zurück, 
um nicht in die Situation zu kommen, dass das Gerät aus Sicht des 
Anwenders ohne Ausweg komplett gebrickt ist.

Wenn der Anwender die Firmware aber irgendwann korrekt und vollständig 
konfiguriert hat, soll er in diesem Moment die "Nach soundsoviel 
erfolglosen Versuchen auf Werkseinstellung zurücksetzen"-Option 
deaktivieren, die standardmässig als letzte Rettung für den Fall einer 
verpfuschten Konfiguration aktiviert ist. Ab dann gibt es nämlich 
üblicherweise auch noch andere Möglichkeiten, wie der Anwender die 
Konfiguration im Notfall komplett zurücksetzen kann, nämlich z.B. über 
einen Button.

[M. K. (Gast)]

In meinem Fall würde ich nie auf Werkseinstellung rücksetzen wollen, 
weil das in jedem Fall die maximale Katastrophe wäre.
Ich kann immer über die serielle an das Modul rankommen aber wenn es mir 
regelmässig die Config zerlegt, weil ich noch am spielen bin oder WLAN 
AP bzw. Broker abkoffern, ist das mehr als nur etwas ärgerlich.
Das System soll später über Jahre durchlaufen ohne das da ein geschulter 
MA vorsitzt der den Schluckauf beseitigen kann.

Bekommen alle anderen die Config tatsächlich auf Anhieb so hin und haben 
noch nie Probleme mit AP / MQTT-Broker gehabt?

Aber okay, das sind dann die Wehen.
Lässt sich ja wohl alles konfigurieren, ich muss nur noch rausfinden 
wie.

Ich verstehe schon das da irgendeine Logig hinstersteht und die 
Entwickler sich dabei was gedacht haben.
Aber es sind doch alle an die Geräte rangekommen ohne das ein Not-AP 
aufgespannt wurde.
Warum muss es denn nach dem flashen der Tasmota FW unbedingt diese 
merkwürdige Selbstrückstellung geben?

Wenigstens eine Automatik die hin un wieder nachsieht ob die alte config 
wieder läuft, wäre doch ratsam gewesen.
Oder gehört das zum smart home dazu, das man alle paar Wochen nach hause 
kommt und nix mehr geht, weil der Raspi seine SD zerschossen hat oder 
der AP nicht mehr mochte?
Beides ist doch nun keine Seltenheit, da muss doch mal jemand vor mir 
drüber gestolpert sein.

Gut, führt zu nix.
Ich mach dann mal weiter.

[Jan L. (ranzcopter)]

M. K. schrieb:
> Bekommen alle anderen die Config tatsächlich auf Anhieb so hin und haben
> noch nie Probleme mit AP / MQTT-Broker gehabt?

ich zumindest habe Tasmota seit V4 dutzendfach im Einsatz, und bisher 
noch nichtmal gewusst, dass es da irgendeinen "back to factory 
setup"-Mechanismus geben soll. Und ja, ich hatte auch schon zeitweise 
Dinge wie MQTT "down" wegen Updates, Problemen oder auch "vergessenen 
Passwörtern"... :)

Andererseits hatte ich aber auch schon ESP-Module, die sich völlig 
erratisch verhielten - dann aber egal, ob mit Tasmota oder ESPEasy etc. 
-> ersetzt, Problem verschwunden.

[Joachim S. (oyo)]

M. K. schrieb:
> In meinem Fall würde ich nie auf Werkseinstellung rücksetzen wollen,
> weil das in jedem Fall die maximale Katastrophe wäre.
> Ich kann immer über die serielle an das Modul rankommen aber wenn es mir
> regelmässig die Config zerlegt, weil ich noch am spielen bin oder WLAN
> AP bzw. Broker abkoffern, ist das mehr als nur etwas ärgerlich.

Wenn Dir die "Zurück auf Standardeinstellungen als letze 
Notlösung"-Sicherheitsvorkehrungen nicht passen, dann stell sie einfach 
ab. Als allererstes, bevor Du irgendetwas anderes konfigurierst. Es gibt 
Geräte, bei denen diese Vorkehrungen sinnvoll oder nötig sind, daher 
müssen sie standardmässig halt aktiviert sein.

Bei Dir nicht, also schalte sie per

SetOption1 1
SetOption36 0
SetOption65 1

einfach aus. (Siehe 
https://tasmota.github.io/docs/FAQ/#device-reset-to-defaults-on-its-own). 
Oder benutze halt nicht die "One size fits all"-Standard-Firmware, 
sondern eine selbst kompilierte mit anderen Standard-Einstellungen.

> Aber es sind doch alle an die Geräte rangekommen ohne das ein Not-AP
> aufgespannt wurde.
> Warum muss es denn nach dem flashen der Tasmota FW unbedingt diese
> merkwürdige Selbstrückstellung geben?

Möglicherweise interpretiere ich Dich da gerade falsch, aber ich 
verstehe das als: "Die Leute sind zum Flashen der Firmware doch 
offensichtlich bereits an die serielle Schnittstelle des ESP8266 
herangekommen, wo also ist das Problem?"

Falls Du das tatsächlich ungefähr so meinst, dann ist Dir wahrscheinlich 
nicht bewusst, dass viele ESP8266-basierten Geräte ganz ohne Kabel etc. 
auf Tasmota-Firmware umgeflasht werden - per WiFi, über eine Software 
namens "tuya-convert".
Es gibt bspw. recht günstig farbige RGB-LED-Lampen mit E27-Fassung mit 
ESP8266 drin zu kaufen. Die sind verklebt - das Gehäuse zu öffnen und 
per Kabel an den ESP anzudocken ist da schwer bis geradezu unmöglich. 
Nicht mal einen Button gibt es an diesen Lampen. Wenn man bei denen 
irgendwas beim Flashen/Konfigurieren verkackt, hat man ein echtes 
Problem. Auch diese Geräte müssen mit der Tasmota-Standard-Firmware 
funktionieren.

> Bekommen alle anderen die Config tatsächlich auf Anhieb so hin und
> haben noch nie Probleme mit AP / MQTT-Broker gehabt?

Ich hatte jetzt noch nie dieses Problem. Obwohl durchaus auch schon mal 
mein MQTT-Broker down oder das WLAN nicht erreichbar war. Das alleine 
scheint Tasmota also noch nicht dazu zu bringen, alles auf 
Werkseinstellung zurückzusetzen. Tasmota scheint bei Dir aus irgendeinem 
Grund zu vermuten, dass da ein schwerwiegenderes Problem vorliegt.
Ich würde mir an Deiner Stelle nochmal ganz genau anschauen, was da vom 
ESP auf der seriellen Schnittstelle gesendet wird. Speziell in dem 
Moment, wenn Tasmota seine Konfiguration "vergisst"/zurückgesetzt wird.

[M. K. (Gast)]

Joachim S. schrieb:
> nicht bewusst

In der Tat.
An sowas habe ich nicht gedacht.

Joachim S. schrieb:
> nochmal ganz genau anschauen, was da vom
> ESP auf der seriellen Schnittstelle gesendet wird. Speziell in dem
> Moment, wenn Tasmota seine Konfiguration "vergisst"/zurückgesetzt wird.

M. K. schrieb:
> Der ESP nimmt die Config an, verbindet sich mit dem WLAN, wirft mir eine
> schöne Meldung raus wie toll er sich doch mit meinem AP versteht und
> dann 37sek später:
> 15:22:29 RSL: stat/tasmota_E83CAC/RESULT = {"Reset":"Reset and
> Restarting"}<\r><\n>
> 15:22:29 CFG: Use defaults<\r><\n>
> 15:22:30 APP: Restarting<\r><\n>

Danach ist der auf default mit Uhrzeit 00:00

HW-Fehler:
Bei meinem ESP Modul ist das GND Pad unterbrochen.
Mal sehen ob das Flickwerk mit Gaslötkolben und NYM Kabel hält und ich 
diesmal weiter komme.

Danke für die option settings!

[M. K. (Gast)]

Jan L. schrieb:
> Andererseits hatte ich aber auch schon ESP-Module, die sich völlig
> erratisch verhielten - dann aber egal, ob mit Tasmota oder ESPEasy etc.
> -> ersetzt, Problem verschwunden.

Da sicher viele hier auch mit dem NodeMCU arbeiten:
Die NodeMCU PCB ist von extrem schlechter Qualität.
(Meine kam von wish, direkt aus China ...)
Leiterbahnen und PADs lösen sich sehr leicht von der PCB.
Die GND Verbindung zum ESP Modul war unterbrochen, nach dem flicken 
gings kurz, bis es sich nicht mehr flashen ließ.
Habe das ESP Modul mit Heißluft getauscht, gleicher Fehler.
Schliesslich war es die GPIO0 Verbindung zum VT2 Transistor der am CH340 
hängt und das Modul in den Flash Modus bringt.

Die Verbindungen reissen zwischen den Pads des ESP Modul Footprints und 
den korrespondierenden Bauteilen der NodeMCU PCB ab. Schon in der 
Originalbestückung, ohne da man daran herumbrät.
Nur das Modul völlig gewalltfrei mit Heißluft runter, und die Pads lösen 
sich bereits. (Ja, ich kann das. Das ist mein Job ;-))
Wahrscheinlich reissen da Vias intern ab.

Von der Oberseite der Modulanschlüsse bis an die Bauteile der NodeMCU 
PCB Durchgang messen, wenn ihr merkwürdige Probleme habt.
Nachlöten bringt nix, da muss Fädeldraht ran.

Es wird nicht einfacher dadurch, das die Verbindungen manchmal auch noch 
funktionieren.

Der zusammengeflickte NodeMCU läuft jetzt stabil.
Also nehme ich alles zurück was ich über die tasmota FW gesagt habe.
Die hat einfach nicht gewusst was sie mit dem Schei* anfangen soll den 
der ESP da veranstaltet hat und ist auf defaults zurückgegangen.

[Angie (Gast)]

Ja,ja, wie so oft werden Hardware-Probleme auf die Software geschoben 
;-)
Und, wer bilig kauft, kauft doppelt und "beschimpft" auch noch die 
wirklich gute SW vom Theo und allen weiter daran Beteiligten.
--> https://tasmota.github.io/docs/About/

MfG Angie

[Stefan F. (Gast)]

M. K. schrieb:
> Die NodeMCU PCB ist von extrem schlechter Qualität.

Ich möchte darauf hinweisen, dass das originale NodeMCU Board von sehr 
guter Qualität war. Aber es gibt nur noch chinesische Nachbauten zu 
kaufen. Die nennen jeden Müll NodeMCU, wenn er nur einen ähnlichen 
Formfaktor hat. Oft ist die Bestückung völlig anders, als beim Original.

Das Einzige, was diese Boards mit dem originalen NodeMCU gemeinsam 
haben, ist die Beschriftung der Pins.