Hallo,
Kann es sein, dass die Implementierung für den CUL in FHEM stark blockieren ist?
Mir ist es gerade aufgefallen, bei einem nicht verbundenen CUL, dass hier relativ lange Freezes entstehen, wenn man "get ccconfig" macht oder eine Lampe schalten will
2019.01.17 08:31:23 1: [Freezemon] myFreezemon: Long running Command detected get MAPLECUL_WLAN1 ccconf :WEB - 3.004969 seconds
Die 3 Sekunden sehen mir auch stark nach einem Timeout in der Implementierung aus.
Gruß
Stefan
Ja, CUL ist bei get blockierend, ich empfehle get Befehle nach Moeglichkeit zu vermeiden.
ccconf ist besonders gravierend, da es intern 6 (potentiell blockierende) Befehle absetzt.
Sollte bei einem per USB angeschlossenen CUL nicht merkbar sein, bei RFR-CULs ist das aber ein echtes Problem.
Set ist nicht blockierend.
Zitat von: rudolfkoenig am 17 Januar 2019, 12:50:43
Ja, CUL ist bei get blockierend, ich empfehle get Befehle nach Moeglichkeit zu vermeiden.
ccconf ist besonders gravierend, da es intern 6 (potentiell blockierende) Befehle absetzt.
Sollte bei einem per USB angeschlossenen CUL nicht merkbar sein, bei RFR-CULs ist das aber ein echtes Problem.
Set ist nicht blockierend.
Aber selbst das setzen von einem Befehlt (Schalten eine LED) ist so blockieren.
Wie definierst du "einem nicht verbundenen CUL" ?
Zitat von: rudolfkoenig am 17 Januar 2019, 13:30:01
Wie definierst du "einem nicht verbundenen CUL" ?
Ein CUL/CUN der nicht über das Netzwerk erreichbar ist.
Habe jetzt eine weile mit socat rumexperimentiert (gestartet, gestoppt, getoetet, vor dem FHEM start, oder danach), und sehe kein Problem.
Beim FHEM Start gibt es nur beim gestoppten socat ein delay von 9 Sekunden, sonst keins.
Im Betrieb konnte ich keinen Haenger provozieren.
Zitat von: rudolfkoenig am 17 Januar 2019, 19:21:29
Habe jetzt eine weile mit socat rumexperimentiert (gestartet, gestoppt, getoetet, vor dem FHEM start, oder danach), und sehe kein Problem.
Beim FHEM Start gibt es nur beim gestoppten socat ein delay von 9 Sekunden, sonst keins.
Im Betrieb konnte ich keinen Haenger provozieren.
Ich konnte es gut mit einem CUN produzieren, der über WLAN angebunden ist.
ZitatIch konnte es gut mit einem CUN produzieren, der über WLAN angebunden ist.
Und wie genau war es dann nicht verbunden?
Naja, über WLAN initialisiert und im Status initialized und dann Strom weg, aber FHEM weiß dass nicht und sucht beim get/set über die IP nach einem toten Gerät.
Gruß Arnd
Gesendet von iPhone mit Tapatalk