Seltsames Verhalten FHZ1000

[loberg]

Hallo,

ich habe auf einer neuen Festplatte Ubuntu 8.04 installiert und danach
einen neuen Kernel (2.6.24-7) gebaut.
Nach Installation von FHEM 4.3 und erstellen einer rudimentären
fhz1000.cfg bekomme ich folgende Ausgabe beim Drücker einer Taste auf
der Fernbedienung:

2008.07.22 22:50:21 3: FHZ opened FHZ device /dev/ttyUSB0
2008.07.22 22:50:22 2: FHZ get FHZ init2
2008.07.22 22:50:22 3: FHZ init2 => 1f0278071c1780
2008.07.22 22:50:22 2: FHZ get FHZ serial
2008.07.22 22:50:22 3: FHZ serial => 136e4934
2008.07.22 22:50:22 2: FHZ set FHZ initHMS
2008.07.22 22:50:22 2: FHZ set FHZ initFS20
2008.07.22 22:50:23 2: FHZ set FHZ time
2008.07.22 22:50:23 2: FHZ set FHZ raw 04 01010100010000
2008.07.22 22:50:23 0: Server started (version 4.3 from 2008-07-12
($Id: fhem.pl,v 1.46 2008/07/11 07:26:19 rudolfkoenig Exp $), pid
5327)
2008.07.22 22:52:58 4: Bad CRC message, skipping it (Bogus message
follows)
2008.07.22 22:52:58 4: Bad CRC message, skipping it (Bogus message
follows)

Nach beenden des Prozesses fhem.pl rufe ich dann das Test-Script
elv.pl auf:

Sending ...8106c98602011f64
Got:
810c00ae0909a001173a0000aa00810c00d00909a001173a41006922810c00d80909a001173a4b006722810c000b0909a001173a7e006722
[0]
Sending ...810804afc90184570208 Result: 10
Got: 810bc99601021f0278075c [1]
Got: 1780810fc98d01028401080780136e [2]
Got: 49346216 [3]
Got: 810b04550101a0 [4]
Got: 014270000000 [5]
Got: 810b04550101a0 [6]
Got: 014270000000 [7]

Jetzt erst wird der Tastendruck auf der Fernbedienung korrekt erkannt:

2008.07.22 23:07:35 3: FHZ opened FHZ device /dev/ttyUSB0
2008.07.22 23:07:35 2: FHZ get FHZ init2
2008.07.22 23:07:36 3: FHZ init2 => 1f0278071c1780
2008.07.22 23:07:36 2: FHZ get FHZ serial
2008.07.22 23:07:36 3: FHZ serial => 136e4934
2008.07.22 23:07:36 2: FHZ set FHZ initHMS
2008.07.22 23:07:36 2: FHZ set FHZ initFS20
2008.07.22 23:07:36 2: FHZ set FHZ time
2008.07.22 23:07:37 2: FHZ set FHZ raw 04 01010100010000
2008.07.22 23:07:37 0: Server started (version 4.3 from 2008-07-12
($Id: fhem.pl,v 1.46 2008/07/11 07:26:19 rudolfkoenig Exp $), pid
6320)
2008.07.22 23:07:44 3: FS20 Unknown device 4270 (21132411), Button 00
(1111) Code 00 (off), please define it

Natürlich könnte ich jetzt vor jedem Start von fhem.pl das Test-Skript
elv.pl einmal starten damit fhem auch funktioniert... Aber es muss
doch einen Grund geben, warum fhem nicht auf Anhieb einwandfrei
funktioniert.

Hat jemand eine Idee, woran das liegen könnte?
Liegt es eventuell an der neuen 4.3'er Version?

[Rudolf Koenig]

> ich habe auf einer neuen Festplatte Ubuntu 8.04 installiert und danach
> einen neuen Kernel (2.6.24-7) gebaut.
> Nach Installation von FHEM 4.3 und erstellen einer rudimentären
> fhz1000.cfg bekomme ich folgende Ausgabe beim Drücker einer Taste auf
> der Fernbedienung:

Das klingt so als ob es vorher mit einem anderen OS/fhem Version es
schon geklappt haette.
Stimmt das?

> 2008.07.22 22:52:58 4: Bad CRC message, skipping it (Bogus message
> follows)

Das ist das typische Verhalten, wenn die USB/Serielle Schnittstelle
ein paar Bits klaut (das 7-te?)
Kannst Du mit stty -a < /dev/ttyUSB0 das pruefen, d.h. die Einstellung
vor und nach elv.pl vergleichen. Alternativ bleibt das "falsche"
Initialisierungs-String.

Gruss,
Rudi

[loberg]

> Das klingt so als ob es vorher mit einem anderen OS/fhem Version es
> schon geklappt haette.
> Stimmt das?

Sorry, hatte ich nicht geschrieben. Ich nutzte FHEM schon recht lange
und auf meinem alten Rechner lief es einwandfrei. Hatte aber noch 'ne
ganz alte FHEM Version und musste jetzt meine Config erst einmal auf
die neue 4.3 anpassen... Bis ich dann irgendwann gemerkt habe, dass
etwas "anderes" nicht funzt.

> Das ist das typische Verhalten, wenn die USB/Serielle Schnittstelle
> ein paar Bits klaut (das 7-te?)
> Kannst Du mit stty -a < /dev/ttyUSB0 das pruefen, d.h. die Einstellung
> vor und nach elv.pl vergleichen. Alternativ bleibt das "falsche"
> Initialisierungs-String.

stty (bevor ich elv.pl ausgeführt habe):
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

stty (nach elv.pl und fhem funktioniert):
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

Als Unterschiede erkenne ich eine ganze Menge an Optionen und
Parametern. Ausschlaggebend könnte wohl 'ixon' sein, welches in der
funktionierenden Situation deaktiviert ist.
Wenn ich diesen Parameter manuell setze (stty -F /dev/ttyUSB0 -ixon)
ändert aber leider trotzdem nichts an dem Verhalten ;-(

Wenn ich mir die elv.pl angucke (ich habe nur leider keine Ahnung von
Perl), kann ich erkennen das aber wohl nur die klassischen Parameter
9600,N,8,1,none gesetzt werden und die sind ja vorher wie hinterher
gleich.

By the way: Rudi, tausend Dank dafür das Du uns fhem.pl gebracht hast.
Ich hatte lange Zeit eine Windows Kiste am laufen nur wegen dem ELV
kram. Danke, Danke, Danke!

[Rudolf Koenig]

Hmmm.

Hab auf einem "out-of-the-box" Ubuntu 8.04 Rechner libdevice-
serialport-perl installiert (aptitude install), ein FHZ1000
angeschlossen, und fhem 4.3 ausgepackt. Rechte von /dev/ttyUSB0 auf
666 geaendert, dann stty -a < /dev/ttyUSB0 ausgefuehrt: entspricht
deinem Version "vor elv.pl", mit ixon. fhem mit einem minimalen config
gestartet, und ein FS20 Knopf gedrueckt. Ich bekomme die Meldung:

FS20 Unknown device XXXX (yyy), Button 02 (1113) Code 00 (off), please
define it
Triggering UNDEFINED

Wenn man waehrend fhem laeuft, stty -a < /dev/ttyUSB0 ausfuehrt, dann
kommt die "richtige" Einstellung, mit -ixon.
Will sagen: bei mir tut es. Kannst Du das stty bei dir auch waehrend
des fhem.pl laufs pruefen? Aber inzwichen bin ich der Meinung, es
liegt an was anderes...

Gruss,
Rudi

[loberg]

Hallo Rudi,

ich habe die von Dir genannten Dinge auch noch einmal geprüft... Alles
OK, gleiches Ergebnis.

Jetzt habe ich einfach mal die Init-Sequenzen aus der elv.pl in die
fhem.pl aufgenommen und nun funktioniert es bei jedem Neustart.

Ich weiß natürlich immer noch nicht in welchem komischen Status meine
Schnittstelle nach einem Neustart ist und warum.. Aber mit dieser
Initialisierung funktioniert es jetzt einwandfrei. Vielleicht liegt es
ja auch an einer der anderen Komponenten in meinem Rechner (Lirc, zwei
TV-Karten, USB IR-Tastatur usw).

Eventuell könntest Du ja eine solche grundlegende Schnittstellen
Initialisierung auch in Dein fhem.pl einbauen?

Vielen Dank für den Support!

Grüße
loberg

[Rudolf Koenig]

> Eventuell könntest Du  ja eine solche grundlegende Schnittstellen
> Initialisierung auch in Dein fhem.pl einbauen?

Welche Initialisierung meinst Du? Rs232 (Baudrate, etc) oder die
FHZ1000 Init-Bytes? fhem.pl sollte in beiden Faellen einen
aufwendigeren Initialisierungs-Sequenz haben als elv.pl, aber
"aufwendig" ist manchmal schlechter. Kann in elv.pl nicht nachschauen,
Tosti's Seite streikt gerade, die Festplatte ist wohl vollgelaufen :-
p.

Gruss,
Rudi

[loberg]

> Welche Initialisierung meinst Du? Rs232 (Baudrate, etc) oder die
> FHZ1000 Init-Bytes? fhem.pl sollte in beiden Faellen einen
> aufwendigeren Initialisierungs-Sequenz haben als elv.pl, aber
> "aufwendig" ist manchmal schlechter. Kann in elv.pl nicht nachschauen,

Ich habe einfach in der fhem.pl ab Zeile 145 folgendes aus der elv.pl
eingefügt:

my $DEV = '/dev/ttyUSB0';
use Device::SerialPort;
my $ELV = Device::SerialPort->new($DEV) || die "Can't open $DEV: $!";
$ELV->reset_error();
$ELV->baudrate(9600);
$ELV->databits(8);
$ELV->parity('none');
$ELV->stopbits(1);
$ELV->handshake('none');

Damit geht's jetzt bei jedem Neustart der Rechners auch ohne elv.pl zu
starten.

[td]

Hervorragend!
Ich hatte genau dasselbe Problem (Suse 10.3) und habe es damit lösen
können.
Evtl. kann das per se in fhem.pl eingebaut werden?

Gruß
td

[svenk]

Hi,

bei mir läuft fhem.pl (4.4) auf einer Buffallo Lifestation (auf nem
Debian). Nach einem Reboot erschien auch bei mir die Meldung

...
2008.09.21 20:02:54 0: Server started (version 4.4 from 2008-08-04
($Id: fhem.pl,v 1.51 2008/08/04 14:34:53 rudolfkoenig Exp $), pid
28609)
2008.09.21 20:03:07 5: FHZ/RAW: 810c (Unparsed: )
2008.09.21 20:04:07 5: FHZ/RAW: 810b (Unparsed: 810c)
2008.09.21 20:04:07 5: FHZ/RAW: 39830983013e4465ff43810c (Unparsed:
810c810b)
2008.09.21 20:04:07 4: Bad CRC message, skipping it (Bogus message
follows)
2008.09.21 20:04:07 4: Bad CRC message, skipping it (Bogus message
follows)
2008.09.21 20:04:07 5: Bogus message received, skipping to start
character
2008.09.21 20:05:05 5: FHZ/RAW: 190909a0013e447e0067ff810c (Unparsed:
810c)
...

und keine Nutzdaten mehr.

Einiges googeln hat mich zu diesem Thread geführt.

Zwar ist das nicht die feine englische Art, aber funktionieren tuts.
Nach dem Einfügen und Neustarten des Servers kommen keine Bad CRC
messages mehr, aber wieder Nutzdaten.

Hiermit schliesse ich mich dem Wunsch von td an, dass diese
Funktionalität auch in fhem.pl eingebaut wird. (also ohne hartkodierte
devices und so ... ;)

grüsse,
sven

[Rudolf Koenig]

> Hiermit schliesse ich mich dem Wunsch von td an, dass diese
> Funktionalität auch in fhem.pl eingebaut wird. (also ohne hartkodierte
> devices und so ... ;)

Die Geschichte: der Workaround Code steht auch in 00_FHZ.pm so drin,
weil ich damit angefangen habe. Aber danach wollten Leute fhem auf
komischen (d.h.: kaputten :-) Distributionen zum laufen kriegen, und
so kamen die weiteren Einstellungen dazu. Diese stoeren nun wiederum
andere Distros.

Ich habe nun diese zusaetzlichen stty's optional gemacht, wenn man die
weiterhin will, dann muss man FHZ folgendermassen definieren:

define MyFHZ FHZ /dev/ttyUSB0 strangetty

Da lobe ich mein 7-bit CUL Protokoll. :-). Btw. der CUL Firmware macht
Fortschritte (wie man es im CVS sehen kann), und einem wird mulmig,
wenn man die als "sicher" geltende Protokolle (z.Bsp Hoermann) zu
Gesicht bekommt. Mein EM1010PC ist jedenfalls ueberfluessig geworden,
der FHZ1300 folgt sobald wir FHT auch senden koennen.

Gruss,
Rudi

[Sven Kloppenburg]

Moin,

Am 22.09.2008 um 00:00 schrieb Rudolf Koenig:

>
>> Hiermit schliesse ich mich dem Wunsch von td an, dass diese
>> Funktionalität auch in fhem.pl eingebaut wird. (also ohne
>> hartkodierte
>> devices und so ... ;)
>
> Die Geschichte: der Workaround Code steht auch in 00_FHZ.pm so drin,
> weil ich damit angefangen habe. Aber danach wollten Leute fhem auf
> komischen (d.h.: kaputten :-) Distributionen zum laufen kriegen, und
> so kamen die weiteren Einstellungen dazu. Diese stoeren nun wiederum
> andere Distros.
>
> Ich habe nun diese zusaetzlichen stty's optional gemacht, wenn man die
> weiterhin will, dann muss man FHZ folgendermassen definieren:
>
> define MyFHZ FHZ /dev/ttyUSB0 strangetty
>

Um in den Genuss dieser Funktionalität zu kommen, muss ich vermutlich
den CVS-Head nehmen, richtig?

Und mit

LS-GL:~/fhem# cat /etc/debian_version
lenny/sid
LS-GL:~/fhem# uname -a
Linux LS-GL 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 armv5tel
GNU/Linux

will ich dann kein strangetty haben. Richtig?

> Da lobe ich mein 7-bit CUL Protokoll. :-). Btw. der CUL Firmware macht
> Fortschritte (wie man es im CVS sehen kann), und einem wird mulmig,
> wenn man die als "sicher" geltende Protokolle (z.Bsp Hoermann) zu
> Gesicht bekommt. Mein EM1010PC ist jedenfalls ueberfluessig geworden,
> der FHZ1300 folgt sobald wir FHT auch senden koennen.

Das ist dann aber für die Selbstbauhardware. Für mich ist das dann
leider zu spät, weil ich die FHZ1300PC ja nun schon angeschafft habe.

mit freundlichen Grüßen,
Sven Kloppenburg

[Rudolf Koenig]

> Um in den Genuss dieser Funktionalität zu kommen, muss ich vermutlich  
> den CVS-Head nehmen, richtig?

Ja.

> Und mit
[...]

> will ich dann kein strangetty haben. Richtig?

Ich hoffe es, wissen tu ich es aber nicht. Ich habe im Moment das
Gefuehl, dass es eher an dem Prozessor als an dem Distro haengt,
sicher bin ich nicht. Ein Benutzer auf einem Buffalo hat z.Zt auch
noch Probleme, sogar mit dem strangetty Option aber angeblich nicht
mit dem Hack. Das verstehe ich gar nicht, und ich habe so meine
Schwierigkeiten remote zu debuggen, ausserdem im Moment etwas weniger
Zeit. Kann jemand mithelfen?

> Das ist dann aber für die Selbstbauhardware. Für mich ist das dann  
> leider zu spät, weil ich die FHZ1300PC ja nun schon angeschafft habe.

Naja, wie mans nimmt. Man sagt auch, mit dem Essen kommt das Appetit,
bei mir war das jedenfalls so. Es ist schon faszinierend, wieviele
Protokolle man mit einem Geraet emfpangen kann (FS20/FHT/S300/EM/...),
und wieviel mehr man mit weitere Bastelei empfangen koennte. Im Moment
ist der Firmware aber noch beim Reifen.