Ich habe heute einen rfxtrx433 erhalten, auf Firmware 74 geflasht und versucht ihn in FHEM in Betrieb zu nehmen. Unter RFXmngr funktioniert er und zeigt meine TFA-Sensoren (Temp,Wind,Regen) an. Als Initialisierungsstring wird '0d01000102534a00040a01010000' angezeigt.
Unter FHEM erhalte ich im Protokoll die Fehlermeldung
TRX: Initialization Error hexline='0d01000102534a00040a01010000'
Außerdem wird ein undefined $char in 45_TRX.pm in Zeile 246 angemeckert.
Wenn ich den kompletten elseif-Zweig
}
# elsif ($buf !~ m/\x0d\x01\x00.........../) {
# my $hexline = unpack('H*', $buf);
# Log3 $name, 1, "TRX: Initialization Error hexline='$hexline'";
# return "TRX: Initialization Error %name expected char=0x2c, but char=$char received.";
# }
else {
auskommentiere, läuft die Initialisierung und die TFA-Sensoren werden in FHEM angezeigt und gelesen.
Ich steige nicht dahinter, woran es liegen könnte.
Jemand eine Idee?
Habe noch folgendes herausgefunden:
Es liegt offenbar am regulären Ausdruck im Suchstring. Der Initialisierungsstring des RFXtrx enthält im 7.Byte "0x0a". Dies wird vom "." im regulären Ausdruck aber nicht abgedeckt. Zitat aus einer Doku zu regulären Ausdrücken:
"•das Element . sucht nach einem beliebigen Zeichen, das kein "\n"-Zeichen ist (die genaue Treffermenge hängt von den verwendeten Modifiern ab). "
Eine Änderung des Programmcodes in
.....
$buf = DevIo_TimeoutRead($hash, 0.1);
my $hexline = unpack('H*', $buf);
if (! $buf) {
Log3 $name, 1, "TRX: Initialization Error: No character read";
return "TRX: Initialization Error $name: no char read";
}
# elsif ($buf !~ m/\x0d\x01\x00.........../) {
elsif ($hexline !~ m/0d0100....................../) {
.....
behebt das Problem.
Allerdings habe ich noch das Problem, das die Auswertung des Initialisierungsstring noch nicht funktioniert:
Die Programmänderung:
....
# Analyse result and display it:
# if ($buf =~ m/\x0d\x01\x00(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)/) {
if ($hexline =~ m/0d0100(..)(..)(..)(..)(..)(..)(..)(..)(..)(..)(..)/) {
my $status = "";
....
liefert im Protokoll:
2014.05.14 14:18:17 3: Opening RFXCOMUSB device /dev/ttyUSB0
2014.05.14 14:18:17 3: Setting RFXCOMUSB baudrate to 38400
2014.05.14 14:18:17 3: RFXCOMUSB device opened
2014.05.14 14:18:18 1: TRX: Init OK
2014.05.14 14:18:18 4: TRX: Init status hexline='0d01000102534a00040a01010000'
2014.05.14 14:18:18 1: TRX: Init status: 'unknown Mhz, firmware=52, protocols enabled: RFU5 RFU4 ProGuard FS20 OREGON KOPPLA '
Ok. Du bist wohl bisher der einzige von viele Usern, da Du genau die Protokolle in RFXmngr ausgewählt hast, dass jetzt im Init-String ein 0a steht. Deshalb ist es bisher nicht aufgefallen. Hättest Du andere Protokolle ausgewählt, wäre das nicht aufgefallen. Bei meinen Protokollen läuft es auch ohne Probleme:
Zitat2014.05.16 18:58:13 3: Opening TRX_0 device /dev/ttyUSB0
2014.05.16 18:58:13 3: Setting TRX_0 baudrate to 38400
2014.05.16 18:58:13 3: TRX_0 device opened
2014.05.16 18:58:14 1: TRX: Init OK
2014.05.16 18:58:14 1: TRX: Init status: '433.92MHz transceiver, firmware=174, protocols enabled: RFU4 LaCrosse Hideki OREGON ARC X10 '
Oder Deine Perl-Version verhält sich anders als bei anderen Usern und dort matcht . auch auf 0x0a.
Deine Patches sehen auf den ersten Blick gut aus. Danke. Ich schau mir die mal näher an, teste und melde mich dann. Dann kann ich auch gleich die übrigen Protokolle bei der Ausgabe des Init-Strings einbauen.
Vielen Dank noch einmal.
Ich habe entsprechend gefixed (auch per unpack). Sollte jetzt alles funktionieren.
Ist im SVN und morgen per update verfügbar.