Nachtrag zum letzten HMCCU Update

[zap]

Mit dem letzten Update wurden HMCCUCHN/HMCCUDEV um folgende Funktionen erweitert:

• Beim Attribut ccureadingfilter kann man nun die Filterung auf bestimmte Kanäle einschränken. Das ist hilfreich, wenn ein Datenpunkt in mehreren Kanälen vorkommt, man aber nur einen als Reading haben möchte.
• Beim Attribut stripnumber kann man nun die Rundung von Zahlen Datenpunkt spezifisch festlegen.

Weitere Infos dazu in der Commandref von HMCCUCHN.

[StephanFHEM]

Hallo,

ich musste heute meinen Raspi neustarten und musste dann leider feststellen, dass nix mehr lief (nach ca. 10 Sekunden ist der Rapsi immer wieder abgestürzt und FHEM nicht erreichbar). Nach viel basteln unter Ausnutzung des 10 Sekunden-Fensters habe ich rausgefunden, dass der Absturz in der Start-Phase von FHEM erfolgte. Der letzte Logeintrag war dann folgender:

Code Auswählen Erweitern

undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 142, <$fh> line 2861.

nachdem ich dann alle 88_HMCCU*.pm Dateien manuell gelöscht habe lief es wieder wie am Schnürchen (bis auf die Fehlermeldung der HMCCU-Geräte natürlich).

Ich denke, der Fehler muss durch das letzte Update reingekommen sein. Da ich nach dem Update nicht sofort ein Shutdown Restart gemacht habe ist es erst heute aufgefallen.

Wäre prima, wenn du das beheben könntest!

Grüße
Stephan

[zap]

ich musste heute meinen Raspi neustarten und musste dann leider feststellen, dass nix mehr lief (nach ca. 10 Sekunden ist der Rapsi immer wieder abgestürzt und FHEM nicht erreichbar).

Ist der Raspi abgestürzt (also Linux/OS mäßig) oder "nur" FHEM?

Nach viel basteln unter Ausnutzung des 10 Sekunden-Fensters habe ich rausgefunden, dass der Absturz in der Start-Phase von FHEM erfolgte. Der letzte Logeintrag war dann folgender:

Was auch immer das 10 Sekunden Fenster ist ... melde Dich mal auf dem Raspi an (ich vermute, nur das FHEM stürzt ab) und schau Dir das Logfile an. Interessant sind die Logfile Meldungen vorher. Die Meldung mit der undefined subroutine ist nur eine Folge davon, dass HMCCU nicht geladen werden konnte. Also bitte mal die 1. HMCCU Meldung nach dem Start suchen und posten.

Solange ich die Ursache nicht kenne, kann ich nichts beheben. Und bei anderen Usern läuft die 4.2

[StephanFHEM]

also.... es ist definitiv das ganze System abgestürzt und nicht nur FHEM.

Das 10 Sekunden-Fenster war immer die Zeit von Strom an bis Systemabsturz. In der Zeit konnte ich mich dann per Putty noch gerade verbinden um dann nach 10 Sekunden wieder rausgeworfen zu werden. Nur durch manuelles abschalten von FHEM innerhalb der 10 Sekunden konnte ich den Absturz verbindern. Die von mir zitierte Zeile war dann der jeweils letzte Eintrag im Log von FHEM.

Das ganze lief wieder nachdem ich die HMCCU-Dateien gelöscht habe. Ich habe diese Dateien mittlerweile wieder eingefügt aus einem älteren Backup und damit läuft auch wieder alles.

[Wernieman]

Könntest Du bitte mal ein Filesystemcheck machen? Das FHEM das System runterreist ist NICHT normal ... Du hast doch ansonsten eine "standard-Fhem-installation"?

[StephanFHEM]

also.... ich habe eine normale FHEM auf Jessie Lite ... und dazu dann noch YAHM.

Systemcheck werde ich beizeiten noch machen. Hatte heute schon genug Reboots;-)
Denke aber, dass es bei Fehlern auf SD-Card jetzt auch nicht mehr vernünftig laufen würde. Und es rennt seit dem Austausch der HMCCU-Dateien heute Morgen ohne Probleme

[zap]

Möglicherweise waren genau die TEile der SD Karte hinüber, wo die neuen Module lagen.

Ein FHEM wird auch bei krassen Modulfehlern nicht Linux abschiessen können. Ok, vielleicht wenn es als root läuft, aber wer macht sowas schon 

[Wernieman]

Deshalb ja die Frage: " standard-Fhem-installation?"

Was mir nur dazu einfällt:
- Defektes System (deshalb FileCheck)
- Defekte Hardware

FHEM kann (nicht darf) durch ein Update oder sonstige Fehler abschmieren. Das es aber gleich das System mitreist ... ist extrem ungewöhnlich.

Ist eigentlich wirklich das Systerm weg? Was steht den in der "var/log/kern.log" zu der Zeit?

[StephanFHEM]

sieht so aus, als ob das System schon noch lief. Da steht eine Menge drin, aber davon sieht für mich nichts wie eine Fehlermeldung aus.
Kann es sein, dass durch das HMCCU Modul das Netzwerk durch eine Art Dauerschleife so ausgelastet war, dass nicht mal mehr Putty zugriff hatte? Obwohl es eigentlich am LAN hängt

[Wernieman]

Wenn die Auslastung bei 100% liegt kommt auch ssh (putty) nicht mehr durch ... dann ist der PI aber auch nicht abgestürzt ..

[zap]

Die Fehlermeldung im FHEM Log deutet darauf hin, dass das IO Defice nicht definiert werden konnte. Dazu gibt es mit ziemlicher Sicherheit eine Meldung im Logfile. Solange ich die nicht kenne, ist alles andere ins Blaue geraten.

Und nein, HMCCU lastet weder die CPU noch das Netz aus. Man kann HMCCU dazu bringen, dass es eine Zeit lang auf die CCu wartet, mit der Option waitforccu. Aber selbst dieses Warten wird mit sleeps ausgeführt, d.h. Andere Prozesse kommen zum Zug.

was auch wichtig ist: das IO Device muss vor den anderen CCU Devices definiert werden in der fhem.cfg. Sonst wird das Modul nicht geladen und es würde auch die gleiche Fehlermeldung kommen. wenn du die fhem.cfg nicht manuell editiert hast, sollte dieses Problem jedoch nicht auftreten. Wenn du sie manuell editiert hast, kann ich dir auch nicht helfen.

[StephanFHEM]

Hallo,

hab das Update jetzt erneut gemacht und dieses mal lief alles sauber! Keine Ahnung wo er letztes mal den Schluckauf hatte. Am System wird wohl auch nichts kaputt sein, weil es seit dem Tag problemlos 24h/Tag lief.

jetzt aber noch eine kurze Frage: Hab auf den neuen RPC-Server gestellt. Kann ich das alte Device "HMCCURPC" jetzt löschen?

Grüße
Stephan

[zap]

jetzt aber noch eine kurze Frage: Hab auf den neuen RPC-Server gestellt. Kann ich das alte Device "HMCCURPC" jetzt löschen?

Grüße
Stephan

Ja, kannst du löschen. Wenn Du wieder auf extrpc umstellen solltest, wird es wieder angelegt.