CUL@PI -> Komm. bricht nach Stunden ab -> X21 weckt den CUL wieder auf

[grobiballon]

Hallo,

Ich habe schon länger Probleme mit dem CUL am Raspberry mit FHEM 5.5
Betrieben wird er aktuell mit vier FHTs. Die Kommunikation funktioniert grundsätzlich ohne Probleme. Wenn man jedoch den CUL für längere Zeit "in Ruhe" lässt, empfängt und sendet er keine Daten mehr. Der Buffer läuft voll und von den FHTs und den FHT8Vs werden keine Statusberichte mehr empfangen.
Die Kommunikation bricht offensichtlich immer einige Stunden nach der letzten durch FHEM initiierten Kommunikation mit den FHTs ab. Wenn ich regelmäßig den CUL durch set CUL1 raw X21 anspreche, funktioniert alles tadellos, dennoch sollte dies nicht die dauerhafte Lösung sein. Im Übrigen bleibt durch das X21 der Buffer bestehen, der dann auch brav abgearbeitet wird.

Definiert ist der CUL V3  wie folgt:

Code Auswählen Erweitern

define CUL_0 CUL /dev/ttyACM0@9600 0200

Ich habe in der Situation der eingeschlafenen Kommunikation mal die folgenden Befehle ausgeführt:

Ist Empfang eingeschaltet? --> dürfte OK sein

Code Auswählen Erweitern

get CUL_0 raw C35

CUL_0 raw => C35 = 0D / 13


Auslesen der CULFW Version: --> es gibt eine neuere, sollte aber kein Problem sein

Code Auswählen Erweitern

get CUL_0 raw V

CUL_0 raw => V 1.57 CUL868


Freie CUL Sendezeit --> Bin mir hier nicht sicher was richtig ist.

Code Auswählen Erweitern

get CUL_0 raw X 2

CUL_0 raw => 21 900


Freie Kapazität des FHT Buffers --> Der Buffer ist nicht leer, wie im nächsten Schritt zu sehen ist.

Code Auswählen Erweitern

get CUL_0 raw T03

CUL_0 raw => 86


Inhalt des FHT Buffers: --> ist nicht Leer, einige Befehle haben sich seit dem "schlafen legen" des CULs angesammelt.

Code Auswählen Erweitern

get CUL_0 raw T02

CUL_0 raw => 0202:3E01 0203:3E01 0201:3E01 0204:3E01 0202:3E01 0203:3E01 0201:3E01 0204:3E01


Eingestellte FHT-ID: --> dürfte nicht kritisch sein.

Code Auswählen Erweitern

get CUL_0 raw T01

CUL_0 raw => 0200


Eingestellte Frequenz, Bandbreite etc. Ausgeben: --> Dürfte auch unproblematisch sein. Normalerweise keine Probleme mit dem Empfang.

Code Auswählen Erweitern

get CUL_0 ccconf

CUL_0 ccconf => freq:868.350MHz bWidth:464KHz rAmpl:42dB sens:4dB


set CUL_0 raw X61 --> Damit habe ich nun mal das Logging hoch gesetzt.
set CUL_0 raw X25 --> Damit werden auch checksum-Fehler angezeigt.
set CUL_0 raw X80 --> RSSI / Signalstaerke jeder Flanke wird gemeldet

Irgendwann mitten beim Ausführen dieser Befehle hat der CUL erwartungsgemäß wieder einwandfrei funktioniert - nur warum?

Es scheint mir so, als wenn der CUL in eine Art Energiesparmodus verfällt. Gibt es sowas? Der Raspberry an sich hat ja keine Energiesparmodi. Ich glaube langsam nicht mehr, dass es irgendwo an FHEM liegt.

So langsam bin ich mit meinem Latein am Ende.

Gruß
Andreas

Edit: der Betreff hatte sich irgendwie unsinnig verändert.

[betateilchen]

Das Verhalten ist doch längst im Wiki unter "bekannte Probleme" beschrieben:

http://www.fhemwiki.de/wiki/FHT80b#Bekannte_Probleme

http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT

[grobiballon]

Hallo,

danke für die Schnelle Antwort. Ich kenne den Wiki. Ich glaube nicht, dass es dieses Problem ist, denn warum funktioniert die Kommunikation nach Ausführen von "set CUL_0 raw X21" wieder? Wenn es Frequenzprobleme wären, dürfte der Buffer - nach meinem Verständnis - danach auch nicht weiter abgearbeitet werden. Zu dem Funktioniert das Empfangen der Telegramme sofort wieder.
Laut Wiki ändert "set CUL_0 raw X61" nur das Logging und setzt im CUL nichts zurück.
Und es liegt auch nicht an dem beschriebenen Problem, dass die FHTs nichts mehr senden, denn sie tun es, ohne dass ich sie mit "report" aufwecken muss.

Gruß
Andreas

[micomat]

evtl ein Problem mit der Spannung? wie groß ist das Netzteil am Pi?
cfg schick ich dir später.

[grobiballon]

evtl ein Problem mit der Spannung? wie groß ist das Netzteil am Pi?

Ich habe da ein 1500mA Netzteil dran. Hatte da auch schon dran gedacht. Wenn es das Netzteil wäre, dann könnte ich den CUL aber nicht mit einem raw X21 wieder aufwecken. 1500mA müssten nach allem was ich gefunden habe ausreichend sein.

[micomat]

sehe ich auch so...

[grobiballon]

Ich habe nunmal den ganzen Abend rumgegoogled und bin auf das hier gestoßen:
http://unix.stackexchange.com/questions/91027/how-to-disable-usb-autosuspend-on-kernel-3-7-10-or-above

Kurz gesagt geht es um Änderungen im Linux-Kernel bei Wechsel auf 3.10. Es soll sich etwas im USB-Powermanagement geändert haben. Ich muss da am Wochenende mal dran herumfummeln - habe aktuell leider keinen Zugriff via Telnet. Ich habe aber eigentlich keinen Plan von der Geschichte - Linux ist absolut noch nicht meins und ich habe das Teil quasi nur mit Anleitung eingerichtet.

Vielleicht ist die Sache hier aber auch ein Denkanstoß an einen erfahrenen Linuxianer, der mir noch Tipps geben kann...

[micomat]

ich hab aktuell keine ahnung welchen kernel ich fahre, muss ich mal schauen