FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: PatrickR am 20 Juli 2018, 23:09:50

Titel: hmccu: Freezes bei dem Absenden mehrerer Kommandos
Beitrag von: PatrickR am 20 Juli 2018, 23:09:50
Guten Abend zusammen!

Ich verwende hmccu zur Steuerung meiner zahlreichen HmIP-Geräte. Für sämtliche Rolläden habe ich mehrere aufeinander aufbauende structures definiert. Sende ich nun ein entsprechendes Kommando an eine der Structures, treten Freezes auf, wobei die Länge variiert, z. B.:


Thu 19.07.2018 23:15:59  freezemon s:23:15:58 e:23:15:59 f:1.213 d:cmd-set OG.SZ.RolladenR down(Command) fn-SetFn(OG.SZ.RolladenR) tmr-structure_asyncQueue(EG.WZ.Rolladen) tmr-structure_asyncQueue(EG.Rolladen) tmr-structure_asyncQueue(HA.Rolladen)


Die Dauer der Freezes erreichte vereinzelt schon 18 Sekunden obwohl ich in Ermangelung von Alternativen als Workaround schon async_delays in den structures eingestellt hatte.

Patrick


Titel: Antw:hmccu: Freezes bei dem Absenden mehrerer Kommandos
Beitrag von: zap am 21 Juli 2018, 08:45:38
Wieviele set Kommandos werden denn da im Schnitt gleichzeitig abgesetzt? Wenn die CCU beschäftigt ist, kann das schon etwas dauern.

Du kannst mal im I/O Device im Attribut ccuflags das Flag nonBlocking setzen. Dann werden die set Befehle asynchron ausgeführt, d.h. FHEM dürfte nicht mehr blockieren. Je nach Anzahl der gleichzeitig abgesetzten Set Befehle frisst das Ressourcen auf dem FHEM Rechner, da für jeden Set Befehl ein Subprozess erzeugt wird (BlockingCall).
Titel: Antw:hmccu: Freezes bei dem Absenden mehrerer Kommandos
Beitrag von: PatrickR am 22 Juli 2018, 20:12:52
Hi!

Zitat von: zap am 21 Juli 2018, 08:45:38
Wieviele set Kommandos werden denn da im Schnitt gleichzeitig abgesetzt?
12 HmIP-BROLL

Zitat von: zap am 21 Juli 2018, 08:45:38
Wenn die CCU beschäftigt ist, kann das schon etwas dauern.
Unpraktischerweise ist die CCU (Selbst als RPi3 B+ mit RaspberryMatic) sehr schnell mit sich selbst beschäftigt. Das finde etwas ärgerlich...

Zitat von: zap am 21 Juli 2018, 08:45:38
Du kannst mal im I/O Device im Attribut ccuflags das Flag nonBlocking setzen. Dann werden die set Befehle asynchron ausgeführt, d.h. FHEM dürfte nicht mehr blockieren.
Danach hatte ich schon gesucht und meine mich zu erinnern, es nicht gefunden zu haben. Habe das heute Morgen schonmal getestet und es gab keinen Freeze mehr. Werde jetzt im nächsten Schritt die async_delays rausnehmen und schauen, ob Befehle verloren gehen oder die CCU am Rad dreht.

Zitat von: zap am 21 Juli 2018, 08:45:38
Je nach Anzahl der gleichzeitig abgesetzten Set Befehle frisst das Ressourcen auf dem FHEM Rechner, da für jeden Set Befehl ein Subprozess erzeugt wird (BlockingCall).
Das sollte auf dem Server nicht wirklich ein Problem sein.

Danke schonmal für das nonBlocking-Flag!

Patrick
Titel: Antw:hmccu: Freezes bei dem Absenden mehrerer Kommandos
Beitrag von: zap am 23 Juli 2018, 17:50:10
Den Raspi würde ich jetzt nicht als Server bezeichnen. Wenn wie bei mir 5 RPC Prozesse laufen, ein Sonos Subprozess sowie zeitweise mehrere Presence Prozesse, kann es schon eng werden mit dem physikalischen Speicher und FHEM wird merklich langsamer.

Jedenfalls solltest du bedenken, dass die nonBlocking Option nur gegen die Freezes von FHEM hilft. Die Befehle werden deshalb nicht schneller ausgeführt. Wenn Befehle gar nicht ausgeführt werden, kann es helfen, das Attribut ccuReqTimeout auf einen Wert >5 zu setzen.

Anderer Ansatz: du packst alle Rollladenbefehle in ein Programm auf der CCU. Das führst du dann per set execute aus.
Noch ne Variante: du erstellst auf dem Raspi ein Homematic Script mit den 12 Befehlen und führst das per set hmscript aus. Da kannst du sogar Parameter übergeben.

Beide Varianten haben den Vorteil, dass nur ein Request an die CCU geschickt wird.
Titel: Antw:hmccu: Freezes bei dem Absenden mehrerer Kommandos
Beitrag von: PatrickR am 23 Juli 2018, 21:11:53
Hi!

Zitat von: zap am 23 Juli 2018, 17:50:10
Den Raspi würde ich jetzt nicht als Server bezeichnen.
Das mache ich auch nicht. Ich bezeichne einen 4-Kern-Xeon mit 16 GB RAM als Server ;)

Zitat von: zap am 23 Juli 2018, 17:50:10
Jedenfalls solltest du bedenken, dass die nonBlocking Option nur gegen die Freezes von FHEM hilft. Die Befehle werden deshalb nicht schneller ausgeführt.
Das reicht mir vollkommen. Und tatsächlich werden sie sogar schneller ausgeführt, weil ich auf das async_delay in den Structures verzichten kann und der CCU das Bremsen überlasse. Habe das jetzt dank Deines Tipps schon ca. 2 Tage am Laufen und es sieht prächtig aus.

Zitat von: zap am 23 Juli 2018, 17:50:10
Wenn Befehle gar nicht ausgeführt werden, kann es helfen, das Attribut ccuReqTimeout auf einen Wert >5 zu setzen.
Werden die Timeouts eigentlich geloggt oder gibt es zufällig Events, die man handlen kann?

Zitat von: zap am 23 Juli 2018, 17:50:10
Anderer Ansatz: du packst alle Rollladenbefehle in ein Programm auf der CCU. Das führst du dann per set execute aus.
Noch ne Variante: du erstellst auf dem Raspi ein Homematic Script mit den 12 Befehlen und führst das per set hmscript aus. Da kannst du sogar Parameter übergeben.

Beide Varianten haben den Vorteil, dass nur ein Request an die CCU geschickt wird.
Ich wollte eigentlich sämtliche Logik in FHEM abbilden und die CCU nur als simples IO-Device mit erweiterten Parameterkonfigurations- und Debuggingmöglichkeiten nutzen.

Letztlich muss die CCU damit klarkommen, schließlich bietet sie die Schnittstelle an... Ich hoffe, bei eq3 arbeitet man auf dieses Ziel hin. Aktuell ist in der CCU leider noch etwas Nachholbedarf.

Auf jeden Fall Danke für den Hinweis mit dem nonBlocking!

Patrick