Modul für ONKYO AV Receiver (und neuere Pioneer AV Receiver)

Begonnen von Loredo, 30 September 2013, 14:52:36

Vorheriges Thema - Nächstes Thema

bense2k

Danke nach der installation von XML::Simple scheint es zu funktionieren.

Andy89

Zitat von: Loredo am 29 Mai 2016, 18:30:36
Das scheint mir wie gesagt ein Firmware Bug zu sein; der ONKYO liefert ein fehlerhaftes XML mit doppelten Einträgen.

hmm, womit ruf ich denn die Informationen ab, dann prüf ich mal was ankommt und guck mal was den Fehler hervorruft.

Meine Firmware Version ist die 1050-2030-0102, falls das etwas bringt
FHEM 6.0 auf rPi4 docker (mit Alexa & Siri); dbLog, FTUI, Sonos, XiaomiMapCreator auf rPi4 docker;
raspimatic auf rPi3+ > diverse Aktoren und Sensoren;
LGW > (PCA301),EC3000,LaCrosse; MQTT2 > WLAN-Steckdosen,Xiaomi Map;
Harmony Hub;Sonos;Onkyo AVR;RGB WLAN Controller;Netatmo;Withings;Unifi;AMAD

Loredo

Ich habe gestern Abend noch eine Version eingecheckt mit dem Versuch die XML Fehler nur als Warnung zu verarbeiten.


Mehr kann man nicht tun; die doppelten Einträge im XML sind ein Firmware Bug, den Onkyo beheben müsste.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Thargor


Gibt es eigentlich eine Möglichkeit das Modul temporär zu deaktivieren oder zumindest die Funktion ONKYO_AVR_Ready ?
Hintergrund: Der Onkyo hängt an einer Schaltsteckdose, solange die Steckdose nicht an ist, braucht das Modul auch nicht übers Netzwerk zu suchen.
Ich habe es mit DISABLE probiert, aber das scheint nicht zu wirken. Das Attribut ConnectionCheck kommt vermutlich auch nicht vom Onkyo?

krannich

Nach dem ich gestern den Stecker gezogen habe ging es für kurze Zeit.
Heute Nacht lief das Log wieder mit Fehlermeldungen voll:

2016.05.30 01:14:31 2: AVR: second attempt to read timed out, this is an unrecoverable error.
2016.05.30 01:16:01 2: AVR: first attempt to read timed out, trying to close and open the device.
2016.05.30 01:16:01 3: Opening AVR device 192.168.1.40:60128
2016.05.30 01:16:04 3: Can't connect to 192.168.1.40:60128: No route to host

Gibt es die Möglichkeit ein Onkyo-Legacy-Modul zu erstellen (gerne ohne weiteren Support) so dass die Funktionalität von vor ein paar Wochen wieder hergestellt wird?

Gerne kann ich hier auch unterstützen, wenn Du mir sagst, was ich grob zu tun hätte. Programmieren kann ich, PERL ist nicht ganz mein Steckenpferd.

Viele Grüße
Dennis

Loredo

Zitat von: Thargor am 30 Mai 2016, 16:38:50
Gibt es eigentlich eine Möglichkeit das Modul temporär zu deaktivieren oder zumindest die Funktion ONKYO_AVR_Ready ?
Hintergrund: Der Onkyo hängt an einer Schaltsteckdose, solange die Steckdose nicht an ist, braucht das Modul auch nicht übers Netzwerk zu suchen.
Ich habe es mit DISABLE probiert, aber das scheint nicht zu wirken. Das Attribut ConnectionCheck kommt vermutlich auch nicht vom Onkyo?


Die Funktion ONKYO_AVR_Ready wird nicht vom Modul selbst aus aufgerufen, sie ist (wohl) nur für Windows notwendig, um eingegangene Daten zu verarbeiten.


Das Attribut connectionCheck kann auf "off" gesetzt werden, damit bei unterbrochener Verbindung nicht mehr versucht wird diese herzustellen.


Zitat von: krannich am 30 Mai 2016, 18:35:47
Nach dem ich gestern den Stecker gezogen habe ging es für kurze Zeit.
Heute Nacht lief das Log wieder mit Fehlermeldungen voll:
Gibt es die Möglichkeit ein Onkyo-Legacy-Modul zu erstellen (gerne ohne weiteren Support) so dass die Funktionalität von vor ein paar Wochen wieder hergestellt wird?


Nein, diese Möglichkeit gibt es nicht und sie macht auch keinen Sinn. Wenn der Receiver auf dem Port keine Verbindung (mehr) annimmt, dann gilt das auch für jedes andere Modul oder Netzwerkgerät, auch außerhalb von Fhem. Ich bin sicher du kannst auch sonst keine Verbindung zu dem Port herstellen (gemeint ist kein Ping! Das ist kein wirklicher Verbindungstest... man muss ein Telnet auf Port 60128 machen können).
Das ist ein Problem des Receivers und im Zweifel ein Firmware Bug. Die aktuellste Firmware zu installieren brauche ich wohl nicht extra empfehlen hoffe ich  ;)  Auch ein Reset auf Werkseinstellungen kann u.U. helfen, sowas sollte man ebenfalls probieren.


Auch gilt es zu beachten, dass maximal 5 gleichzeitige Verbindungen zum Onkyo Receiver möglich sind. Darüber hinaus kann es sein, dass der Receiver so reagiert wie du es beschreibst. Das neue Fhem Modul baut genau eine einzige Verbindung dauerhaft auf und versucht diese erneut aufzubauen, sofern sie verloren gegangen ist. Alle Programme oder Geräte, die deinen Onkyo sonst noch steuern, kommen noch oben drauf.
Das alte Modul war hier im Nachteil, weil es für jeden Befehl jedes Mal eine neue Verbindung aufgebaut hat. Dem Eindruck nach sind manche Firmware etwas buggy/empfindlich und schließen Verbindungen nicht immer richtig und lassen dann irgendwann keine neue Verbindung mehr zu, bis man das Gerät kurz vom Strom trennt, damit die Software im Onkyo wieder neu hochfährt. So etwas mag bei dir der Fall sein.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

krannich

Danke für die schnelle Antwort. Super!

Also ich habe noch einmal die neuste Firmware aufgespielt – war wirklich eine Version hinterher.
Zusätzlich habe ich das Attribut connectionCheck auf off gesetzt.
Mal schauen was passiert.

Über Umwege habe ich es auch hinbekommen Dein "altes" Modul (10857) umzubenennen.
Habe alle ONKYO-Vorkommnisse in dkONKYO umbenannt.
Damit funktioniert es dann wieder problemlose.
Dennoch erhalte ich ein paar Fehlermeldungen so wie diese hier

PERL WARNING: Subroutine dkONKYO_AVR_Initialize redefined at ./FHEM/99_dkONKYO_AVR.pm line 62, <$fh> line 8.

Naja, aber es soll ja nicht Sinn und Zweck sein Dein "altes" Modul zu verunstalten.
Ich werde berichten was passiert.

Viele Grüße
Dennis

Andy89

Zitat von: Loredo am 30 Mai 2016, 08:57:49
Ich habe gestern Abend noch eine Version eingecheckt mit dem Versuch die XML Fehler nur als Warnung zu verarbeiten.


Mehr kann man nicht tun; die doppelten Einträge im XML sind ein Firmware Bug, den Onkyo beheben müsste.

Vielen Dank dafür! Nun funktioniert mein AVR wieder ohne Probleme. Steuerung funktioniert. Anlegen einer zweiten Zone mittel createZone 2 läuft und funktioniert auch! Ein statusRequest lässt mein fhem nun auch nicht mehr abstürzen  :) :) :)


etwas könnte dich evtl interessieren:
PERL WARNING: Use of uninitialized value in string ne at ./FHEM/70_ONKYO_AVR.pm line 1526.

Danke nochmal  :) :) :) :)
Nun kann die Musik in Zone  2 wieder alleine starten, wenn ich morgens die Küche betrete. Und die Musik kann in Zone 1 starten, wenn ich nach der Arbeit heimkomme  :) :) :) :) :)

Beste Grüße
Andy
FHEM 6.0 auf rPi4 docker (mit Alexa & Siri); dbLog, FTUI, Sonos, XiaomiMapCreator auf rPi4 docker;
raspimatic auf rPi3+ > diverse Aktoren und Sensoren;
LGW > (PCA301),EC3000,LaCrosse; MQTT2 > WLAN-Steckdosen,Xiaomi Map;
Harmony Hub;Sonos;Onkyo AVR;RGB WLAN Controller;Netatmo;Withings;Unifi;AMAD

Thargor

Zitat von: Loredo am 30 Mai 2016, 19:01:30

Die Funktion ONKYO_AVR_Ready wird nicht vom Modul selbst aus aufgerufen, sie ist (wohl) nur für Windows notwendig, um eingegangene Daten zu verarbeiten.
Das Attribut connectionCheck kann auf "off" gesetzt werden, damit bei unterbrochener Verbindung nicht mehr versucht wird diese herzustellen.


Vielen Dank für die schnelle Antwort.

Ich habe connectionCheck auf off gesetzt. Bei mir läuft FHEM auf einem Synology NAS, also unter Linux und trotzdem wird weiterhin munter (und ziemlich häufig) die Funktion ONKYO_AVR_Ready aufgerufen, die laut apptime auch mal 3s lang "arbeitet". Was macht die Funktion denn?



1of16

Leider habe ich immer noch massive Probleme mit meinem TX-NR515.

Wenn ich die Steckdose anschalte, merkt das Modul zwar, dass der AVR wieder verfügbar sein müsste (die Logmeldungen hören auf), aber anschalten oder gar steuern kann ich den  meist AVR nicht. Manchmal dann doch wieder, aber dann spamt er folgende Meldung:
SW: 49534350000000100000000a0100000021315057525153544e0d
Erst wenn ich das Device löschen und neu anlege erkennt er den AVR wieder, so dass man ihn steuern kann.
Die Logmeldungen sehen auch nicht wirklich gut aus:
2016.05.31 19:17:46.626 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:17:46.779 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:17:46.781 3: ONKYO_AVR set avr on
2016.05.31 19:17:46.781 5: ONKYO_AVR avr: called function ONKYO_AVR_SendCommand()
2016.05.31 19:17:46.781 4: ONKYO_AVR avr: snd power -> on (PWR01)
2016.05.31 19:17:46.782 5: ONKYO_AVR avr: 192.168.1.97:60128 snd ISC!1PWR01
2016.05.31 19:17:46.782 5: SW: 49534350000000100000000801000000213150575230310d
2016.05.31 19:17:47.535 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:17:47.687 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:17:47.702 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:17:47.798 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:17:47.880 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:17:52.416 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:17:52.434 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:17:52.436 3: ONKYO_AVR set avr input pc
2016.05.31 19:17:52.438 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:17:52.440 3: ONKYO_AVR set avr on
2016.05.31 19:17:52.440 5: ONKYO_AVR avr: called function ONKYO_AVR_SendCommand()
2016.05.31 19:17:52.441 4: ONKYO_AVR avr: snd power -> on (PWR01)
2016.05.31 19:17:52.442 5: ONKYO_AVR avr: 192.168.1.97:60128 snd ISC!1PWR01
2016.05.31 19:17:52.442 5: SW: 49534350000000100000000801000000213150575230310d
2016.05.31 19:17:52.445 5: ONKYO_AVR avr: called function ONKYO_AVR_SendCommand()
2016.05.31 19:17:52.446 4: ONKYO_AVR avr: snd input -> pc (SLI05)
2016.05.31 19:17:52.446 5: ONKYO_AVR avr: 192.168.1.97:60128 snd ISC!1SLI05
2016.05.31 19:17:52.446 5: SW: 495343500000001000000008010000002131534c4930350d
2016.05.31 19:17:54.518 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:17:54.519 3: ONKYO_AVR set avr volume 10
2016.05.31 19:17:54.520 3: avr_volume: Device needs to be ON to adjust volume.
2016.05.31 19:17:57.557 5: ONKYO_AVR avr: raw 49534350000000100000000a01000000213150575230311a0d0a49534350000000100000000a01000000213150575230311a0d0a49534350000000100000000a010000002131534c4930351a0d0a ISCP............!1PWR01...ISCP............!1PWR01...ISCP............!1SLI05...
2016.05.31 19:17:57.558 5: ONKYO_AVR avr: con power(PWR01): return zone1 value '01' converted through VALUE from HASH table to 'on'
2016.05.31 19:17:57.559 4: ONKYO_AVR avr: rcv power = on
2016.05.31 19:17:57.730 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:17:57.734 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:17:57.738 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:17:57.742 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:18:05.223 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:18:06.756 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:18:06.882 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:18:06.987 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:18:07.001 5: ONKYO_AVR avr: called function ONKYO_AVR_Set()
2016.05.31 19:18:07.006 5: ONKYO_AVR avr: called function ONKYO_AVR_Get()
2016.05.31 19:18:07.028 5: SW: 49534350000000100000000a0100000021315057525153544e0d
2016.05.31 19:18:35.942 4: ONKYO_AVR avr: volume - Warning, value '02' not found in HASH table, will be sent to receiver 'as is'
2016.05.31 19:18:35.942 4: ONKYO_AVR avr: snd volume -> 02 (MVL02)
2016.05.31 19:18:35.943 5: ONKYO_AVR avr: 192.168.1.97:60128 snd ISC!1MVL02


Die neuste Version deines Moduls ist nach einem Restart geladen:
File            Rev   Last Change
70_ONKYO_AVR.pm 11558 2016-05-29 16:47:13Z loredo

Der AVR nutzt natürlich auch die neuste Firmware.

Da diese massiven Probleme wohl nur mit den pre2013 Versionen bestehen, würde meine Frage auch zu einem gesonderten "pre2013" Modul auf der alten Basis abzielen, damit lief ja noch alles wunderbar...
Und der WAF sinkt gerade ins bodenlose...das kann ich mir nicht leisten ;)

Grüße
Philip
FHEM in einem Dockercontainer
VCCU mit 3x HM-MOD-UART und 1x HmLGW
1x CCU2
2x nanoCUL 433MHz, 3x RPi3, Unifi-Controller mit drei APs für presence und Unifi Protec
div. weitere HM, ein paar HmIP Geräte und div. Shellys

Loredo

Zitat von: Thargor am 31 Mai 2016, 13:48:20
Ich habe connectionCheck auf off gesetzt. Bei mir läuft FHEM auf einem Synology NAS, also unter Linux und trotzdem wird weiterhin munter (und ziemlich häufig) die Funktion ONKYO_AVR_Ready aufgerufen, die laut apptime auch mal 3s lang "arbeitet". Was macht die Funktion denn?


Ich weiß nicht genau, wann Fhem die ReadyFn aufruft. Das ist eine DevIo Angelegenheit und außerhalb meines Einflussbereiches. Ich kann das von dir beschriebene Verhalten nicht nachstellen.


Zitat von: 1of16 am 31 Mai 2016, 19:23:45
Wenn ich die Steckdose anschalte, merkt das Modul zwar, dass der AVR wieder verfügbar sein müsste (die Logmeldungen hören auf), aber anschalten oder gar steuern kann ich den  meist AVR nicht. Manchmal dann doch wieder,


Du schickst vermutlich mehrere Befehle hintereinander, das funktioniert nicht. Du musst warten, bis die Rückmeldung des power=on Kommandos eingetroffen ist und das Reading auf "on" gewechselt hat. Deshalb stehen da auch Meldungen wie "Device needs to be ON to adjust volume.", die du wohl überlesen hast. Probier doch erstmal die manuelle Steuerung, bevor du ein Script schreibst.


Zitat von: 1of16 am 31 Mai 2016, 19:23:45
aber dann spamt er folgende Meldung:
SW: 49534350000000100000000a0100000021315057525153544e0d


Diese Meldung erzeugt Fhem/DevIo. Es handelt sich um eine Debug Meldung, weil du auf Verbose=5 gesetzt hast. Die ganzen Meldungen sind dann also gewollt und völlig normal. Setze verbose=3 und die Meldungen hören auf.


Die restlichen Logmeldungen sind alle ganz normal, nichts anormales dabei.


Zitat von: 1of16 am 31 Mai 2016, 19:23:45
Da diese massiven Probleme wohl nur mit den pre2013 Versionen bestehen, würde meine Frage auch zu einem gesonderten "pre2013" Modul auf der alten Basis abzielen, damit lief ja noch alles wunderbar...


Ich kann keine Schwierigkeiten seitens des Moduls erkennen. Du verwendest es einfach falsch, das ist alles.


Zitat von: 1of16 am 31 Mai 2016, 19:23:45
Und der WAF sinkt gerade ins bodenlose...das kann ich mir nicht leisten ;)


Dafür kann ich nun wirklich nichts...  ???
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

#446
Ich habe gerade eine aktualisierte Version eingecheckt, welche sich explizit um die Steuerung von Bass, Treble und der dedizierten Lautstärke für Center und Subwoofer kümmert. Zudem funktioniert Preset für die Radio Stationen nun.

Die Setter dazu werden eingeblendet, wenn man einmalig den aktuellen Tone-Wert über ein get-Kommando eingelesen hat.
Also z.B.:


get AVR remoteControl tone-front
get AVR remoteControl center-temporary-level
get AVR remoteControl subwoofer-temporary-level


Die anderen tone-* Befehle werden nicht unbedingt von jedem Receiver unterstützt. Wenn man sie abschickt, jedoch keine neuen Readings erzeugt werden, dann unterstützt der Receiver die Steuerung nicht.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

1of16

Zitat von: Loredo am 31 Mai 2016, 20:50:27
Du schickst vermutlich mehrere Befehle hintereinander, das funktioniert nicht. Du musst warten, bis die Rückmeldung des power=on Kommandos eingetroffen ist und das Reading auf "on" gewechselt hat. Deshalb stehen da auch Meldungen wie "Device needs to be ON to adjust volume.", die du wohl überlesen hast. Probier doch erstmal die manuelle Steuerung, bevor du ein Script schreibst.

Ich kann keine Schwierigkeiten seitens des Moduls erkennen. Du verwendest es einfach falsch, das ist alles.
Das Reading wechselt nie auf "on". Die Befehle habe ich manuell abgesetzt.
Aber ok, dann muss ich wohl beim alten Modul bleiben...
FHEM in einem Dockercontainer
VCCU mit 3x HM-MOD-UART und 1x HmLGW
1x CCU2
2x nanoCUL 433MHz, 3x RPi3, Unifi-Controller mit drei APs für presence und Unifi Protec
div. weitere HM, ein paar HmIP Geräte und div. Shellys

Loredo

#448

Zitat von: 1of16 am 31 Mai 2016, 21:54:28
Das Reading wechselt nie auf "on". Die Befehle habe ich manuell abgesetzt.
Aber ok, dann muss ich wohl beim alten Modul bleiben...


Steht dir natürlich frei, hier wird niemand zu seinem Glück gezwungen (schon gar nicht bei solch pampigen Posts).
Ich denke ja du missverstehst was ganz grundlegendes, ich habe aber auch keine Lust dir noch weiter zu helfen.










Wer unbedingt meint die alte Pull-Version würde seine Probleme tatsächlich lösen, der kann sie sich ab sofort aus ./contrib/ kopieren:

https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/70_ONKYO_AVR_PULL.pm

Diese Legacy-Version wird nicht weiterentwickelt und nicht supportet.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

1of16

Zitat von: Loredo am 31 Mai 2016, 21:59:45

Wer unbedingt meint die alte Pull-Version würde seine Probleme tatsächlich lösen, der kann sie sich ab sofort aus ./contrib/ kopieren:

https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/70_ONKYO_AVR_PULL.pm

Diese Legacy-Version wird nicht weiterentwickelt und nicht supportet.
Vielen Dank, damit läuft es jetzt wieder wie gewohnt.
FHEM in einem Dockercontainer
VCCU mit 3x HM-MOD-UART und 1x HmLGW
1x CCU2
2x nanoCUL 433MHz, 3x RPi3, Unifi-Controller mit drei APs für presence und Unifi Protec
div. weitere HM, ein paar HmIP Geräte und div. Shellys