[gelöst] CUL "unknown message EOB" [edit] und das plotfork-Problem ...

[Pfriemler]

Moin,
gestern abend mal wieder ein Update von FHEM gemacht, auch 00_CUL.pm wurde erneuert. Knapp 10 Minuten nach dem Neustart kam die erste Meldung

Code Auswählen Erweitern

2015.03.19 22:16:58 2: CUL1: unknown message EOB
nach einem Neustart heute morgen spielt er endgültig verrückt ...

Code Auswählen Erweitern

2015.03.20 09:15:52 2: CUL1: unknown message EOB
2015.03.20 09:17:15 2: CUL1: unknown message 0004466F
2015.03.20 09:17:15 2: CUL1: unknown message ? (0004466F is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2015.03.20 09:17:16 2: CUL1: unknown message ? (? (0004466F is un V W X e T47190069A609 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2015.03.20 09:18:18 2: CUL1: unknown message ? (? (? (0004466F ifK41275233E0 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2015.03.20 09:19:10 2: CUL1: unknown message ? (? (? (? (0004466F A Z E G M K U YT471900A60007 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x

Anyone else?
Ich spiel jetzt erst mal ein Backup ein und sehe dann weiter ...

[rudolfkoenig]

Der Geraetetreiber hat fuer die Verbindung zum CUL (warum auch immer) echo aktiviert, d.h. alles was culfw meldet, kriegt er umgehend wieder zurueck.
Dafuer ist ziemlich sicher keine Aenderung in FHEM verantwortlich, und an dieser Stelle wurde seit laengerem nichts gedreht. Ein Neustart allerdings koennte helfen.

[Pfriemler]

Hm ... "EOB" steht m.W. für Kommunikationsprobleme mit externen Devices - hier könnte evtl. auch eine Änderung in der FHT-Kommunikation das Problem sein. Ich nutze über den SlowRF nur FHT, einen KS300 und ein Anzeigedisplay, alles lief seit Wochen störungsfrei. Ich habe gestern nur ein paar nicht-CUL-bezogene Altlasten (Residents) entsorgt und einen Bluetooth-Stick (re)aktiviert. Der ist inzwischen wieder weg, und Neustarts, inkl. Strom, habe ich nun wirklich genug gemacht.
00_CUL.pm ist wirklich nicht neu. Ich mache gerade einen Vergleich.

Der Geraetetreiber hat fuer die Verbindung zum CUL (warum auch immer) echo aktiviert, d.h. alles was culfw meldet, kriegt er umgehend wieder zurueck.

Woran sieht man das und wie macht man es rückgängig?

[Pfriemler]

So, hab was gefunden. Genau sein: Es war natürlich nicht die einzige Änderung.
attr WEB plotfork 1 !

Diese Änderung hatte ich bereits vorher gemacht, sie blieb aber ohne Wirkung. Erst als ich für das Anstecken des Bluetoothsticks (im Zusammenhang mit dem Update) den Raspi stromlos machte, ging der Zauber los. In meinem "Residents"-Room gibt einen Plot ... 

http://forum.fhem.de/index.php/topic,13224.msg181280.html#msg181280 hat mich auf den richtigen Weg gebracht. Alles, was dort steht und darunter, kann ich prima nachvollziehen, am monierten Verhalten hat sich leider nichts geändert.

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.

100% nachvollzogen.

Schade, plotfork hat meine Diagramme so schön schnell gemacht.

plotfork auf 1 lassen, nach jedem Reboot eine Seite mit Plot aufrufen und dort set CUL1 raw B00 absetzen? Händisch ist mir das zu aufwändig, kann man es automatisieren - oder ist eine endgültige Lösung in Sicht? Oder habe ich wieder was übersehen?

[rudolfkoenig]

Ich habe FHEMWEB geaendert, damit es die neue (vom Blocking.pm ausgeliehene) fhemFork verwendet, weiterhin wird POSIX::exit statt exit aufgerufen. Koennt ihr bitte testen, ob das hilft?
Falls es nicht bekannt sein sollte: SVN ab sofort, update erst ab morgen.

[Pfriemler]

Ich habe FHEMWEB geaendert, damit es die neue (vom Blocking.pm ausgeliehene) fhemFork verwendet, weiterhin wird POSIX::exit statt exit aufgerufen. Koennt ihr bitte testen, ob das hilft?

Super, mach ich gerne, aber erst ab Mittwoch, so lange bin ich unterwegs und remote habe ich da keine Eingriffsmöglichkeiten, wenn das System aus anderen Gründen baden geht, dann bitte wenn ich dabei bin  . Aber vielen Dank schon mal. Vielleicht ist ja jemand anderes schneller.

[Pfriemler]

So, endlich. Seit gestern abend läuft das Update. Keine Probs.
Eben Plotfork eingeschaltet und SVGs aufgerufen. Wie im zitierten anderen Thread dabei beobachtet ob der fett markierte Teil sich ändert (von -echo in echo).

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 = 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

Nix. Die SVGs flutschen wie gewünscht. Morgen melde ich mich nochmal, ob der CUL sich wieder beschwert. Aber ich rechne nicht mehr damit.

DICKES DANKE!!!

[Pfriemler]

Nachtrag. Auf dem CUL ist Ruhe eingekehrt. Problem gelöst!

geht nich Gips nich ...