[GELÖST] - Sporadisch passiert etwas / Licht an/aus ohne erkennbaren Grund

Begonnen von 87insane, 07 Februar 2019, 12:55:17

Vorheriges Thema - Nächstes Thema

Wernieman

d.h. nach einem solchen Verhalten (Kurzer Lichtimpuls) hattest Du ein reboot des ESP?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

87insane

Ja!

Habe jetzt gerade das Thema wieder gehabt und im ESP geschaut warum.
Ich sehe hier:

Boot: Manual reboot (53)
Reset Reason: Hardware Watchdog


Wie ich dort nun genauer weiter suchen muss, muss ich auch erst mal googlen.

Wernieman

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

87insane

Sicher das es nur WLAN sein kann? Hab alle schalter mal geprüft heute morgen. Alle sind nie länger an als 24,25 Stunden und laufen dann in ein Reset. Die schalter sind an unterschiedlichen Orten. Die rssi werte sind von sehr gut<50 bis hin zu 78+. Es muss aufgrund dessen ja einen anderen Grund geben oder aber probleme in der espeasy Firmware. Kann man das mit einem Syslog Server auslesen?

Wie kann ich weiter debuggen? Wenn es wirklich WLAN sein sollte, was mögen die ESP easy geräte nicht? Bei mir sind sie im N Netzwerk mit DHCP Reservierung für jeden Schalter.  Ansonsten gibt es keine Reglementierung für die Schalter. Bin aktuell echt ratlos. Da es anscheinend alle sind. Die Rollo Schalter machen nach reboot keine komischen Dinge. Die schalter, die für Licht genommen werden, mit den einfacheren regeln laufen in komisches verhalten. Würde das gerne alles sauber haben aber bin ideenlos. Ggf hilft ne neue FW, wenn ggf WLAN issues behoben wurden. Aber wenn dem nicht so ist...?

Beta-User

Zu WLAN und - v.a. den ESP-Dingern - gibt es bereits Dutzende Beiträge...

Häufigstes Problem: "Falscher" AP (Fritzbox) iVm. zu vielen Geräten (so ab Mitte 20 wird's gerne lustig - Handys usw. bitte mitzählen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

Naja - die Schalter laufen ja über WLAN und ich kann sie kontrollieren. Weswegen es ja der richtige sein muss. Ich habe aktuell aktiv:

1 x Router im AZ
1 x Repeater im Flur

X Geräte im WLAN. Es sind ca. 40 Geräte im Netzwerk (Kabel u. WLAN). Der Router kommt mit der Verwaltung aber gut hinterher. Ich habe keine 0815 Hardware von der Tcom oder so.

Ein Gedanke wäre, dass die Dinger ggf. mit dem N draft nicht komplett klar kommen. Das könnte ich leicht testen. Interessanter wäre es natürlich den genauen Fehler zu haben. Habe gelesen, dass die Dinger auch bei Loop (fehlerhafter Code) WLAN trennen und dann neu starten. Gibt es eine Möglichkeit an den genauen Fehler zu kommen? Werde gleich mal nach den anderen Threads gucken.
Das Rollo in der Küche so wie auch der Schalter im Bad, laufen über den Repeater. In der ESP FW kann man leider nicht sagen, zu welchem AP (mac Adresse) er sich verbinden soll. Man kann nur auswählen wie das Netzwerk heißt. Sobald das geschehen ist, verbindet er sich immer einfach nur mit der stärkeren Sendequelle. Was aber auch egal ist, da einige der anderen Schalter auch direkt am eigentlichem Router hängen und die machen die gleichen Probleme.

Beta-User

Na ja, du kannst noch 10x behaupten, dass da kein Problem ist, weil da keines sein darf ;) .

Tatsache ist, dass die AVM-Büchsen, die du da scheinbar hast (warum verschweigst du das?!? Danach war indirekt, aber doch hoffentlich an sich klar gefragt...), eben genau zu den unmotivierten Reboots der ESP-basierten Geräte passen. Kannst du gerne wegdiskutieren wollen, aber ich bin dann mal raus aus der Diskussion ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

#82
Ich denke du hast es missverstanden. Ich diskutiere nicht, ich bin verzweifelt.

Ich habe KEIN AVM! Würde ich auch nicht kaufen! Aus welchem Schluss, LOG oder sonst was, ziehst du diese "Erkenntnis"?
Ich habe einen Netgear Router R7500 und einen DLINK Repeater, da mein anderer gerade platt ist, hatte den für draußen genutzt.

Ich gebe mir Mühe alle Fragen zu beantworten und damit weiter zu kommen. Aber hier einfach Unterstellungen zu machen, ist wenig zielführend!

Hinzu kann es ja sein, das ggf. Problem mit der Koexistenz von 20/40Mhz oder aber dem N draft bestehen. Das sagte ich aber auch vorhin. Was ich leider nicht gefunden habe, ist ein Weg, genau zu prüfen, was der Schalter sagt in diesem Moment. Die Erkenntnis das ein HW Watchdog nur auf WLAN Probleme zurück zu führen ist, ist mir auch nicht ganz schlüssig. Vermute mal, das ist Erfahrung.

EDIT:
In den neueren Versionen von ESP habe ich mal das changelog angesehen. Aktuell steht z.B. dies drin:

[WiFi] Allow force to B/G to improve WiFi stability.
[WiFi] Correct fall-back when B/G only mode cannot connect
[WiFi] Add option to set wifi off and restart wifi when connection lost


ggf. bringt das schon was. So würde ich den n draft anlassen können. Aber es genauer zu wissen, wäre natürlich super!

Beta-User

Sorry für die falsche Unterstellung.

Jedenfalls ist es so, dass du nicht der einzige bist, bei dem die ESP's ab einer gewissen Anzahl spontane Reboots hinlegen und keiner so richtig weiß, was die eigentliche Ursache ist - Router, Firmware, EMV-Themen....
Statistisch gesehen tritt das halt bei bestimmten Hardware-Kombinationen häufiger auf, aber sowas wie gesicherte Erkenntnis hat wohl keiner. Ist einer der Gründe, warum ich sehr ungern WLAN-Gerätschaften in mein FHEM integriere und manchmal vielleicht über's Ziel rausschieße, wenn es nahe liegt, dass "sowas" mal wieder Probleme macht ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wernieman

Kleine Nachfrage:

Alle Deine esp8266 rebooten innerhalb von 24h?
Also keine uptime >24??

Mein letzter "Problemkandidat":
GIT version: mega-20190121
Local Time: 2019-02-20 11:00:41
Uptime: 16 days 10 hours 49 minutes


- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

87insane

#85
Heute Morgen schaute ich nach ob alle betroffen sind. Leider sind es tatsächlich alle...

Einer war einen Tag und 2 Stunden an. Alle anderen hatten heute nacht (verschiedenste Zeiten) einen reset gemacht (also unter 24h).


Hatte oben zwar schonmal gefragt aber kann der Syslog Server sowas genauer anzeigen? Habe noch keinen aufgesetzt, da mein Rechner ja auch noch defekt war (kommt echt alles zusammen im Moment). Wenn er es eingrenzen könnte, würde ich ASAP einen einrichten und laufen lassen. Ggf. bringt die Analyse ja anderen auch noch was.

ZitatMein letzter "Problemkandidat":
Code: [Auswählen]
GIT version:   mega-20190121
Local Time:   2019-02-20 11:00:41
Uptime:   16 days 10 hours 49 minutes

Lustig.... Meine sind aktuell alle auf mega-20190121. Aber sowas wie 16 Tage.... Das ist ja schon Luxus :)

EDIT: Da ich aktuell ja noch alles mit logge was den Schalter im AZ angeht, habe ich gerade mal geschaut..... Er steht seit ich das LOG aktivierte auf present in FHEM. Nicht ein einziges absent. Dies würde ja umgekehrt heißen, das zumindest FHEM immer genug Infos bekommen hat, bzw. die Intervalle nicht überschritten wurden. Das ist wenigstens etwas....

Gibt es so ne art Liste, in der drin steht was ESPEASY nicht mag an WLAN Einstellungen? Kann zum testen mal die Koexistenz + n draft aus machen. Das ist schonmal eine Idee. Hinzu würde ich einen Schalter mal auf die neue ESPeasy Version anheben, in der auch im Changelog steht, dass dort wifi Seitig was geändert wurde (Release mega-20190215).

Wernieman

Habe die Version drauf, da mit "älteren" genau dieser esp sich heufiger aus dem WLAN verabschiedet hatte.

Bezüglich Present:
Fhem sagt nur das er absent ist, wenn er sich nicht X-Sekunden (einstellbar) gemeldet hat. Da ein reboot dieser Dinger bekanntlich sehr schnell ist, dürfte innerhalb dieser Zeit immer ein "Datum" kommen. Ich glaube (Hinweis: glauben<>wissen), das es im Default eine Zeit von 5 Minuten war.

Bzw:
Wenn Du die uptime bei den RSSI Werten mitsendest (habe ich bei mir so), könntest Du Dir eine Alarmierung/Info bauen, wenn die uptime kleiner wird, da dann ein reboot stattgefunden haben müsste.

Bezüglich Syslog:
Ich weiß nicht, was der esp beim log "info" alles mitloggt, habe es bei mir auf "error" stehen. Natürlich muß das WLAN laufen, solche Fehler wird er "schlecht" senden können. Aber wie immer gilt: In einem solchem Falle ist jeder "Brotkrumen" an Info sinnvoll! Schließlich sind wir nur dadurch darauf gekommen, das es schon auf esp/wlan-Seite passiert.

Habe übrigens deshalb bei mir deshalb ein eigenes WLAN nur für die esp aufgespannt. Meine Zotac hatte ein freien, hostapd fähigen, WLAN-Controller .... ;o)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

87insane

Hmmmm...

Kann man auf einem ESP direkt in ein LOG File schreiben? Ich meine Platz wäre ja noch und so könnte er vor dem Restart alles mit schreiben...?

Wie gehen wir/ich nun vor?
- Als erstes wollte ich einen Schalter auf die aktuelle ESPeasy FW bringen. Die anderen lasse FW-Seitig unberührt.
- Zusätzlich werde ich die Koexistenz abschalten (20/40Mhz).

Danach kann ich ja leider erstmal nur warten. Hinzu würde ich gerne den n draft aus machen aber das erst wenn die beiden Dinge oben nix gebracht haben. Habe es so vor, da ich sonst nicht weiß, was es am Ende war.
Weitere Ideen / Anregungen nehme ich aber gerne auf! 

Wernieman

ob lokales log möglich ... mir nicht bekannt. Deren Flash-Speicher mag häufig auch kein mehrmaliges überschreiben.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

87insane

#89
1. Koexistenz ist nun aus.
2. Schalter im AZ mit mega-20190216 geflasht und hängt nun im Netzwerk.

Was mir gerade noch aufgefallen ist: Der Schalter vom Bad hat nun Uptime:   1 days 11 hours 44 minutes. An diesem hatte ich aber auch nichts geändert. Der Router neustart von 5 min hat ihn nicht interessiert. Aber der hängt auch hinter einem Repeater. ABER auch die Schalter die auf dem Hauptrouter hängen haben in den 5min noch keinen Stress gemacht und liefen bzw. laufen weiter.

Das mit dem internen Log werde ich mal googlen. Also bei den Sonoff T1 habe ich bei meinem Test-Schalter auf meinem Tisch bestimmt schon 25 mal was anderes drauf geflasht. Bisher ist es okay für ihn. Ohne internes Log, sehe ich wenig chancen (deine Begründung, weiter oben...). Aber trotzdem werde ich extern mit loggen. Dafür muss ich mir noch einen Server basteln. Ich sehe die chance das er ggf. vor seinem Reboot noch genug in das externe Log schreibt, um zu wissen warum er sich neustartet.

EDIT: Noch nicht an aber in der neuen FW vorhanden...(siehe Screen)