Was war das?Plötzlicher IT/Sduino-Komplettausfall-nur durch Update zu reparieren

Begonnen von Jogi, 27 Juli 2019, 13:53:49

Vorheriges Thema - Nächstes Thema

Jogi

Hallo,
ich hatte diese Woche einen seltsamen Fehler. Ich war auf Dienstreise und bekam eine Info meiner Familie: "Deine Technik spinnt".
Ich habe mich dann per VPN aufgeschaltet und konnte keinen Fehler entdecken. Mit Hilfe der Familie konnte ich den Fehler dann auf IT eingrenzen. Sämtliche IT-Geräte (Steckdosen) waren nicht mehr ansprechbar. Die werden alle über Sduino (nano) geschaltet.
Die Befehle gingen alle scheinbar normal raus, aber es wurde nichts geschaltet.
Alle Maßnahmen zur Fehlerbehebung, die ich normalerweise ergreife (Sduino-Reset, FHEM-Neustart, Rasp-Neustart, ...) brachten keinen Erfolg. Ich konnte den Fehler aus der Ferne nicht beheben und musste mir natürlich entsprechende Kommentare meiner beiden weiblichen Familienmitglieder anhören.
Als ich dann wieder zu Hause war, habe ich mich sofort auf die Fehlersuche gemacht. Da ich nichts erkennen konnte und auch erneute Neustartversuche keine Hilfe brachten, habe ich gedacht, der Fehler läge an einem defekten nano Sduino und wollte ihn durch einen anderen Sdunio, den ich als Reserve habe, ersetzen. Aber auch das brachte keinen Erfolg. Das gleiche Problem.
Eher aus Verzweiflung, als aus logischer Schlußvolgerung habe ich dann ein FHEM-Update und einen Neustart gemacht und danach lief alles wieder ganz normal, sowohl mit dem NanoSduino als auch mit dem Ersatz Sduino.
Jetzt habe ich zwar wieder etwas gelernt, aber verstehen tue ich das ganze nicht. Mein System ist immer ziemlich aktuell. Ich mache einmal monatlich ein FHEM- und ein Raspi-Update.
Vor dem Fehler wurden keine Veränderungen durchgeführt und als ich das Haus verließ lief noch alles normal.
Ich kenne es normalerweise so, dass es zu einem Fehler kommen kann, wenn man etwas neues installiert und vorher oder nachher kein Update macht. Aber das im laufenden Betrieb ein Update fehlt???

Hat jemand eine Idee, was das gewesen sein könnte und wie man das vermeiden kann?





KölnSolar

ZitatAber das im laufenden Betrieb ein Update fehlt???
Kann ich mir als Fehlerursache auch nicht vorstellen. Du könntest mal gucken, was erneuert wurde. Du siehst ja im Verzeichnis restoreDir/update/.... die "ausgelagerten" files und im Logfile siehst Du die files die "neu" durch das update angelegt wurden(alternativ zum Logfile anhand der timestamps im Modulverzeichnis FHEM). Irgendwo müsste ja 10_IT oder 00_SIGNALduino auftauchen, wenn Deine Fehleranalyse stimmen würde.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Ralf9

ZitatSämtliche IT-Geräte (Steckdosen) waren nicht mehr ansprechbar. Die werden alle über Sduino (nano) geschaltet.
Hat der Empfang noch funktioniert?
Wurde, bevor das Schalten der IT-Geräte nicht mehr funktionierte, ein fhem neustart, ein reload von Modulen oder ein rereadcfg gemacht?

Gruß Ralf

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Jogi

Zitat von: KölnSolar am 27 Juli 2019, 19:07:52
Kann ich mir als Fehlerursache auch nicht vorstellen. Du könntest mal gucken, was erneuert wurde. Du siehst ja im Verzeichnis restoreDir/update/.... die "ausgelagerten" files und im Logfile siehst Du die files die "neu" durch das update angelegt wurden(alternativ zum Logfile anhand der timestamps im Modulverzeichnis FHEM). Irgendwo müsste ja 10_IT oder 00_SIGNALduino auftauchen, wenn Deine Fehleranalyse stimmen würde.
Ich habe  jetzt mal versucht Deine Anweisungen zu befolgen und Licht ins Dunkel zu bringen.
Im Verzeichnis restoreDir/update/.... finde ich mehrere Dateien, unter anderem auch die 00_SIGNALduino.pm
Im Logfile finde ich nach dem Update folgende Einträge zum SDuino:

Vor dem Update:
2019.07.25 21:31:54 1: PERL WARNING: Use of uninitialized value in eval "string" at ./FHEM/00_SIGNALduino.pm line 257, <$fh> line 1450.

Während und nach dem Update:
2019.07.25 22:13:42 1: UPD FHEM/00_SIGNALduino.pm
2019.07.25 22:13:45 1: UPD FHEM/90_SIGNALduino_un.pm
2019.07.25 22:13:49 1:  - feature: 90_SIGNALduino_un.pm: support tracing geiger rohrmotor signals
2019.07.25 22:13:49 1:  - change:  00_SIGNALduino.pm: v3.4.0
2019.07.25 22:13:49 1:             Option to reconstruct last bit of transmission in MU and MS signals
2019.07.25 22:13:49 1:             if there is enough data to detect it.
2019.07.25 22:13:49 1:             Moved protocol hash into a separate perl module instead of loading
2019.07.25 22:13:49 1:             a simple textfile into a variable.
2019.07.25 22:13:50 1:             Added standard deviceOverview output in detail page #545
2019.07.25 22:13:50 1:             new internal (Protocol_ID), which will provide the protocolID in
2019.07.25 22:13:50 1:             logcial modules.
2019.07.25 22:13:50 1:             Drop-down list for set command config CC1101 (#589)
2019.07.25 22:13:50 1:             add drop-down list for cc1101_bWidth, cc1101_rAmpl and cc1101_sens


@Ralf9: Das mit dem Empfang habe ich nicht getestet. Normalerweise nutze ich den SDuino nur zum Senden. Einen Neustart hat es unmittelbar davor nicht gegeben. Vielleicht 2 Tage vorher.

Bringt das Licht ins Dunkel? Mir ist der Fehler immer noch unklar.


KölnSolar

ZitatBringt das Licht ins Dunkel?
Es wird heller.  :)
Zumindest ist jetzt klar, dass es die 00_Signalduino.pm war. Jetzt könntest Du noch im Sourcecode  restoreDir/update/2019-07-25/00_SIGNALduino.pm gucken, welche Version es vor dem Update war(1. Zeile hier posten).

Mit der Info kann dann der maintainer evtl. nachvollziehen, was genau passiert sein könnte. Es kann aber natürlich auch so etwas gewesen sein, wie SD-Karte kaputt oder ..... Also irgendein individuelles Systemproblem, welches sich durch update der 00_SIGNALduino.pm gelöst hat.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Jogi

Zitat von: KölnSolar am 29 Juli 2019, 10:22:59
Es wird heller.  :)
Zumindest ist jetzt klar, dass es die 00_Signalduino.pm war. Jetzt könntest Du noch im Sourcecode  restoreDir/update/2019-07-25/00_SIGNALduino.pm gucken, welche Version es vor dem Update war(1. Zeile hier posten).

Mit der Info kann dann der maintainer evtl. nachvollziehen, was genau passiert sein könnte. Es kann aber natürlich auch so etwas gewesen sein, wie SD-Karte kaputt oder ..... Also irgendein individuelles Systemproblem, welches sich durch update der 00_SIGNALduino.pm gelöst hat.

Vielen Dank für Deine Tipps.
Das ist die alte Version:
# v3.3.4 (stable release 3.3)

Danke auch für den Tipp mit der SD-Karte. Das wäre für mich eine logische Erklärung, auf die ich noch nicht gekommen bin. Ich werde das mal im Auge behalten. Oder ich tausche sie sicherheitshalber gleich aus.

Ralf9

Eine Möglichkeit wäre,  du hattest am Anfang die v 3.4.0 (dev-r34) und bist dann durch ein fhem Update auf die v 3.3.4 gewechselt, bei der v 3.3.4 ist es dann unter gewissen Umständen denkbar, dass es Probleme beim laden des protocoll hash gibt

Gruss ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

point3r

Hallo zusammen,

ich hole diesen Thread noch einmal aus der Versenkung, weil er mein Problem quasi genau beschreibt, die Lösung aber nicht funktioniert.

Ich betreibe einen Signalduino, der Somfy und IT-Steckdosen bedient. Das funktionierte auch eigentlich sehr gut, seit neuestem gibt es aber den Fehler, dass zwar die Rollläden einwandfrei fahren, die Steckdosen nicht mehr geschaltet werden.

Das Problem tauchte erstmalig auf, als die 00_SIGNALduino.pm am 16.07.2020 aktualisiert wurde. Nach mehreren Varianten (wieder zurückspielen auf die alte 00_SIGNALduino.pm) kam ich dann zur vermeintlichen Lösung, dass ich die Firmware des sduino auf v3.4.0 aktualisiert habe sowie die Version v3.4.4 der 00_SIGNALduino.pm verwende.

Nach etwa einer Woche ohne Probleme kann ich jetzt aber die Steckdosen erneut nicht schalten. Ein Reset des sduino löst das Problem, aber ich wollte nicht unbedingt nach 24h automatisch ein Reset machen.

Gibt es noch weitere Optionen, die ich mal testen kann?

Danke!

point3r

Ralf9

Was für eine sduino Hardware verwendest Du?
Du kannst mal meine alternative Firmware V 3.3.2.1-rc9 testen
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

point3r

Guten Morgen,

ich verwende einen c1101 mit Arduino nano, hab' mal die Firmware geflashed, ich werde berichten. Im Moment scheint alles zu gehen.

Grüße

point3r