YAMAHA_AVR Verzögerungen

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

Vorheriges Thema - Nächstes Thema

dev0

Hi Markus,

anbei schon mal das Log des Restart mit verbose 5 der AVR Zonen.
Über die Queue Steurung würde ich gerne noch einen Moment nachdenken, komme gerade nicht dazu.

Schlimbo

Hi Markus,
Danke für die neue Version, funktioniert bei mir bestens.

im Log habe ich aber eine Meldung:
2015.12.11 13:05:39 1: PERL WARNING: Odd number of elements in anonymous hash at ./FHEM/71_YAMAHA_AVR.pm line 1627, <GEN39> line 312.

Beim "RX-V773"  gibt es keine Probleme,  wenn beide Zonen gleichzeitig eingeschaltet  werden:
set AV_Receiver on; set AV_Receiver_Zone2 on; set AV_Receiver input netradio;set AV_Receiver_Zone2 input netradio;set AV_Receiver navigateListMenu Hinzugefügten/Old
--> Beide Zonen werden eingeschalten

Zitat von: Markus Bloch am 10 Dezember 2015, 22:54:37
Ich habe auch schonmal an der Commandref gearbeitet und den Teil mit dem Netradio-Beispiel via remoteControl-Befehle entfernt und durch den im Anhang befindlichen Teil ersetzt.

Schaut mal bitte drüber, ob man das so als normalsterblicher versteht. Passt das soweit, würde ich es in Deutsch nochmal verfassen.
Ist sehr verständlich geschrieben, denke damit ist klar erklärt, wie die Funktion zu nutzen ist.

Gruß Schlimbo


Markus Bloch

Zitat von: dev0 am 11 Dezember 2015, 12:30:23
Hi Markus,

anbei schon mal das Log des Restart mit verbose 5 der AVR Zonen.
Über die Queue Steurung würde ich gerne noch einen Moment nachdenken, komme gerade nicht dazu.

In deinem Log sieht man überall:


2015.12.11 12:04:50.127 5: YAMAHA_AVR (WZ_AMP) - could not execute command "statusRequest unitDescription": connect to to http://192.168.30.52:80 timed out

2015.12.11 12:04:50.142 5: YAMAHA_AVR (KU_AMP) - could not execute command "statusRequest unitDescription": connect to to http://192.168.30.52:80 timed out

2015.12.11 12:04:50.166 5: YAMAHA_AVR (BA_AMP) - could not execute command "statusRequest unitDescription": connect to to http://192.168.30.52:80 timed out


Das kann daran liegen, dass alle Zonen fast zeitgleich nur wenige Millisekunden versetzt versuchen, die Konfiguration des Receivers zu erfragen. Sicher bin ich mir allerdings nicht. Dannach funktioniert es ja wieder sofort.

Könnte sein, dass man das mit der Zusammenlegung der Queues lösen könnte. Versprechen, kann ich es aber nicht.

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 11 Dezember 2015, 11:09:00
1. Wenn eine Zone ein Kommando absetzt, was ein anschließendes Delay benötigt (aktuell "on" und "off"), dann werden entsprechende Delays in allen Zonen in deren Queue eingebracht. Die Queues halten sich dann auch jeweils separat an dieses Delay und arbeiten erst weiter, wenn diese jeweils einzeln verstrichen sind.
Bis jetzt wissen wir, dass on/off ein Delay benötigt. Gut. Wie sieht es aus, wenn z.B. eine Sonosdruchsage gemacht werden soll und in allen Zonen die Inputs und Lautstärke geändert werden muss. Ich vermute, dass bei der ersten Variante sich die Queues auch wieder in die Quere kommen, da sie direkt nacheinander befeuert werden und unabhängig von einander an den Amp schicken. Ich habe es aber noch nicht ausprobieren können, geht erst am Morgen wieder. Variante 2 würde dieses Problem, wenn es besteht mMn auch lösen.

Ah... sehe Du hast gerade geantwortet und das bestätigt auch meine Vermutung, das eine Queue die beste Lösung ist.

Markus Bloch

Zitat von: dev0 am 11 Dezember 2015, 15:48:43
Bis jetzt wissen wir, dass on/off ein Delay benötigt. Gut. Wie sieht es aus, wenn z.B. eine Sonosdruchsage gemacht werden soll und in allen Zonen die Inputs und Lautstärke geändert werden muss. Ich vermute, dass bei der ersten Variante sich die Queues auch wieder in die Quere kommen, da sie direkt nacheinander befeuert werden und unabhängig von einander an den Amp schicken. Ich habe es aber noch nicht ausprobieren können, geht erst am Morgen wieder. Variante 2 würde dieses Problem, wenn es besteht mMn auch lösen.

Ah... sehe Du hast gerade geantwortet und das bestätigt auch meine Vermutung, das eine Queue die beste Lösung ist.

Das würde ich aber gerne separat umsetzen. Die ganzen Änderungen, die wir jetzt hier im Rahmen dieses Threads gemacht haben, möchte ich erstmal gerne einchecken. Anschließend würde ich mich nochmal hinsetzen und die Queues für Mehrzonen-Geräte zu einer zusammenführen.

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

Macht sinn. Wenn ich etwas testen soll oder ich dich sonst irgendwie unterstützen kann, dann sag einfach bescheid.

Markus Bloch

Hallo zusammen,

die Änderungen sind nun eingecheckt und stehen ab morgen zur Verfügung.

Hiermit sollten nun viele Probleme der Vergangenheit angehören. Das Modul YAMAHA_AVR macht nun nichts blockierendes mehr (bis auf die DNS Auflösung) und sollte somit nun keine Probleme im Ablauf von FHEM verursachen (was ja der eigentliche Aufhänger für diesen Thread ja war).

Vielen Dank an alle für die Unterstützung beim testen und ausprobieren.

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)

Markus Bloch

Zitat von: Schlimbo am 11 Dezember 2015, 13:44:01
im Log habe ich aber eine Meldung:
2015.12.11 13:05:39 1: PERL WARNING: Odd number of elements in anonymous hash at ./FHEM/71_YAMAHA_AVR.pm line 1627, <GEN39> line 312.

Hallo Schlimbo,

ist mit dem update morgen ebenfalls behoben. War ein Copy-Paste-Vergesser.

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)

vbs

Sorry, ich hatte leider noch keine Gelegenheit, mich mit den Änderungen so wirklich auseinander zu setzen. Aber ich habe seit dem Update heute folgende Warning beim Start (letzte Zeile):

2015.12.12 12:45:08 0: Featurelevel: 5.7
2015.12.12 12:45:08 0: Server started with 297 defined entities (fhem.pl:10116/2015-12-06 perl:5.020002 os:linux user:fhem pid:2883)
2015.12.12 12:45:08 1: Perfmon: possible freeze starting at 12:45:02, delay is 6.294
2015.12.12 12:45:08 3: YAMAHA_AVR (wz_avr) - could not execute command on device wz_avr. Please turn on your device in case of deactivated network standby or check for correct hostaddress.
2015.12.12 12:45:08 1: HMLAN_Parse: HMLAN0 new condition ok
2015.12.12 12:45:08 3: onKuSqueezebox: ku_sb -> off
2015.12.12 12:45:08 3: get wz_avr mute : off
2015.12.12 12:45:08 1: openelec:9090 reappeared (wz_xbmc)
2015.12.12 12:45:08 1: openelec:9090 reappeared (wz_xbmc)
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set ku_lightSpot 0 0 10
2015.12.12 12:45:08 3: CUL_HM set ku_lightSpot 0 0 10
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set sz_lightLava off
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set sz_lightAmbient 0 0 10
2015.12.12 12:45:08 3: CUL_HM set sz_lightAmbient 0 0 10
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set sz_lightSpot 0 0 10
2015.12.12 12:45:08 3: CUL_HM set sz_lightSpot 0 0 10
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set wz_lightLedStripe HSV 0,0,0 10
2015.12.12 12:45:08 3: wz_lightLedStripe set HSV 0, 0, 0 with ramp: 10, flags:
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set wz_lightRed 0 0 10
2015.12.12 12:45:08 3: CUL_HM set wz_lightRed 0 0 10
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set wz_lightDesk 0 0 10
2015.12.12 12:45:08 3: CUL_HM set wz_lightDesk 0 0 10
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set wz_lightCrystal 0 0 10
2015.12.12 12:45:08 3: CUL_HM set wz_lightCrystal 0 0 10
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set fl_lightCrystal 0 0 10
2015.12.12 12:45:08 3: CUL_HM set fl_lightCrystal 0 0 10
2015.12.12 12:45:08 3: SMARTLIGHTS: submitting command: set fl_lightChain 0 0 10
2015.12.12 12:45:08 3: CUL_HM set fl_lightChain 0 0 10
2015.12.12 12:45:08 3: YAMAHA_AVR (wz_avr) - device wz_avr reappeared
2015.12.12 12:45:08 1: PERL WARNING: Use of uninitialized value $zone in concatenation (.) or string at ./FHEM/71_YAMAHA_AVR.pm line 1148.

Markus Bloch

Habe ich gefixt. Gibt es morgen.

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)

Markus Bloch

Zitat von: dev0 am 11 Dezember 2015, 16:44:17
Macht sinn. Wenn ich etwas testen soll oder ich dich sonst irgendwie unterstützen kann, dann sag einfach bescheid.

Teste doch bitte mal die angehangene Version. In dieser sind die Queues der Zonen verschmolzen. Sobald für ein physisches Device (Erkennung anhand der System-Id) eine Main-Zone definiert ist, werden die Unterzonen (Zone 2, 3, 4) ihre Kommandos in die Queue der Main-Zone einbringen. Die Rückmeldungen der Antworten werden aber wieder von der Unterzone verarbeitet.

Dabei ist es jedoch so, dass beim Starten von FHEM jede Zone erstmal individuell und selbstständig die Systemkonfiguration des Receivers abfragt. Sobald die gewählte Zone verifiziert wurde und die System-ID zur Verfügung steht wird ab da an geprüft, ob eine Main-Zone definiert ist. Falls ja, wird von da an alle weiteren Befehle über die Main-Zone abgewickelt. Somit gibt es beim Start pro Zone jeweils 2 Requests die von den Zonen-Definitionen eigenständig durchgeführt werden.

Sobald die Main-Zone nicht mehr definiert sein soll, werden die Kommandos augenblicklich wieder auf eigene Faust durchgeführt.



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)

Schlimbo

#41
Hallo Markus,
Seit dem gestrigen Update funktioniert die Lautstärke Änderung nicht mehr.
Es muss etwas mit der "smooth" Funktion zu tun haben, setzte ich "volume-smooth-change"  auf 0 funktioniert es wieder.

Log:
2015.12.16 06:30:45 3: YAMAHA_AVR (AV_Receiver) - Could not execute "volume -89.5": received return code 3

Kannst du das bitte mal checken?

Danke

Gruß
Schlimbo

dev0

Zitat von: Markus Bloch am 15 Dezember 2015, 23:56:16
Teste doch bitte mal die angehangene Version. In dieser sind die Queues der Zonen verschmolzen.

Moin Markus,

leider läßt sich mit dieser Version keine Zone weder ein- noch ausschalten.
Log anbei.

/Uli

Markus Bloch

Zitat von: Schlimbo am 16 Dezember 2015, 06:49:47
Hallo Markus,
Seit dem gestrigen Update funktioniert die Lautstärke Änderung nicht mehr.
Es muss etwas mit der "smooth" Funktion zu tun haben, setzte ich "volume-smooth-change"  auf 0 funktioniert es wieder.

Log:
2015.12.16 06:30:45 3: YAMAHA_AVR (AV_Receiver) - Could not execute "volume -89.5": received return code 3

Kannst du das bitte mal checken?

Danke

Gruß
Schlimbo

Ja, da habe ich mal wieder gekonnt ignoriert, dass ja Punktrechnung vor Strichrechnung gilt. Die Grundschule ist eben auch schon eine Weile her. Ist morgen wieder funktionsfähig.

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)

Markus Bloch

Zitat von: dev0 am 16 Dezember 2015, 08:48:39
Moin Markus,

leider läßt sich mit dieser Version keine Zone weder ein- noch ausschalten.
Log anbei.

/Uli

Nächster Versuch. Ist leider etwas fummelig.

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)