CUL und RFXTRX disconnect reconnect

Begonnen von Klaus Rubik, 06 Juni 2013, 11:37:50

Vorheriges Thema - Nächstes Thema

Klaus Rubik

Hallo FHEM Gemeinde,

seit einigen Tagen bekomme ich im Minutenabstand Fehlermeldungen folgender Art im Log-File:


2013.06.06 11:27:48 3: Setting CUL_0 baudrate to 9600
2013.06.06 11:27:48 1: /dev/ttyACM0 reappeared (CUL_0)
2013.06.06 11:27:48 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux
2013.06.06 11:27:48 3: Setting RFXTRXUSB baudrate to 38400
2013.06.06 11:27:48 1: /dev/ttyUSB0 reappeared (RFXTRXUSB)
2013.06.06 11:28:56 1: /dev/ttyUSB0 disconnected, waiting to reappear
2013.06.06 11:29:02 3: Setting RFXTRXUSB baudrate to 38400
2013.06.06 11:29:02 1: /dev/ttyUSB0 reappeared (RFXTRXUSB)
2013.06.06 11:31:50 1: /dev/ttyUSB0 disconnected, waiting to reappear
2013.06.06 11:31:55 3: Setting RFXTRXUSB baudrate to 38400
2013.06.06 11:31:55 1: /dev/ttyUSB0 reappeared (RFXTRXUSB)
2013.06.06 11:33:00 1: /dev/ttyUSB0 disconnected, waiting to reappear
2013.06.06 11:33:06 3: Setting RFXTRXUSB baudrate to 38400
2013.06.06 11:33:06 1: /dev/ttyUSB0 reappeared (RFXTRXUSB)
2013.06.06 11:33:11 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.06.06 11:33:16 3: Setting CUL_0 baudrate to 9600
2013.06.06 11:33:17 1: /dev/ttyACM0 reappeared (CUL_0)
2013.06.06 11:33:17 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux


Hat irgenjemand eine Idee woran das liegen kann?

Viele Grüße

Klaus

FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

Klaus Rubik

Update:

Zur Fehleranalyse habe ich FHEM nochmal komplett neu aus dem Image von FHEM.DE installiert. Aus der Altinstallation habe ich nur fhem.cfg, das gplot und das images Verzeichnis übernommen.

==> Fehler tritt nicht mehr auf

Danach Update ausgeführt...

==> Fehler tritt wieder auf, sowohl der CUL alsauch der RFXTRX disconnecten sich und reconnect erfolgt dann nach wenigen Sekunden.

Ideen?
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

rudolfkoenig

Keine wirkliche Idee, die dafuer Verantwortliche FHEM/DevIo.pm wurde seit dem release von 5.4 nicht geaendert, seit 5.3 ist auch nur eine Methode zum oeffnen von UNIX-Sockets dazugekommen.

Disconnect wird aufgerufen, falls beim Lesen keine Antwort kommt (read liefert -1 oder 0 zurueck).

Du solltest mit "attr global verbose 5", oder gezielter mit "attr CUL loglevel 2" das debugging erhoehen, und rauskriegen was vorher passiert ist.

Wenn man das Problem dadurch reproduzieren kann, dann koennen wir es auch loesen.

Klaus Rubik

Hallo Rudi,

ich habe den Loglevel wie vorgeschlagen auf 2 gesetzt, hier einige Auszüge aus dem Logfile:


2013.06.07 10:27:38 2: CUL_0: T1B1D00BA00 -81
2013.06.07 10:27:44 2: CUL_0: FC04BAA00 -83.5
2013.06.07 10:27:45 2: CUL_0: T081100B600 -79.5
2013.06.07 10:27:48 2: CUL_0: FC04BAA00 -84
2013.06.07 10:27:50 2: CUL_0: T4A4600BA00 -80.5
2013.06.07 10:28:00 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.06.07 10:28:05 3: Setting CUL_0 baudrate to 9600
2013.06.07 10:28:05 1: /dev/ttyACM0 reappeared (CUL_0)
2013.06.07 10:28:05 2: SW: V
2013.06.07 10:28:05 2: SW: ?
2013.06.07 10:28:05 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux
2013.06.07 10:28:05 2: SW: X21
2013.06.07 10:28:05 2: SW: T01
2013.06.07 10:28:10 2: CUL_0: T052200B600 -80.5
2013.06.07 10:28:19 2: CUL_0: T10693B02 -76.5
2013.06.07 10:28:19 2: CUL_0: T10693B82 -77
2013.06.07 10:28:51 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.06.07 10:28:56 3: Setting CUL_0 baudrate to 9600
2013.06.07 10:28:56 1: /dev/ttyACM0 reappeared (CUL_0)
2013.06.07 10:28:56 2: SW: V
2013.06.07 10:28:56 2: SW: ?
2013.06.07 10:28:56 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux
2013.06.07 10:28:57 2: SW: X21
2013.06.07 10:28:57 2: SW: T01
2013.06.07 10:29:11 2: CUL_0: T2B5F00B600 -63
2013.06.07 10:29:24 2: CUL_0: T173D00B636 -67.5
2013.06.07 10:29:27 2: CUL_0: H503D00947140 -68


Hilft Dir das weiter?

Viele Grüße

klaus
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

rudolfkoenig

Bedingt.
Man sieht, dass am Anfang die Kommunikation hervorragend funktioniert, und FHEM keine Anfrage gestellt hat, worauf er ungeduldig warten wuerde, und wg. fehlenden Antwort das Geraet auf disconnected setzt, sondern das Geraet meldet selbstaendig, dass hier nichts mehr zu lesen gibt.

Ich wuerde damit gerne auf das Betriebssystem (z.Bsp. /var/log/messages) verweisen, vielleicht steht das was drin.

Weitere Tests: vor und nach dem disconnected Meldung ein "get CUL_0 uptime" durchfuehren, um zu sehen ob culfw inzwischen ein reboot durchgefuehrt hat. Wenn ja, dann ist das Problem auf dem Stick zu suchen.

Klaus Rubik

Hallo Rudi,

der Stick hat eine Uptime von CUL_0 uptime => 1 02:01:10 , in der Zeit hatte ich etliche Fehlermeldungen.
/var/log/messages finde ich auf der Fritzbox 7390 nicht :-(

Viele Grüße

klaus
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

rudolfkoenig

>  /var/log/messages finde ich auf der Fritzbox 7390 nicht :-(

Etwas Vergleichbares kriegt man, wenn man per telnet sich anmeldet, und das Fenster offen laesst.

Willi

Hallo Klaus,

hast Du CUL sowie RFXtrx433 direkt ohne HUB an die 7390 angeschlossen oder mit USB-HUB dazwischen?

Wenn Du einen HUB dazwischen hast, sieht das nach Problemen mit dem HUB aus. Probier mal den direkten Anschluß ohne HUB.

Wichtig ist einen aktiven HUB (also mit separater Stromversorgung) zu nutzen. Bei einem passiven HUB, kann es je nach Wetter und Laune der Fritzbox funktionieren oder auch nicht. Da der Stromverbrauch von CUL sowie RFXtrx433 auch ein wenig abhängig von der Anzahl der Geräte ist, die pro Sekunde empfangen werden, kann es Dir passieren, dass es anfangs mit dem passiven funktioniert, aber später nicht mehr, weil CUL und RFXtr433 mehr Strom benötigen. Evtl. liefert aber auch die Fritzbox nicht mehr so viel Strom auf dem USB-Port wie früher mal. Es gibt viele mögliche Gründe.

Gemäß meiner Erfahrung funktionieren nicht alle USB-HUBs stabil (auch im aktiven Betrieb) an Fritzbox und Linux-Rechnern. Sinnvoll wäre also mal einen anderen USB-HUB zu testen.

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

Klaus Rubik

Hallo,

@Rudi:
ZitatEtwas Vergleichbares kriegt man, wenn man per telnet sich anmeldet, und das Fenster offen laesst.
Es kommen keine Meldungen, nur im FHEM-Logfile die bereits bekannten.

@Willi:
Zitathast Du CUL sowie RFXtrx433 direkt ohne HUB an die 7390 angeschlossen oder mit USB-HUB dazwischen?
Ich habe einen passiven Hub dazwischen, besorge mir am Montag einen aktiven mit Stromversorgung.

Klaus
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

Willi

Ich würde erst einmal den RFXtrx433 direkt an einen der beiden USB-Ports (einer hinten, einer an der Seite) anschließen.
Wie viele Geräte hast Du denn an der 7390?
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Klaus Rubik

einen CUL 868
einen 4 GB USB-Stick
und den RFXTRX433
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

Willi

Da der USB-Stick vermutlich weniger Strom verbraucht als RFXtrx433 und CUL, würde ich mal versuchen den USB-Stick an den HUB und RFXtrx433 direkt an einen USB-Port anzuschließen.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Klaus Rubik

Hallo Willi, hallo Rudi,

ich bin mir nicht sicher, ob das wirklich ein HW-/Spannungsproblem am USB Port oder Hub sein soll. Ich habe heute nochmals eine Grundinstallation mit dem Image von FHEM.DE durchgeführt. Aktueller SW-Stand:

version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3008 2013-04-01 11:19:27Z rudolfkoenig $

Seit der Installation heute morgen bis jetzt nicht eine einzige Fehlermeldung im Logfile. Vor der Installation hatte ich auch noch tonnenweise Einträge im Logfile wie im Thread [Beitrag #81374] beschrieben.

Vorschlag zur Fehlereingränzung:
Ich würde jetzt Modul für Modul einzeln per update modulname durchführen und danach jeweils auf Fehlermeldungen im Logfile prüfen.
Macht das aus Eurer Sicht Sinn? Wenn ja, in welcher Reiehnfolge soll ich die Module updaten?

Viele Grüße
Klaus
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

febus

Hallo,
ich hatte auch Probleme nach einem Update gestern und konnte mir nur mit einem restore helfen:

1) disconnect reconnect des RFXTRX
2) unknown message Einträge im Log (mehrere pro Sekunde!)
3) Sendebefehle funktionieren nicht mehr (erst nach Hardware reset des CULs).

Ich nutze einen CUL und einen RFXTRX an einem RPi. Seit dem Restore läuft wieder alles ohne Probleme.
Das unterstützt also die These, dass sich hier mit dem Update ein Software-problem für die Konfiguration eingeschlichen hat.

Gruß,
Marc

Viele Grüße,
Marc

Willi

Ich habe soeben meine Fritzbox 7390 auf die neueste FHEM-Version geupdated.
Sicherheitshalber habe ich alle Dateien geupdated. Bisher scheint es bei mir keine Probleme zu geben.

Allerdings ist der RFXtrx433 direkt an einem USB-Port. Und CUL ist an einem anderen Gerät.

@Rudi: Was machen die folgende Änderungen in FHEM:
  - fhem.pl 1. Juni: "Making regexp in Client-List of iodevs work in Dispatch"
  - DevIo.pm 8. Juni: "FBAHA reconnect works now / get dect200 devInfo detects 546E absence"

Evtl. könnte hilfreich sein, nach dem vollständigen Update testweise fhem.pl sowie DevIo.pm einer älteren Version einzuspielen und zu sehen, was passiert.

Ansonsten würde ich vorschlagen, eines der Geräte (RFXtrx433 und CUL) abzustecken und zu testen, ob das Problem noch besteht. RFXtrx433 am besten direkt ohne HUB anschließen.

Interessant wäre, ob das Problem dann noch auftritt. Irgendwie müssen wir ja die Fehler eingrenzen können.
Mit ist allerdings immer  noch schleierhaft, warum CUL und RFXtrx433 stabil über einen passiven HUB funktionieren sollten. Deshalb werde ich Fehler bzgl meines Codes nur analysieren wollen, wenn RFXtrx entweder an einem aktiven Hub oder direkt am USB-Port hängt. Ich möchte ausschließen wollen, dass es an einem passiven HUB liegt.

Bitte als Infos jeweils angeben:
- Version der Firmware RFXtrx433: Bitte die Zeile "TRX: Init status":
TRX: Init status: '433.92MHz transceiver, firmware=64, protocols enabled: Lighting4 LaCrosse Hideki OREGON AC X10 '
- Version der Fritzbox. Bei mir: "FRITZ!OS 05.22"
- Anschluss RFXtrx433 wie per USB: "direkt hinten"/"direkt Seite"/"passiver HUB"/"aktiver HUB".
  Bei mir "direkt Seite"
- Wenn UNKNOWN-Messages kommen diese mit den Zeilen davor angeben.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433