Nicht erreichbarer CUNO verhindert Start von FHEM

Begonnen von Prof. Dr. Peter Henning, 04 Januar 2013, 07:11:26

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Falls ein CUNO über das Netzwerk nicht erreichbar ist (_bevor_ der STATE auf "disconnected" gesetzt wird), steigt beim Start von FHEM die subroutine CUL_Ready aus.
Das führt zu einem Abbruch des FHEM-Starts mit der Meldung

Can't call method "status" on an undefined value at /usr/share/fhem/FHEM/00_CUL.pm line 952.

Klar - weil in dieser Zeile 952 steht
my ($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags) = $po->status;
und $po nicht definiert ist.

Könnte man vielleicht bei Gelegenheit abfangen.

LG

pah

rudolfkoenig

Ich habe es umgebaut, dass es auch mit einem undefinierten $po zurechtkommen soll, aber ich konnte es weder testen noch nachvollziehen, da ich keine Windows-Testumgebung fuer fhem habe. Unter Linux/OSX wird dieser Code nicht angesprungen, soweit ich es sehe.

Prof. Dr. Peter Henning

Doch, genau das passierte auf meinem Raspberry !
Und der läuft wirklich nicht unter Windows, ich schwöre es beim Grab meiner Großmutter.

LG

pah

rudolfkoenig

Dann wuesste ich gerne, wie ich es reproduzieren soll. Weder mit eine nicht existierende IP-Adresse, noch mit einem falschen port konnte ich das nachstellen.

Prof. Dr. Peter Henning

Hmmm.

Das sind auch zwei unterschiedliche paar Schuhe: Bei einer falschen IP oder einem falschen Port gibt es gar keine Verbindung zum CUNO. In dem speziellen Fall kämpfe ich aber seit Monaten damit, dass in der Firmware Version 1.46 bei meinem CUNO irgendetwas schief läuft, der TCP/IP-Stack regelmäßig gigantische Verzögerungen produziert. Das heißt: die telnet-Verbindung wird aufgemacht, der CUNO liefert aber keine Response. Und genau dann kommt das Programm an dieser Stelle an.

LG

pah

rudolfkoenig

Kriege ich aber auch so noch nicht reproduziert:

define CUL CUL heise.de:80 5432
...
2013.01.04 13:31:34.438 3: CUL device opened
2013.01.04 13:31:43.577 1: Cannot init heise.de:80, ignoring it

Prof. Dr. Peter Henning

Hmm, das wird immer wilder.

Die zuerst gepostete Fehlermeldung kommt ungefähr bei jedem 4. FHEM-Start. Dazwischen gibt es immer wieder solche, bei denen der "cannot init" Fehler auftritt.

Ich durchblicke das 00_CUL.pm noch nicht ganz: Wo wird die Fehlermeldung mit dem "cannot init" ausgelöst ?

LG

pah

rudolfkoenig

DevIo.pm/DevIo_OpenDev ruft als initfn CUL_DoInit (aus 00_CUL.pm) auf. Falls dieser kein undef zurueckliefert, dann kommt es zu "Cannot init $dev, ignoring it". Die konkrete Fehlermeldung vom CUL_DoInit wird elegant unter dem Teppich gekehrt :)

Lorenz

Hallo zusammen,

ich hänge mich hier mal zum Thema "cannot init" dran. Ich schreibe an einem ein Modul für die Kommunikation mit einer Alarmanlage auf Basis von 00_TAHR.pm. Fhem läuft unter debian auf auf einem Dockstar. Zur Kommunikation wird ein USBtoserial Adapter genutzt. Die Schnittstelle wird dabei über DevIo angesprochen. ttyUSB0 ist auf ttyS4 gemappt. Beim Start und auch beim Restart wird Cannot init /dev/ttyUSB0, ignoring it ausgegeben. Dann hilft manchmal "Save fhem.cfg". Immer hilft das Ändern des devices in der fhem.cfg auf die gemappte, also in diesem Fall von ttyUSB0 -> ttyS4. Beim nächsten Start umgekehrt. Das ist gerade in der Testphase "unpraktisch" und ich verstehe das nicht.
In 00_TAHR steht
sub TAHR_Ready($)
{
  my ($hash) = @_;
  return DevIo_OpenDev($hash, 1, undef)
...
Damit sollte undef an DevIo übergeben werden.

Was kann ich tun, um das Problem in den Griff zu kriegen?

Bei der Gelegenheit noch eine Frage: Ich musste in DevIo die parity auf even setzen.
Wie kann ich verhindern, dass das bei einem Update überschrieben wird.
Kann man das mit einer Parameterübergabe erledigen?
Gesehen habe ich aber bislang nur die Baudrate.

LG

Lorenz
. . . . . .
Fhem auf NUC7i3BNH, Raspberry Pi B und B+, Raspberry Pi 2 B, Peripherie: FB7490, 1-Wire, Homematic, FS20, Lampen, Briefkasten, Klingel, Sonos, GardenaSmart, Unifi, Gaszähler an GPIO, Stromzähler EFR SGM-C4, Heizung Buderus GBH 172, Alarmanlage EMA und BMA von Bosch

rudolfkoenig

> ich hänge mich hier mal zum Thema "cannot init" dran

Falsch.

> Beim Start und auch beim Restart wird Cannot init /dev/ttyUSB0, ignoring it ausgegeben.

Vermutlich ist etwas im spezifizierten initfn schiefgelaufen.

>  ttyUSB0 ist auf ttyS4 gemappt

Von wem? Falls ein Programm ttyUSB0 auf ttyS4 mapped, dann sollte fhem die Finger vom ttyUSB0 lassen.
Normalerweise sind aber "USBtoserial Adapter" in Hardware gegossen, und haben mit ttyS* nichts zu tun.

> Ich musste in DevIo die parity auf even setzen.

Kann man im initfn (Parameter zu DevIo_OpenDev) tun.



Lorenz


>> ich hänge mich hier mal zum Thema "cannot init" dran

>Falsch.

Sorry.

>> Beim Start und auch beim Restart wird Cannot init /dev/ttyUSB0, ignoring it ausgegeben.

>Vermutlich ist etwas im spezifizierten initfn schiefgelaufen.

Was bedeutet das? Kann ich etwas daran ändern?

>> ttyUSB0 ist auf ttyS4 gemappt

>Von wem?

Nur vorübergehend von mir im System mit ln -s /dev/ttyUSB0 /dev/ttyS4, um das überhaupt halbwegs zum Laufen zu kriegen.
Und als workaround hat´s ja geholfen.

>Falls ein Programm ttyUSB0 auf ttyS4 mapped, dann sollte fhem die Finger vom ttyUSB0 lassen.
>Normalerweise sind aber "USBtoserial Adapter" in Hardware gegossen, und haben mit ttyS* nichts zu tun.

Soweit klar.

>> Ich musste in DevIo die parity auf even setzen.

>Kann man im initfn (Parameter zu DevIo_OpenDev) tun.

Schaue ich mir an.

LG
. . . . . .
Fhem auf NUC7i3BNH, Raspberry Pi B und B+, Raspberry Pi 2 B, Peripherie: FB7490, 1-Wire, Homematic, FS20, Lampen, Briefkasten, Klingel, Sonos, GardenaSmart, Unifi, Gaszähler an GPIO, Stromzähler EFR SGM-C4, Heizung Buderus GBH 172, Alarmanlage EMA und BMA von Bosch

Prof. Dr. Peter Henning

Es ist nicht üblich, USB-devices auf /dev/ttyS* zu mapen - das kann allerhand unerwünschte Nebenwirkungen haben. Besser des Folgende:

mit dmesg | grep -i usb

oder aus /var/log/messages

"alles über USB" ausgeben lassen. Beispiel für die erhaltenen Daten:

Nov 22 22:17:26 raspberrypi kernel: [   10.600041] ftdi_sio 1-1.3.1.2:1.0: FTDI USB Serial Device converter detected
2: FTDI USB Serial Device converter now attached to ttyUSB0
[    3.572009] usb 1-1.3.1.2: new full-speed USB device number 8 using dwc_otg
[    3.701033] usb 1-1.3.1.2: New USB device found, idVendor=0403, idProduct=6001
[    3.711652] usb 1-1.3.1.2: SerialNumber: FTFK8OHX

USB-1-Wire

Nov 22 22:17:26 raspberrypi kernel: [   11.174947] ftdi_sio 1-1.3.4.1:1.0: FTDI USB Serial Device converter detected
 FTDI USB Serial Device converter now attached to ttyUSB1
    4.032263] usb 1-1.3.4.1: new full-speed USB device number 10 using dwc_otg
[    4.139115] usb 1-1.3.4.1: New USB device found, idVendor=0403, idProduct=6001
[    4.150561] usb 1-1.3.4.1: SerialNumber: A900IEH8

Daraus ist zu ersehen, welche eindeutigen Seriennummern die beiden hier verwendeten FTDI-Devices haben.

Dann die Datei /lib/udev/rules.d/95-usb.rules erzeugen oder editieren. Mit den beiden Einträgen

/lib/udev/rules.d/95-usb.rules
# USB solar inverter interface
SUBSYSTEMS=="usb", ATTRS{serial}=="FTFK80HX", SYMLINK+="solar"
# USB 1-Wire interface
SUBSYSTEMS=="usb", ATTRS{serial}=="A900IEH8", SYMLINK+="owxdg"

wird dafür gesorgt, dass jedesmal beim Systemstart diese beiden USB-Devices auf /dev/solar und /dev/owxdg gemappt werden.

Das geht übrigens
- immer unter Linux, nicht nur auf dem RPi
- auch mit anderen Geräten, als USB-Serial Konvertern. Und empfiehlt sich IMMER, wenn man eine Anwendung (wie z.B. FHEM) auf GANZ BESTIMMTE Geräte zugreifen lassen möchte.

LG

pah

Lorenz

Der Tipp mit den SYMLINKS ist prima, das werde ich so einbauen.
Jetzt habe ich zuerst das Mapping entfernt und nutze nur USB0.
Nach einem shutdown restart kommt immer "Cannot init ..." ein save fhem.cfg beseitgt das Problem. Also war die Nutzung des anderen device überflüssig.

Nun habe ich in DevIo 2 LOGs eingesetzt:

my $ret;
  if($initfn) {
    Log 5, "initfn: $initfn"; #LG
       my $ret  = &$initfn($hash);
    Log 5, "ret: $ret"; #LG
    if($ret) {
      DevIo_CloseDev($hash);
      Log 1, "Cannot init $dev, ignoring it";
    }

Nach dem shutdown restart sieht das LOG so aus:

2013.01.14 16:32:31 3: Opening Alarm device /dev/ttyUSB0
2013.01.14 16:32:31 3: Setting Alarm baudrate to 9600
2013.01.14 16:32:31 3: Aalrm device opened
2013.01.14 16:32:31 5: initfn: TAHR_Poll
2013.01.14 16:32:33 5: SW: 1049014A16
2013.01.14 16:32:33 5: ret: 1358177555.78739
2013.01.14 16:32:34 1: Cannot init /dev/ttyUSB0, ignoring it

Nach dem save fhem.cfg:

2013.01.14 16:32:39 3: Opening Alarm device /dev/ttyUSB0
2013.01.14 16:32:39 3: Setting Alarm baudrate to 9600
2013.01.14 16:32:39 3: Alarm device opened
2013.01.14 16:32:39 5: initfn: TAHR_Poll
2013.01.14 16:32:41 5: SW: 1049014A16
2013.01.14 16:32:41 5: ret:

und alles ist gut.

Nach dem nächsten Restart stand in $ret:

2013.01.14 16:53:27 5: ret: 1358178809.45189

Mit meinen noch oberflächlichen Perl-Kenntnissen vermute ich, dass der Wert in $ret eine Zeitangabe in Sekunden ist.

Und die könnte aus dem Modul TAHR kommen und mit der Poll Routine zusammenhängen, weil da steht :

sub TAHR_Poll($)
{
  my ($hash) = @_;
 
  return if($hash->{STATE} eq "disconnected");

  DevIo_SimpleWrite($hash, "1049014A16", 1); # Request data (Poll)
  InternalTimer(gettimeofday()+3, "TAHR_Poll", $hash, 0); # 3 Sekunden warten
}

Und somit könnte es sich um falsche Verkettung der hashes handeln, aber jetzt wird das Bild für mich unscharf.
Und den Zusammenhang mit dem restart und dem save.fhm.cfg sehe ich garnicht.

Please help ...

LG

L G
. . . . . .
Fhem auf NUC7i3BNH, Raspberry Pi B und B+, Raspberry Pi 2 B, Peripherie: FB7490, 1-Wire, Homematic, FS20, Lampen, Briefkasten, Klingel, Sonos, GardenaSmart, Unifi, Gaszähler an GPIO, Stromzähler EFR SGM-C4, Heizung Buderus GBH 172, Alarmanlage EMA und BMA von Bosch

rudolfkoenig

Das InitFn in DevIO_SimpleWrite muss "undef" zurueckliefern, sonst gilt das Initalisieren als fehlgeschlagen.

Das ist wohl in dem (ungetesteten) TAHR Modul bzw. im initfn alias TAHR_Poll nicht beruecksichtigt: da nicht explizit angegeben, wird das Rueckgabewert des letzten Befehls (InternalTimer) zurueckgeliefert, und der liefert wiederum das Timeout zurueck _FALLS_ es als naechstes dran ist, sonst undef.

Loesung: Am Ende von TAHR_Poll "return undef;" einfuegen.

Lorenz

Super - Danke für die Hilfe.

Nun läuft alles wie es soll.
Das Modul was daraus entstanden ist, bildet die VdS 2465 Schnittstelle nach,
allerdings z.Zt. noch speziell auf eine bestimmte Anlage eingeschränkt,
so dass es noch keinen Sinn macht, es zu veröffentlichen.

Aber ich erweitere damit meine Perl-Kenntnisse und vielleicht entsteht am Ende ein Modul was die VdS Schnittstelle allgemeingültig
abbildet. Allerdings ist dies ziemlich komplex und aufwendig und wird daher noch etwas dauern.

Ich glaube aber, dass diese Schnittstelle eine Hausautomation ideal ergänzt und daher sich die Mühe lohnt, abgesehen von dem Lerneffekt.

Bislang habe ich eine Alarmanlage mit dem Umweg über FS20 Sende und Empfangsmodule eingebunden, dies brachte aber den Traffic zu sehr nach oben.

LG

L G
. . . . . .
Fhem auf NUC7i3BNH, Raspberry Pi B und B+, Raspberry Pi 2 B, Peripherie: FB7490, 1-Wire, Homematic, FS20, Lampen, Briefkasten, Klingel, Sonos, GardenaSmart, Unifi, Gaszähler an GPIO, Stromzähler EFR SGM-C4, Heizung Buderus GBH 172, Alarmanlage EMA und BMA von Bosch