Nach Update Fehlermeldung?

[topfi]

Ich muss diesen thread leider wieder aus dem Grab holen. Bei meinem Raspi mit CUL 868 habe ich exakt dieses Problem wieder:
Symptome: Nach einem Rechnerneustart läuft zunächst alles  ordnungsgemäß, aber nach kurzer Zeit führt der CUL die Intertechno-Befehle nicht aus und schreit die ganze Nacht "help me!". Die Lott-Rolläden und den Energiemonitor im 868-Band betätigt er komischerweise.

Diagnose: auf der Schnittstelle werden die Echos zunächst nach einem fhem-Neustart ordnungsgemäß deaktiviert:

Code Auswählen Erweitern

stty -a < /dev/ttyACM0
speed 38400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl echoke


aber nach einiger Zeit wieder aktiviert:

Code Auswählen Erweitern

stty -a < /dev/ttyACM0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke


Dann geht der Zirkus los.
Ich kann das wie folgt reproduzieren: sudo fhem Service stop/start --> Zustand 1 (Echos aus)

Wenn ich nun auf der Weboberfläche den room wechsle, springt der Raspi auf Zustand 2 (Echo an) 
Mit dem nächsten Intertechno-Befehl, schreit der CUL dann Hilfe, führt den Befehl NICHT aus  und macht nichts mehr. Irgendwann (bei einem der nächsten Intertechno-Befehle, die auch nicht ausgeführt werden) setzt er sich zurück und das System läuft normal durch. Es wird auch kein Echo mehr aktiviert. Das Zurücksetzen mit "Normalisieren der Echo-Einstellungen"  kann man manchmal (leider klappt das nicht immer) durch aufeinanderfolgendes

set CUL1 T0 0000
set CUL1 raw B00

auslösen.

So, und nun schreie ich mal: "... help me!" 

[topfi]

Eben konnte ich das etwas eingrenzen:

Nach einem reboot des Raspi steht das Echo richtig auf off. Bis ich eine Seite (einen room auf der Weboberfläche) aufrufe, auf dem es einen Plot gibt (egal, welchen). Dann springt das echo auf on. Setze ich dann von der fhem-Oberfläche MIT einem Plot den CUL zurück mittels raw B00, dann stellen sich die Echos auf off und bleiben bis zum nächsten reboot auch da.
Setze ich den CUL von einer Seite OHNE Plots aus zurück, werden die Echos auf off gestellt, stellen sich aber wieder auf on, wenn ich auf eine Seite mit einem SVG-Plot wechsle.

Lange Rede, kurzer Sinn: Nach jedem Reboot muss ich auf eine Seite mit SVG-Plots wechseln und set CUL raw B00 machen.

Aber welches Modul mir die Schnittstelle verkehrt setzt, und warum es das nur nach einem reboot tut, weiß ich leider nicht.

Hat sonst niemand Probleme mit dem CUL nach einem reboot?

[topfi]

Ich habe plotfork soeben als Übeltäter ausgemacht. Ein Aktivieren von plotfork bewirkt, dass die Kommunikation mit dem CUL gestört wird.  Nochmal zum Verständnis:

* Raspberry mit CUL V3
* reboot des gesamten Raspi (nicht nur shutdown restart)
* FHEM arbeitet zunächst normal.
* Nachdem irgendeine FHEMWEB-Seite mit einem SVG_PLOT aufgerufen wurde, werden die Eigenschaften der USB-Schnittstelle /dev/ttyACM0 derart geändert, dass die Cefehle zum CUL ein lokales Echo bewirken.
* Damit kann der CUL nichts anfangen, das log füllt sich nach mindestens einem Schaltbefehl mit Einträgen der Art:

Code Auswählen Erweitern


2014.07.05 12:18:17 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:17 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:17 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:16 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:16 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:16 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:15 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:15 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:14 3: CUL1: Unknown code is0f0000ff0ff0, help me!
2014.07.05 12:18:14 3: CUL1: Unknown code is0f0000ff0fff, help me!
2014.07.05 12:18:14 3: CUL1: Unknown code is0f0000ff0ff0, help me!
2014.07.05 12:18:13 2: IT IODev device didn't answer is command correctly:   raw => is0F0000FF0FFF
2014.07.05 12:18:13 2: IT set Ambiente_Treppe off
2014.07.05 12:18:13 3: CUL1: Unknown code is0f0000ff0fff, help me!
2014.07.05 12:18:13 3: CUL1: Unknown code is0f0000ff0fff, help me!
2014.07.05 12:18:13 3: CUL1: Unknown code is0f0000ff0fff, help me!
2014.07.05 12:18:12 2: IT set Ambiente_Treppe on


*Manuelles Abstellen des Echos:  "stty < /dev/ttyACM0 -echo" hilft nur so lange, bis wieder eine Seite mit einem Plot angeschaut wird.
*Reset des CUL mittels "set CUL1 raw B00" beseitigt das Problem und sellt das Echo dauerhaft aus. Aber nur dann, wenn der Fehler vorher bereits aufgetreten ist.

Das passiert übrigens auch, wenn plotfork zum Zeitpunkt des reboots disabled war und später von der Weboberfläche aktiviert wird. Der erste Wechsel auf eine Seite mit Plots löst das Problem aus.

Was kann ich tun, um plotfork wieder benutzen zu können? Das hat mir nämlich die timeouts beim Heartbeat des HMLAN-Adapters beseitigt. Kann man die Schnittstelle beim Raspi während des Boot-Prozesses bereits dauerhaft so setzen, dass das echo off bleibt?

[topfi]

Um mein Selbstgespräch hier abschließen zu können: Eben habe ich auf dem Raspi ein "apt-get upgrade" gemacht und seitdem ist das Problem verschwunden. Hätte ich das mal gleich getan... Der war allerdings auch ein großer Service, hat den ganzen Kernel ausgetauscht.

Vielleicht hat ja der nächste was davon.

[topfi]

Und nun doch wieder 

Also plotfork ausgemacht, dann geht es. Aber dass sonst keiner die Probleme hat, ist schon merkwürdig. Oder bin ich etwa komplett verkehrt in diesem Unterforum?!

[Navigator]

...nein bist du nicht. Gestern habe ich wegen wegen leichter Freezes beim Plotaufbau auch Plotfork aktiviert und nun auch eine Unknown Message vom CUL im Log. Diese Meldung kannte ich bisher gar nicht.

[franky08]

In der FHEMWEB.pm wurde vorgestern plotfork wieder auf 0 gesetzt da es massiv Probleme mit z.B. DbLog gab.

Man sollte mit dem Wort Fehler vorsichtig umgehen, da es Entwickler automatisch in schlechte Laune versetzt.

Die Ursache des Problems mAn ist, dass neuerdings in FHEMWEB plotfork dann greift, falls das Attribut gesetzt ist (auch bei 0, was vorher nicht der Fall gewesen ist, und was vmtl. in deiner Konfiguration der Fall ist).
Nachdem (im neuerdings geforkten Prozess) das Plot erstellt ist, beendet sich das Kindprozess, und die DB-Bibliothek ist der Ansicht, dass die im Kind vom Papa geerbte DB-Verbindung auch im Server zuzumachen ist. Papa-FHEM kann danach nicht mehr mit der DB kommunizieren. Das ein Restaurieren der SVG.pm das Problem behebt, liegt daran, dass mit dem alten SVG.pm plotfork deaktiviert ist, da das Modul sich nicht mehr als "FORKABLE" bewirbt.

Ich habe erstmal das alte plotfork-Verhalten in FHEMWEB restauriert: "attr WEB plotfork 0" schaltet plotfork aus. Man koennte ueberlegen im Kindprozess die Db-Verbindung auf InactiveDestroy zu setzen, das muss aber von jemandem mit DbLog getestet werden, bevor ich es einbaue.

VG
Frank

[Navigator]

Danke für den Hinweis.