Lange Auslöseverzögerungen

[cerise]

Hallo,

openHAB läuft hier auf einem Raspberry Pi 2 B, auf dem zusätzlich noch fhem mit CUL werkelt.
Die Kopplung zu LCN geht mit LinHK auf Fritzbox (7270v2), die Visualisierung mittels HABdroid.

Grundsätzlich klappt es, nach Erstellung von sitemap- und items-Datei, Lichter zu schalten, bzw. zu dimmen, oder Rollläden zu fahren.

Allerdings habe ich das Problem, dass nach wenigen Schaltaktionen via HABdroid die Ausführung der beabsichtigten Aktionen im Bus ca. 5-10s verzögert erfolgt. D. h. die erste oder einige wenige Aktionen werden sofort ausgeführt, dann stockt es. Ab und zu habe ich auch den Eindruck, dass manche Aktionen gar nicht ankommen.

Hat jemand so etwas auch schon mal gesehen?

Ist der Raspi überlastet?
Die angezeigte LinHK-Kopplungsqualität ist meist größer 96%, häufig aber nur größer 93%. Ist das zu schlecht? Geht hier was verloren oder bremst das?
Weiss jemand, wie ich der Verzögerung auf die Spur komme? In den Log-Dateien im openhab/logs/-Verzeichnis habe ich keine Fehlermeldungen gefunden.

Gruß, Jochen.

[BBL]

Wie ist denn so die Systemauslastung des Raspi? Ich habe meine mal angehangen. Konnte bei Tastendrücken keine nennenswerte Verzögerung feststellen, nur beim schnell wiederholten Dimmen über ein Slider kommt er für ein paar Zehntelsekunden ins Stocken.

[cerise]

Die Ausgabe von 'top' sieht hier ähnlich aus, load kleiner eins, keine (mir) auffälligen Speicher- oder CPU-Fresser. Statt lcnpchk läuft hier fhem.pl zusätzlich (macht aber keinen Unterschied, wenn ich fhem testweise beende).
Muss noch einen screenshot machen...

Auch nach einem Upgrade auf 1.8 sind die Verzögerungen immer noch da - hatte gehofft, das Problem ließe sich ggf. so beseitigen...

Bei mehrfachem Dimmen kurz hintereinander erscheinen die entsprechenden Meldungen sofort auf der 'osgi>'-Konsole (openHAB wurde mit start_debug.sh gestartet) und auch in der logs/events.log.
Bis die Kommandos allerdings im LinHK-Busmonitor auftauchen und entsprechend die Lampe reagiert, kann es bis zu 15s dauern :confused:

Gruß, Jochen, der sich fragt, in welcher Warteschlange die Kommandos aufgehalten werden und wie man das rausfindet...

[BBL]

Tja, schwierig, ich habe leider keine Erfahrung mit LinHK. Vielleicht kann ein anderer User hier weiter helfen.

[cerise]

Habe gestern einem Kollegen, der ebenfalls mit LinHK koppelt, openHAB empfohlen - mal sehen, welche Erfahrungen er macht...

Einen Hinweis habe ich noch gefunden. Im Log-File tauchen immer wieder folgende Meldungen auf

Code: Alles auswählen

2016-02-01 19:07:45.324 [WARN ] [osphere.cpr.DefaultBroadcaster] - Duplicate resource d6d78e82-fda9-48d6-9d52-8bfd12cda485. Could be caused by a dead connection not detected by your server. Replacing the old one with the fresh one

Ob solche 'dead connections' das System ausbremsen können? Sind aber nur 'WARN'ungen.

Gruß, Jochen.

[BBL]

Diese Meldungen hab ich auch, scheinen also keine direkte Ursache zu sein.

[cerise]

Ja, stimmt, habe mittlerweile einige Diskussionen zu diesen Warnungen im Netz gefunden; auch in anderen Projekten, in denen 'osphere' eingesetzt wird...

Hier ist noch ein screenshot der top-Ausgabe, zum Vergleich. Finde den aber immer noch unauffällig.

[cerise]

Die folgende Meldung (diesmal ein 'ERROR') habe ich auch schon mehrfach im Logfile gefunden:

Code: Alles auswählen

19:31:30.349 [DEBUG] [inding.lcn.internal.LcnBinding:153  ] - Channel "myhome" received input: =M000010.K1Roll�den S�d
19:31:30.404 [ERROR] [.b.l.i.LcnBindingActiveService:125  ] - Error while executing background thread LCN Refresh Service
java.lang.IllegalArgumentException: null
   at java.nio.Buffer.position(Buffer.java:244) ~[na:1.8.0]
   at org.openhab.binding.lcn.connection.Connection.readAndProcess(Connection.java:398) ~[na:na]
   at org.openhab.binding.lcn.connection.ConnectionManager$2.execute(ConnectionManager.java:275) ~[na:na]
   at org.openhab.binding.lcn.internal.LcnBinding.execute(LcnBinding.java:188) ~[na:na]
   at org.openhab.binding.lcn.internal.LcnBindingActiveService.run(LcnBindingActiveService.java:122) ~[na:na]
   at java.lang.Thread.run(Thread.java:744) [na:1.8.0]



Ist mir aber nicht klar, was das zu sagen hat...
Gruß, Jochen.

[cerise]

Für Interessierte:
Im LinHK-Support-Thread http://www.bus-profi.de/index.php/forum/topic/6651.html wurden Logfiles analysiert und eine mögliche Ursache für die Verzögerungen beschrieben.

Gruß, Jochen, der allerdings den Beweis dafür noch erbringen muss...