Dimmer Aktoren blockiert bei HmIP-RCV-50 verlinkung

[frd030]

Vielleicht beschreibt mal jemand, was wer genau und wie eingerichtet hat ubd unter wecher Firmware.

Firmware: Problem besteht seit FW 3.45.7 (aktuell ist 3.47.22 drauf).
Ich habe die Virtuellen Taster unter 3.43.16 eingerichtet, da funktionierten sie noch ohne jegliche Verzögerung!

Hier ein (typisches) Beispiel mit zwei Aktoren: Die Steckdose ist ein HmIP-PS, der Schalter ein HmIP-FSM, beide mit aktüller FW.
Der virtuelle Taster soll beide Lichter in der Küche gleichzeitig abschalten:

Hier die Konfig der Verknüpfungen (Einstellungen Default):

Wenn man den vTrigger mit diesen beiden Direktverbindungen aktiviert (egal ob über einen physischen Taster (HmIP-WRC2 löst Programm aus), direkt manuell in der WebUI oder in PocketControl per Click), dann tut die CCU3 erstmal die nächsten ca. 15 Sekunden - nichts - das bedeutet, dass alle in dieser Zeit getriggerten Programme nicht oder erst nach dieser Wartezeit ausgeführt werden. Direktverknüpfungen gehen natürlich noch und die WebUI ist weiterhin grundsätzlich bedienbar, auch in dieser Wartezeit. Der Log gibt nicht mehr her, als schon gepostet, er zeigt lediglich, dass es diese Verzögerung gibt.

[alchy]

Direktverknüpfungen gehen natürlich noch

Werden die Aktoren aus DER DV direkt angesteuert oder die auch verzögert

dann tut die CCU3 erstmal die nächsten ca. 15 Sekunden - nichts - das bedeutet, dass alle in dieser Zeit getriggerten Programme nicht oder erst nach dieser Wartezeit ausgeführt werden.

Das habe ich mal versucht zu prüfen. Ein "führe alle 3 Sekunden Programm war schnell zusammengeklickt. Weile laufen lassen damit die CCU richtig Last bekommt und dann die Tasten Alle Rollo RUNTER (IP) & Alle Rollo HOCH (IP) nacheinander gedrückt.

Resultat: interessiert die CCU überhaupt nicht. Das 3 Sekunden Programm wurde trotzdem getriggert und logisch ausgeführt.
auch alle Rollos sind direkt nach Tastendruck runter, bzw. hoch gefahren.

und die WebUI ist weiterhin grundsätzlich bedienbar, auch in dieser Wartezeit

zusätzlich habe ich während des Tests noch eine Schaltsteckdose HM-LC-Sw1-Plmehrfach völlig verzögerungsfrei bedient, auch Sensoren wie HmIP-SWDO-I melden verzögerungsfrei ihren geänderten Zustand.


ABER

im 4. Versuch hatte ich dann so etwas ähnliches wie ein Lag.
ALLERDINGS hatte ich mich dabei verdrückt und die Lange Taste statt der Kurzen benutzt.
Der Druck auf die Taste brachte die Rollos nur zum anrucken, hielten kurz inne und bewegten sich nach ca. 3 Sekunden kurz weiter und blieben stehen.
Das ist bei mir auch reproduzierbar. Während ein kurzer Tastendruck wie geplant funktioniert, funktioniert ein langer Tastendruck nicht.

Kannst du (oder ein Mitleser) dies mal gegenprüfen bitte. Ich muss da später weiter machen, vor allem mit einer DV zu Schaltaktoren.


Alchy

[comtel2000]

Könntet ihr zusätzlich bitte in die hmserver.log sehen, ob diese Meldungen auftreten:

Code: Alles auswählen

Transaction State: false | Size: 2 

Im Debug Mode sieht es so aus:

Code: Alles auswählen

Nov 5 12:40:00 de.eq3.cbcs.devicemanagement.TransactionManager INFO  [vert.x-eventloop-thread-3] Transaction State: true | Size: 1 
Nov 5 12:40:00 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendNotificationHandler DEBUG [vert.x-worker-thread-2] send event(s) to interface: 1009 http URL: http://127.0.0.1:31999 
Nov 5 12:40:00 de.eq3.cbcs.devicemanagement.TransactionManager INFO  [vert.x-eventloop-thread-3] Transaction State: false | Size: 2 
Nov 5 12:40:00 de.eq3.cbcs.devicemanagement.TransactionManager INFO  [vert.x-eventloop-thread-3] Transaction State: false | Size: 3 
Nov 5 12:40:00 de.eq3.ccu.server.internal.BasicAPIHttpVertxHandler DEBUG [vert.x-eventloop-thread-2] io.vertx.ext.web.impl.HttpServerRequestWrapper@bd50ae 
Nov 5 12:40:00 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-5] rpc.api.bidcos Incoming Request: event 
Nov 5 12:40:00 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher DEBUG [vert.x-eventloop-thread-5] event interface: HmIP-RF_java device 001F58A9A72427:10: key:PRESS_SHORT = true 
Nov 5 12:40:00 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-5] rpc.api.bidcos Send Response for : event 
Nov 5 12:40:00 de.eq3.ccu.server.internal.BasicAPIHttpResponseHandler DEBUG [vert.x-eventloop-thread-2] io.vertx.ext.web.impl.HttpServerRequestWrapper@bd50ae 
Nov 5 12:40:01 de.eq3.cbcs.devicemanagement.TransactionManager INFO  [vert.x-eventloop-thread-6] Transaction State: false | Size: 4 
Nov 5 12:40:01 de.eq3.cbcs.devicemanagement.TransactionManager DEBUG [vert.x-eventloop-thread-6] Suspend transaction 34 task SendFrameCommand [frame=UnconditionalSwitchCommandFrame : ApplicationHeader [frameType= UNCONDITIONAL_SWITCH_COMMAND, macSource=000000, macDestination=F00001, ipSource=000000, ipDestination=F00001], sendMode=PERMANENT_LISTENER], start fast lane transaction 37 task SendFrameCommand [frame=AnswerFrame : ApplicationHeader [frameType= ANSWER, macSource=000000, macDestination=912310, ipSource=000000, ipDestination=912310], sendMode=PERMANENT_LISTENER]

..

Nov 5 12:40:17 de.eq3.cbcs.server.core.vertx.handler.TransactionTimeoutHandler DEBUG [vert.x-worker-thread-1] Abort Transaction with ID: 34 and Timer ID: 144 from AP: 3014F711A0001F58A9A72427 currentTask: SendFrameCommand [frame=UnconditionalSwitchCommandFrame : ApplicationHeader [frameType= UNCONDITIONAL_SWITCH_COMMAND, macSource=000000, macDestination=F00001, ipSource=000000, ipDestination=F00001], sendMode=PERMANENT_LISTENER] 

 

Die Transaktionen können nicht abgearbeitet werden und alle weiteren Events stauen sich auf bis zum "TransactionTimeout" hier 17 sec.
Einen Unterschied zwischen kurz oder langem Taster Event kann ich bei mir nicht erkennen.

[alchy]

Jupp, die TransactionManager INFO Meldungen finde ich auch im Protokoll.
Allerdings bringe ich die nicht in diesen Zusammenhang und sind die dann nicht auch thread abhängig?

Aber ich kann das Problem ja auch nicht nachvollziehen. Finde auch kein Suspend oder Timeout.
Habe wohl nur durch Zufall wahrscheinlich irgendetwas anderes gefunden mit kurzer vs. langer Taste.

Alchy

[frd030]

Direktverknüpfungen gehen natürlich noch

Werden die Aktoren aus DER DV direkt angesteuert oder die auch verzögert

Die Aktoren reagieren sofort auf diese DV und werden nicht verzögert, nur alle Programme die danach getriggert werden.

[frd030]

Aber ich kann das Problem ja auch nicht nachvollziehen. Finde auch kein Suspend oder Timeout.
Habe wohl nur durch Zufall wahrscheinlich irgendetwas anderes gefunden mit kurzer vs. langer Taste.

Tja, homematic bringt immer wieder Überraschungen...
Danke für Deine Bemühungen!
Ich habe noch ein zwei Ideen, die ich vielleicht am Wochenende mal probiere...

Ich kann mir durchaus vorstellen, dass es irgendein Zusammenspiel sein könnte, das vielleicht nicht in allen Systemen existiert. Schwer zu finden, fürchte ich. Einziger Anhaltspunkt könnte sein, dass sich das Verhalten mit dem Update von einer auf die andere FW plötzlich verändert hat - ich habe damals sogar einen Rollback gemacht und dann funktionierte mit der 3.43.16 wieder alles verzögerungsfrei. Es muss sich etwas in der FW geändert haben, das im Zusammenhang steht. Leider geben die ChangeLogs von eQ-3 nicht viel her...

[Baxxy]

Da ich gerade ein bisschen mit Direktverknüpfungen experimentiere habe ich das mal an meinem Testsystem nachgestellt.
Und siehe da, auch bei mir gibt es eine mal mehr mal weniger große Verzögerung.

Beteiligte Komponenten: Raspi3B mit RPI-RF-MOD und RaspberryMatic 3.47.22.20191026, 2x HmIP-PSM (FW: 2.6.2), 1x HmIP-WRC6 (FW: 1.0.19)

Die DV's sind Standardverknüpfung Taster - Schaltaktor (Schalter ein / aus) zwischen virtueller Taste und PSM.
Einstellungen Kanal 2 der PSM's:

2xPSM_DV_Settings.JPG (17.18 KiB) 1448 mal betrachtet

Das erste "Einschalten" geht noch sofort, danach wird's zäh.

Zum Vergleich habe ich dann noch eine Taste des WRC6 mit den PSM's verknüpft, da klickt's und klackt's direkt ohne Verzögerung.

Grüße
Baxxy

[alchy]

Die Aktoren reagieren sofort auf diese DV und werden nicht verzögert, nur alle Programme die danach getriggert werden.

OK, dann hatte ich etwas missverstanden.
Aber auch das Verzögern von Programmen nach Tastendrücken habe ich ja mitgetestet. Verzögerungen konnte ich nicht feststellen. Steht aber auch noch der Versuch aus mit einer DV mit Schaltaktoren. Obwohl ich mir da wenig Hoffnung mache. Aber wer weiß das schon so genau.
Aber ich werde es testen in den nächsten Tagen und mich melden.

Ich kann mir durchaus vorstellen, dass es irgendein Zusammenspiel sein könnte, das vielleicht nicht in allen Systemen existiert. Schwer zu finden, fürchte ich.

Daher ja auch meine Nachfrage nach genaueren Angaben. Wenn man einen Fehler reproduzieren kann, haben es die Programmierer einfacher.
Was wiederum natürlich nicht heißt, das reproduzierbare Bugs auch gefixt werden würden.

Und siehe da, auch bei mir gibt es eine mal mehr mal weniger große Verzögerung.

Es wurden ja wohl keine Verzögerungen bei der Ausführung der DV sondern bei "zeitgleich" stattfindenden Programmen bemängelt.
Aber auch bei dir jedenfalls Schaltaktoren. Das muss ich noch testen.



Jedenfalls ist kurz vs. Langer Tastendruck bei der Rollo DV bei mir reproduzierbar.
Schade, das noch keiner geschaut hat bei sich. Ich kann mir vorstellen, das viele User eine DV zwischen einer virtuellen IP Taste und mehreren IP Rolladenaktoren haben.


Alchy

[comtel2000]

Ich denke, das mein ursprüngliches Problem: DVs virtueller Taster mit mehreren HmIP-BDT und auch HmIP-PSM (@Baxxy) + aktueller CCU firmware betrifft. Ob RaspberryMatic oder original CCU eine Rolle spielt ist mir noch unklar.
Ich habe mal ein Ticket bei RaspberryMatic aufgemacht. Ich tippe aber eher auf ein generelles EQ3 Problem.
Gruß Joerg

[comtel2000]

Es wurden ja wohl keine Verzögerungen bei der Ausführung der DV sondern bei "zeitgleich" stattfindenden Programmen bemängelt.

Genau, die Verzögerung startet immer erst nach der DV Taster Aktion.
Die DV Aktion selbst geht ohne Verzögerung und löst anschließend das Blockieren aller CCU Funkevents (Alles was über CCU Funk läuft) für die folgenden 20sec. aus.
Ich habe leider nur einen HmIP Rolladen Aktor, der läuft bei 1:1 DV ohne Probleme (kurz oder langer virtueller Taster)