Problem beim Initialisieren von RFXtrx433 - no character read

Begonnen von vbs, 07 März 2014, 19:08:52

Vorheriges Thema - Nächstes Thema

vbs

Hi Ihr,

ich hab ein kleines Problem, meinen RFXtrx433 zu initialisieren. Bei jedem 'define' kommt folgende Ausgabe:

2014.03.07 19:02:43 3: Opening TRX0 device COM4
2014.03.07 19:02:43 3: Setting TRX0 baudrate to 38400
2014.03.07 19:02:43 3: TRX0 device opened
2014.03.07 19:02:43 1: TRX: Initialization Error: No character read
2014.03.07 19:02:43 1: Cannot init COM4, ignoring it


Das define sieht so aus:
define TRX0 TRX COM4@38400

Wenn ich das Gerät mit 'noinit' anlege, dann kommt kein Fehler und das Ding funktioniert auch einwandfrei.

Firmware auf dem RFXtrx433 ist die 71.

Jemand eine Idee? Danke!

Willi

Das hatte schon jemand mal beim Einsatz unter Windows gepostet. Ich vermute, dass unter Windows sich perl bzgl. der Schnittstellen anders als Linux verhält. Oder es liegt an der Perl-Version.

Mir ist nicht klar, ob meine Treiber unter Windows nur mit noinit funktionieren oder ob es an bestimmten Konfigurationen (Windows-Version und/oder Perl-Version) liegt. Es gibt m.E. wenige, die FHEM mit Windows nutzen. Für mich ein Wunder, dass FHEM überhaupt unter Windows funktioniert.

Du kannst RFXtrx bedenkenlos auch mit noinit benutzen.

Ich setze aus Glaubensgründen kein Windows ein und kann das leider nicht testen.
Wenn Du möchtest, könntest Du das debuggen, in dem Du in in 45_TRX.pm die entsprechenden Debugausgaben beim Init einsetzt.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

vbs

Hallo Willi,

ja es ist tatsächlich Windows. Bot sich bei mir so an, ich sowieso einen kleinen Windows-Rechner dauerhaft laufen habe. Mal schauen, vielleicht kauf ich irgendwann nochmal einen Raspberry als FHEM-Server. Wenn du sagst, dass es auch mit noinit problemlos funktionieren sollte, ist das aber natürlich erstmal ok für mich. Vielleicht schaue ich mir tatsächlich mal an, was da schief läuft unter Windows. Einfach aus Interesse. In dem Fall würde ich natürlich nochmal Rückmeldung geben...

Vielen Dank übrigens für deine Arbeit und den Support!

vbs

Also ich hab da mal reingeschaut und ich denke, ich weiß zumindest woran es liegt:

Aus dem TRX DoInit:
  # Get Status
  $init = pack('H*', "0D00000102000000000000000000");
  DevIo_SimpleWrite($hash, $init, 0);
  $buf = DevIo_TimeoutRead($hash, 0.5);


Dort ruft er DevIo_TimeoutRead auf. Unter Windows scheint das jedoch überhaupt nicht zu funktionieren. Die Funktion kehrt sofort zurück ohne zu blockieren. Wenn ich die Stelle durch ein SimpleRead ersetze, dann klappt es. Jedoch muss man dann mit sleep 1 Sekunde warten vor dem Aufruf.

DevIo_TimeoutRead:
sub
DevIo_TimeoutRead($$)
{
  my ($hash, $timeout) = @_;

  my $answer = "";
  for(;;) {
    my $rin = "";
    vec($rin, $hash->{FD}, 1) = 1;
    my $nfound = select($rin, undef, undef, $timeout);
    last if($nfound <= 0);
    my $r = DevIo_DoSimpleRead($hash);
    last if(!defined($r));
    $answer .= $r;
  }
  return $answer;
}


Er macht dort ein select auf den File Descriptor $hash->{FD}. Unter Windows ist der jedoch nicht definiert. Daher kehrt das select sofort mit nfound=-1 zurück und er springt ohne Daten aus der Funktion.

Aus DevIO_OpenDev:
$hash->{USBDev} = $po;
    if( $^O =~ /Win/ ) {
      $readyfnlist{"$name.$dev"} = $hash;
    } else {
      $hash->{FD} = $po->FILENO;
      delete($readyfnlist{"$name.$dev"});
      $selectlist{"$name.$dev"} = $hash;
    }


Und der File Descriptor ist nicht belegt, weil $hash->{FD} unter Windows beim Öffnen nicht belegt wird. Ich vermute, so ein reiner File Descriptor liegt unter Windows auch gar nicht vor. Ich hab auf die schnelle auch nicht rausfinden können, wie man Win32::SerialPort dazu bringen könnte, selbst ein blockierendes Read mit Timeout auszuführen.
Ist in der Tat erstaunlich das fhem unter Windows läuft, wenn DevIo_TimeoutRead generell nicht zu funktionieren scheint. Benutzt das tatsächlich sonst niemand?

In welches andere Forum kann ich das denn posten, so dass sich das evtl. mal ein Dev anschaut? Vielleicht sollte man zumindest eine Log Ausgabe einbauen a la "ERROR: Aufgerufene Funktion steht unter Windows nicht zur Verfügung".

Werde dann wohl erstmal bei der noinit-Variante bleiben :)