YAMAHA_AVR Verzögerungen

Begonnen von vbs, 05 November 2015, 13:36:33

Vorheriges Thema - Nächstes Thema

dev0

Zitat von: Markus Bloch am 23 Dezember 2015, 11:28:29
Evtl. hilft es ja, das ganze mal mit der Yamaha-App nachzustellen und im Wireshark zu tracen. Vielleicht sieht man ja da was anderes. Von der Spezifikationslage und den Antworten sieht das aber alles valide aus, auch für die 0.
Du hast Recht, die Werte werden im Amp korrekt gesetzt. Nur in den Readings stehen die falschen Werte. Das ist auch kein neues Problem, da mit dieser Version der Fehler auch schon auftritt:
# $Id: 71_YAMAHA_AVR.pm 9365 2015-10-04 11:26:22Z markusbloch $

Davor hatte ich die Version benutzt, aus der ich den Patch zur Tonsteuerung generiert hatte. Damit tritt der Effekt nicht auf.
Wenn es hilft herauszufinden seit welcher Version das auftritt, kann ich gerne ältere Versionen testen. Dazu müsstest Du mir nur verraten wie ich aus Sourceforge ältere Versionen herausholen kann oder einfach hier anhängen.

Markus Bloch

Nunja, an der Bass-Steuerung wurde ja seit der Einbringung generell nichts verändert. Die hatte ich ja fast ungeändert übernommen und seitdem nicht mehr angefasst.

Ich habe mal Logmeldungen bei der Readings-Generierung eingebracht, damit man mal genauer sieht wo er bei den If-Abzweigungen lang geht.

Bitte probier nochmal mit bass 0 und bass 3 und poste nochmal die Logs.

Danke

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

dev0

Zitat von: Markus Bloch am 23 Dezember 2015, 13:25:43
Nunja, an der Bass-Steuerung wurde ja seit der Einbringung generell nichts verändert.

Es gab noch diese Änderung hier.
Anbei das Log mit bass 3/0

Markus Bloch

#63
Fehler gefunden. Hüllen wir den Mantel des Schweigens darüber:   ( if($2)   !=   if(defined($2)) )

EDIT: Andere Frage. Warum hast du folgende Zeilen bei deinem Tone-Patch damals mit eingebracht? Ich versteh noch nicht so ganz was die bringen sollen:


                    $bassVal-- if (($bassVal % 2 != 0) && ($bassVal > 0));
                    $bassVal++ if (($bassVal % 2 != 0) && ($bassVal < 0));


                    $trebleVal-- if (($trebleVal % 2 != 0) && ($trebleVal > 0));
                    $trebleVal++ if (($trebleVal % 2 != 0) && ($trebleVal < 0));
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

dev0

Hi Markus,

jetzt funktioniert es wie es soll, auch weitere Tests mit komplexere Kommandoketten wurden korrekt abgearbeitet. Beim DSP Modell reicht ein on/off Delay von 3 Sekunden aus. Vielleicht magst Du das noch ändern.

Die Modulo-Division soll testen ob der Wert gerade ist, damit bei nicht-DSP Modellen, in den zusätzlichen Zonen, nur gerade Werte gesetzt werden. Wenn die Werte nicht gerade sind, dann wird 1 addiert/subtrahiert je nachdem ob der Wert positiv oder negativ ist um nicht aus dem Wertebereich zu laufen. Laut Spec zum RX-Vx73 beträgt die Schrittweite 20 (2db) und der Bereich +-100 (10db).
Kann man das eleganter lösen?

Vielen Dank für Deine Mühe.
Gruß und noch ein frohes Fest
Uli

Btw: Hast Du vielleicht noch eine Idee wie man feststellen kann ob die command queue abgearbeitet ist?

Markus Bloch

Hi Uli,

Zitat von: dev0 am 25 Dezember 2015, 10:30:45
Hi Markus,

jetzt funktioniert es wie es soll, auch weitere Tests mit komplexere Kommandoketten wurden korrekt abgearbeitet. Beim DSP Modell reicht ein on/off Delay von 3 Sekunden aus. Vielleicht magst Du das noch ändern.


Habe ich geändert.

Zitat von: dev0 am 25 Dezember 2015, 10:30:45
Die Modulo-Division soll testen ob der Wert gerade ist, damit bei nicht-DSP Modellen, in den zusätzlichen Zonen, nur gerade Werte gesetzt werden. Wenn die Werte nicht gerade sind, dann wird 1 addiert/subtrahiert je nachdem ob der Wert positiv oder negativ ist um nicht aus dem Wertebereich zu laufen. Laut Spec zum RX-Vx73 beträgt die Schrittweite 20 (2db) und der Bereich +-100 (10db).
Kann man das eleganter lösen?

Ah stimmt. Danke für den Hinweis. Habe ich als Kommentar mal aufgenommen, damit ich das später noch weis ;-)

Passt schon deine Lösung. Grundsätzlich viel anders würde ich es auch nicht machen, von daher bleibt es so wie es ist. Ich musste nur für mich als Erinnerung einen Kommentar anfügen, warum das dort gemacht werden muss, weil sonst frag ich in ein paar Monaten wieder ;-)

Zitat von: dev0 am 25 Dezember 2015, 10:30:45

Vielen Dank für Deine Mühe.
Gruß und noch ein frohes Fest
Uli

Btw: Hast Du vielleicht noch eine Idee wie man feststellen kann ob die command queue abgearbeitet ist?

Das ist ganz einfach. Siehst du beispielhaft in der Funktion YAMAHA_AVR_getNextRequestHash(). Ich prüfe ob der skalare Kontext ungleich 0 ist, dann sind Elemente enthalten.
    if(@{$hash->{helper}{CMD_QUEUE}} != 0)
    {
         # queue enthält items
    }
    else
    {
        # queue leer/abgearbeitet
    }


Ich werde die Änderungen im Laufe des Tages einchecken. Nun sollte ja alles komplett funktionieren.

Viele Grüße, vielen Dank und noch besinnliche Feiertage.

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Zitat von: dev0 am 25 Dezember 2015, 10:30:45
Btw: Hast Du vielleicht noch eine Idee wie man feststellen kann ob die command queue abgearbeitet ist?

Hab ich evtl. gerade etwas missverstanden. Wenn du einfach nur optisch in der Detail-Seite sehen willst, ob die Queue abgearbeitet ist, kannst du einfach auf die Internals schauen. Wenn dort "CMDs_pending" mit einer Zahl gesetzt ist, siehst du dort die Anzahl der anstehenden Request, welche in der Queue sind. Sind aber im Normalfall innerhalb von Millisekunden abgearbeitet und dieser Eintrag in diesem Fall nicht vorhanden.

Alternativ könnte man noch ein Get-Befehl einbauen, der die Anzahl der Requests in der Queue zurückgibt. Sollte einen User im Normalfall aber eigentlich nicht interessieren.

Die Änderungen sind nun auch vollständig eingecheckt.

Viele Grüße

Markus

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

dev0

Zitat von: Markus Bloch am 25 Dezember 2015, 13:14:24
Wenn dort "CMDs_pending" mit einer Zahl gesetzt ist
Das mit den Internals ist für mich erst einmal definitiv einfacher. Ich wüsste im Moment nicht, wie ich aus einer eigenen Funktion heraus, über den Namen, den Hash eines Devices ermitteln kann.
Hintergrund ist folgender: Um Ansagen beim Eintreffen oder Verlassen des Hauses ausgeben zu können, wollte ich prüfen wann der Amp bereit ist, um die Ansage nicht halb zu verschlucken, da vielleicht noch nicht der richtige Input gesetzt ist. Ein festes Delay würde aber zB. zu einer unnötig langen Unterbrechung der Musik führen, wenn welche läuft.

Markus Bloch

Zitat von: dev0 am 25 Dezember 2015, 14:23:43
Das mit den Internals ist für mich erst einmal definitiv einfacher. Ich wüsste im Moment nicht, wie ich aus einer eigenen Funktion heraus, über den Namen, den Hash eines Devices ermitteln kann.
Hintergrund ist folgender: Um Ansagen beim Eintreffen oder Verlassen des Hauses ausgeben zu können, wollte ich prüfen wann der Amp bereit ist, um die Ansage nicht halb zu verschlucken, da vielleicht noch nicht der richtige Input gesetzt ist. Ein festes Delay würde aber zB. zu einer unnötig langen Unterbrechung der Musik führen, wenn welche läuft.

So genau würde ich es an deiner Stelle nicht machen. Die Queue würde ich da jetzt nicht mit einbeziehen. Wir reden hier von einer max. Verzögerung von unter 1 Sekunde sollte ein vollständiger statusRequest in der Queue vorhanden sein. Sobald Kommandos ja in der Queue vorhanden sind, werden die ohne weitere Verzögerungen direkt abgearbeitet (bis auf on/off). Das geschieht in Millisekunden.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)