[gelöst] Delay beim automatisierten Schalten vom Harmony Hub

[Thyrador]

Moin Moin, ich mal wieder. Und zwar habe ich folgendes Problem:

In Abhängigkeit bestimmter Trigger/Aktionen, soll für meinen AVR eine bestimmte Lautstärke als Standard eingestellt sein (z.B. mein allmorgendlicher Alarm, Kino, etc).
Hierfür habe ich in meinem Frontend (Tablet UI) gewisse Einstellungen mit festen Werten vorbelegt, die aber nach Bedarf angepasst werden können.

Das funktioniert auch alles ganz prima und am Ende habe ich auch die gewünschte Lautstärke, beim Start meiner Aktionen. Aber wir wissen ja, wieso jetzt das tolle Wort "wenn" kommen muss.
Denn wenn ich über ein Perl-Script im Hintergrund die Lautstärke Stufe für Stufe einstellen lassen möchte, dann dauert das wirklich sehr lange.
Da mein AVR die Lautstärke in 0.5er Schritten zählt und ich beim Alarm auf Stufe 65 hochregeln lassen möchte, so sind das 130 Schritte, die hier zu absolvieren sind.
Wenn ich über die Harmony-App die Lautstärke regeln möchte, dann geht das im Grunde auch sehr fix, leider lassen sich hier aber nicht feste Stufen oder größere Sprünge definieren (obgleich der AVR das durchaus verstehen würde, da z.B. Yatse mit entsprechendem Plugin größere Sprünge ermöglicht, die auch sofort umgesetzt werden).

So sitze ich nun also, wenn ich den Kinomodus einstelle, locker eine Minute, oder gar länger, bis ich auf dem entsprechenden Lautstärkepegel bin. Sehr nervtötend.
Und das alles nur, weil ich erst die Lautstärke komplett runter regeln muss (max 98 Stufen, á 0.5er Schritte = 196xVolumeDown), dann 130xVolumeUp).

Um's knapp zu halten, hier das Snippet vom Perl-Code:

Code Auswählen Erweitern

for(my $i = 0; $i < 196; $i++) {
      $avol .= "set WZ.harmonyDenonAVRX3300 VolumeDown;";
   };

...

for(my $i = 0; $i < $volcnt; $i++) {
      $avolu .= "set WZ.harmonyDenonAVRX3300 VolumeUp;";
   };

So wird am Ende ein riesiger Befehlsstring zusammen gebaut, der dann an FHEM übergeben wird und FHEM erledigt dann die Steuerung des Harmony Hubs.

Zu meiner Frage: gibt's hier noch irgendwie Optimierungsmöglichkeiten, sodass die Übergabe/Ausführung der Befehle schneller abgewickelt wird? Die Verzögerung entsteht übrigens nicht beim erzeugen des Befehls, sondern beim Ansteuerung von FHEM an den Hub.
Dasselbe Verhalten lässt sich übrigens auch im normalen Frontend reproduzieren, indem ich die Kommandos für die Lautstärke als webcmd anlege und hier wie wild auf den Link hämmere: reagiert genau so träge.

Da ich eine solche Sonderlocke ungern als "Ich füge jeden Schritt einzeln in meinem Hub hinzu und hab dann ein Problem, wenn ich mich entweder verzählt habe, oder doch irgendwann einmal diese Einstellung ändern möchte" direkt über den Hub realisieren möchte, war die Idee über FHEM eben weitaus komfortabler, da ich hier eben mit wenigen Handgriffen eine solche Änderung schnell umsetzen kann.

Vielen Dank schon mal im Voraus



EDIT:

Alternativ würde sogar reichen, wenn mir einer fix erklärt, wie ich in dem Perl-Script einfach nur folgende URL aufrufen kann: http://meineipvomavrreceiver/MainZone/index.put.asp?cmd0=PutMasterVolumeSet/-15.0

Denn das würde mein Problem so ziemlich auf Anhieb lösen, ohne dass ich da den Hub dazu bemühen müsste.

[Prof. Dr. Peter Henning]

wenn mir einer fix erklärt

Klar doch. Shellskript mit einem Aufruf von curl

LG

pah

[Thyrador]

Bin mit Perl noch nicht ganz so dicke, hast du da ein Beispiel dafür? Für die Berechnung der Lautstärke würde es dann aber auch reichen, wenn ich dann einfach bloß subtrahiere, also einfach meinen Wert, den ich aus dem Frontend habe, dann einfach nur - einem fest eingestellten Wert subtrahiere und das dann an's Ende der Url hänge, oder?

EDIT: Geht das eigentlich auch einfach mit einem Decimal-Wert? Denn wenn ich jetzt 65 haben will, müsste ich rechnen: 65.0 - 80 = -15.0
Geht das so einfach in Perl?

[Thyrador]

Hab's jetzt erstmal so:

Code Auswählen Erweitern

my $vol = $volcnt - 80;
$acmd .= "\"wget -q http://ip.vom.av.receiver/MainZone/index.put.asp?cmd0=PutMasterVolumeSet/".$vol." -O /dev/null\";";

Funktioniert nun ohne Wartezeiten und schaltet direkt, je nach Einstellung.

Verbesserungsvorschläge sind gern gesehen


EDIT: Natürlich bleibt dennoch die ursprüngliche Frage: gibt's ne Möglichkeit, diese Art von Delays beim Schalten über FHEM zu minimieren?

[justme1968]

so viele kommandos hintereinander sind nicht optimal. das blockiert fhem. mehr oder weniger.

über die lösung die hier: https://forum.fhem.de/index.php/topic,51906.msg436451.html#msg436451 entwickelt wurde kann man das aber vermeiden.

für größere sprünge kann man mit harmony sequenzen arbeiten. das vermindert aber nicht die gesamt dauer.

für denon avr gibt es doch ein fhem modul. wenn das nicht geht kannst du dir mit HTTPMOD etwas zusammen bauen.

gruss
  andre

[Thyrador]

Dachte ich mir ja auch irgendwie, aber die Verzögerung gibt's ja eben auch schon, wenn ich den Befehl meinetwegen nur 2-3x hintereinander aufrufen lasse.
Daher kam mir eben der Verdacht, dass FHEM an der Stelle das ganze nicht schneller an den Hub überträgt, da der Hub ja mit einer schnellen Abfolge (über die App, externe Aufrufe, die nicht von FHEM kommen, auch schnell umgehen kann).

Ein solches Modul habe ich im Modul-Ordner aber nicht gefunden, wie heißt das denn?

[justme1968]

es gibt im modul keine geschwindigkeitsbegrenzung. die kommandos werden so schnell gesendet wie es das api erlaubt. aber zweischen tasten druck und taste loslassen wird aktuell 0.1 sekunde aktiv gewartet. das summiert sich natürlich bei 100 tastendrücken.

andererseits war das bis jetzt noch kein problem da die reine ir übertragung auch zeit braucht und es eigentlich bei den meisten geräten eh nicht wirklich viel schneller geht.

https://wiki.fhem.de/wiki/Denon_AV-Receiver

[Thyrador]

Dagegen spricht doch aber trotzdem, dass es mit physischer Fernbedienung, App und per Kommandozeile (mit ner einfachen Schleife) eben schneller geht, als aus FHEM heraus.
Und da vergehen locker mehr als nur 100ms, zwischen den einzelnen Steps. Ich dachte ja erst an die Verzögerungseinstellungen innerhalb des Hubs und hab's danach eben mit anderen Quellen probiert.
Im Regelfall schalte ich ja auch nicht so wahnsinnig viele Kommandos nacheinander mit FHEM. Das rührt ursprünglich auch nur aus der Verwendung des Z906 von Logitech. Da gibt's ja keine API, sondern eben dieses stupide runterrasseln der Kommandos.
Da war's dann natürlich insgesamt weniger (-60 Max, 7 auf passende Alarm-Lautstärke). Das lief dann auch in etwa 20 Sekunden durch, was verschmerzbar war. Aber jetzt mit dem Denon war's dann eben doch etwas extrem. Hab den auch erst neu, deswegen bin ich nach Eröffnung des Posts auf das Webinterface gestoßen und habe gesehen, dass dort die API schon klare Definitionen des Pegels erlaubt. Ist natürlich komfortabler und genauer, als erst leise und dann wieder lauter zu schalten.
In der Vergangenheit führte das hin und wieder entweder zu verschluckten oder zu oft interpretierten Kommandos.
Ist jetzt natürlich schon um einiges besser.

Danke für den Link, schaue ich mir nochmal genauer an. Das Modul ist aber standardmäßig gar nicht bei FHEM dabei gewesen. Gab's dafür einen Grund, oder ist meine Installation fehlerhaft?

[justme1968]

das möchte ich aber mal sehen das du eine taste auf der harmony mehr als 10x pro sekunde drückst.

du kannst in 37_harmony.pm mal in zeile 404 die 0.1 kleiner machen und eventuell in der nächsten zeile noch die 100 entsprechend anpassen.

wenn du verbose auf 4 setzt (oder in zeile 400 die 4 auf 3 oder kleiner setzt) solltest du sehen wie schnell die kommandos raus gehen. eventuell noch global mseclog setzen.

das verschlucken oder zu oft interpretieren ist genau das was passiert wenn du ir zu schnell sendest und was du über die diversen verzögerungen und wiederholungen auf harmony seite beeinflussen kannst. hast du die tastenverzögerung schon auf 0 und die wiederholungen auf 1 gesetzt?

[Thyrador]

Ich halte die Taste gedrückt, da wird der Befehl auch mehrfach gesendet (lässt sich prima mit ner Infrarot-Kamera beobachten )

Danke, das werde ich morgen mal probieren. Wenn's dann schneller geht, wäre das ja schonmal ein Anfang

Ne, die Verzögerungseinstellungen sind bisher von mir noch nicht verändert worden. War an sich auch so bisher nicht notwendig. Das Verschlucken/Doppeln kam bisher eher selten vor, also immer mal sporadisch. Das dürfte jetzt ja auch sowieso Geschichte sein, mit dem Denon, da hier ja jetzt statt 330 nur noch 5 Kommandos benötigt werden.

[justme1968]

das ist aber eine komplett
andere funktionalität die je nach gerät sogar mit anderen ir codes hinterlegt ist und bei der die harmony auch explizit andere verzögerungen einbaut. beim kurz drücken baut die harmony extra verzögerungen ein damit es das gerät nicht als long press interpretiert.

das harmony modul hat aktuell keine unterstützung für long press.

und das zählen geht so auch nicht sonder du gehst eher nach zeit. dafür bieten sich sequenzen in der harmony erst recht an. schau mal im harmony remote forum nach long volume down.

die direkte steuerung per ip ist auf jeden fall besser als ir.

[Thyrador]

Wie gesagt, das Steuern über die App, oder aus der Konsole heraus (einzelne API-calls an den Hub) geht halt auch schneller. Das war ja das, was mich so irritierte. Weil ich mir eben sicher bin, das FHEM auch nichts anderes machen wird.

Damit hab ich mich ehrlich noch nicht so auseinander gesetzt, also mit derartigen Sequenzen. Ich wusste jetzt auch bloß, wie man da eben als zusätzliche Schritte Funktionalitäten einbauen kann, was als einzelne Anweisungen eben 330 Kommandos ergibt. Und das ist halt schon echt extrem.

Ja, da gebe ich dir absolut Recht. Durch diesen einfachen Web-Aufruf (wahlweise dann auch mit dem Modul) ist das nicht nur komfortabler, sondern auch schneller und weniger anfällig für Fehler.
So gefällt mir das jetzt auch wieder, weil's jetzt insgesamt eben nur noch knapp 10 Sekunden, statt über ner Minute dauert. Und da geht jetzt die meiste Zeit für's Aufwärmen vom Denon und das Schalten der Steckdosen drauf.
Also in etwa die Zeit, um mich Kinogerecht in meinem Sessel zu fläzen

[Thyrador]

Hab das heute mal mit den Delays ausprobiert und festgestellt, dass sich hier nichts geändert hat. Auch ist mir aufgefallen, dass der Hub munter weiter macht, wenn ich FHEM aber schon komplett vom Netz genommen habe. Dann liegt's wohl doch am Hub selbst. Aktuell macht der gerade mal 2 Kommandos maximal pro Sekunde.

Ich denke damit ist das Thema dann im Grunde auch erledigt, da es so nachweislich doch nicht an FHEM liegt.

Danke trotzdem an Alle für die Hilfe


NACHTRAG: Leider lässt sich das auch über die Verzögerungseinstellungen des Gerätes (im Hub) nicht beeinflussen. Schade.