[Develop] Onkyo Adapter - VIS Weiterentwicklung
-
Ah, OK. Und dafür gibt es dann wieder die maximal 10 Datenpunkte (von 0-9).
Ich schau mir das mal in Ruhe an. Ich glaub das gibt einen größeren Umbau, aber das macht nix.
Also was wären jetzt deine Wünsche genau?
Im Prinzip hast du ja schon den Adapter angepasst. Ich wandle die XML auch immer in JSON. Das ist halt unsere Welt
Also mein Vorschlag. Ich bau den Adapter soweit um, dass "einfacher" wird. Meiner Meinung nach reicht es, wenn 2 Zonen unterstützt werden.
Zusätzlich müssten dann noch Objekte hinzu, damit die NET Funktion besser unterstützt wird.
Was meinst du? Was fehlt noch bei meinen Überlegungen?
-
ja, die gibt es aber die werden von mir quasi nicht genutzt… die sendet der Onkyo immer! braucht man aber nicht unbedingt denke ich...
Ich befürchte das ganze wird dann noch komplexer... was noch fehlt ist noch die Auswahl des "Input". das könnte man eventuell aus der NRI-xml auslesen... dort werden eigendlich alle möglichkeiten aufgeführt...
<response status="ok"><device id="TX-NR525"><brand>ONKYO</brand> <category>AV Receiver</category> <year>2013</year><model>TX-NR525</model> <destination>xx</destination> <firmwareversion>1060-9110-0000-</firmwareversion></device></response>Wir müssten halt überlegen was rein soll und was nicht… das gante kann man dann wieder in Abhängigkeit zum Model machen. Problem ist bspw. das die Lautstärkenreglung der Zone2 bei meinem nicht geht, da er nur LineOut für Zone2 hat... Ich würde schon gern so viel wie möglich aus den Remote-Apps umsetzen. Ich denke das meiste müsste man Widgetseitig lösen, der Adapter sollte die nötigen Signal ersteinmal senden und Auswerten können...
-
Alsoo,
2 Bier und eine Nacht später…
Ich hab im Adapter mal aufgeräumt. Es ist noch eine Menge zu tun, aber jetzt ist das ganze mal übersichtlicher und vor allem kann man jetzt ohne Fehler selbst RAW Kommandos senden. Dazu bitte nur noch das Object "RAW" verwenden.
@Sveni_lee: Du kannst ihn mal installieren und testen. Er ist als npm und github verfügbar. Am besten vorher den Adapter deinstallieren. Bei mir läuft er jetzt auf jeden Fall ohne Probleme.
Wie gesagt, ist noch eine wenig Arbeit nötig (kosmetisch und vor allem die Anpassung auf die neue Admin3 Oberfläche), aber das ist alles nur im Hintergrund.
Falls du mehr Infos im Log willst, solltest du auf "debug" stellen, dann bekommst du alle Meldungen. Sind allerdings auch richtig viele. Ich werde den "info" level auch noch runterschrauben. Da kommen meiner Meinung nach auch noch zu viel infos.
Aber ich denke wir arbeiten eh noch weiter an dem Adapter
Gruß Eisbaeeer
-
moin moin…
da war ja aber einer fleißig....
Ich hab die Änderungen schon auf Github verfolgt...
Ich werd den Adapter mal neu installieren und mir anschauen.
Im zweiten Schritt würde ich dann meine änderungen einbauen und dir als Pull Request senden.
Was meinst Du, sollten wir eine Test Branch eröffnen? Ist eventuell besser als am offenen Herzen zu operieren...
Gruß Sven
-
Ja wäre sinnvoll. Hab gestern schon geschwitzt. Gefällt mir auch nicht, hab das allerdings gemacht, da der Adapter ja nicht im repository ist. Sozusagen ist er ja nicht offiziell. Sonst hätte ich da nicht so agiert.
Hab mal eine developer version angelegt: https://github.com/Eisbaeeer/ioBroker.onkyo-vis-dev
-
da hast Du mir ja ganz schön Arbeit gemacht…
Musste jetzt erst einmal wieder alles anpassen. Ich denke das klappt auch soweit nur kann ich es grad nicht testen.
Mein Onkyo zu Hause scheint abgestürzt zu sein...
Kann ich von hier leider noch nicht Stromlos machen und neu starten...
soll ich trotzdem mal ein pullrequest auf die Dev-version machen?
-
Hmm, teste erstmal alles durch
-
Hmm, teste erstmal alles durch
`Hallo Eisbaeeer (wirklich so viele "e"?
Ich sehe, dass du onkyo-vis entwickelst und dabei gibt es schon ein onkyo.
Wie währe es damit, dass du ioBroker/iobroker.onkyo weiter entwickelst?
Ich sehe, dass iobroker.onkyo ganz rudimentär ist und es konnte vielleicht noch viel gemacht werden.
Dabei bitte ich dich viel auf die Rollen achten. https://github.com/ioBroker/ioBroker/bl … E_ROLES.md
Damit konnte man in material so darstellen (und später auch in anderen Adaptern)
Bei den Datenpunkten (https://github.com/Eisbaeeer/ioBroker.o … yo.js#L222) bitte ich dich CamelCase zu verwenden (NET_Play_Status => playStatus, Power_Zone1 => powerZone1) und "/" in Namen nicht verwenden, da für MQTT reserviert ist (NET/USB_Artist_Name_Info => artistNameInfo)
Auch Zu viele States in einer Zone wird für Material verwirrend. So was schlage ich vor:
'zone1.power', => switch.power boolean 'zone1.volume', => level.volume number, min, max 'zone1.tuning', ? 'zone1.internetRadioPreset', => string 'zone1.inputSelect', => https://github.com/ioBroker/ioBroker.onkyo/blob/master/io-package.json#L124 'zone1.audioMute', => media.mute , write=true, read=true, boolean 'zone1.tunerPreset', => string 'zone1.listeningMode', => ?? (States?) 'zone1.audioInformation', => string 'zone1.videoInformation' => string 'zone1.artistNameInfo', => media.artist 'zone1.titleName', => media.title 'zone1.timeInfo', => media.duration ? in seconds! 'zone1.timeCurrent', => media.elapsed ? in seconds! 'zone1.time', => media.duration ? in seconds! 'zone1.albumNameInfo', => media.album 'zone1.trackInfo', => media.track 'zone1.playStatus', => media.state ['play','stop','pause'] or [0 - pause, 1 - play, 2 - stop] or [true - playing/false - pause] 'zone1.repeatStatus', => media.mode.repeat Nur status oder auch schreiben? 'zone1.shuffleStatus', => media.mode.shuffle (common.type=number) 0 - none, 1 - all, 2 - one 'zone2.power', => switch.power.zone 'zone2.volume', => level.volume number, min, max 'zone2.tuning', 'zone2.internetRadioPreset', 'zone2.inputSelect', => https://github.com/ioBroker/ioBroker.onkyo/blob/master/io-package.json#L124 'zone2.audioMute', => media.mute 'zone2.tunerPreset', -
Hallo Bluefox
Das Thema Material hatte ich auch schon verfolgt und mitgelesen. Das kann eventuell was werden, wobei ich selbst kein Fan von diesem Adapter bin.
Grundsätzlich wollte ich schon vor langer Zeit den ioBorker.onkyo weiterentwickeln und hatte auch einen pull-request erstellt. Damals war die Anforderung der Nutzer nur, den Adapter VIS kompatibel zu machen, so wie er schon in ccu.io funktionierte. Meine Änderungen wurden damals verworfen bzw. wieder rückgänging gemacht. –> Kannst du in diesem Thread sogar nachverfolgen, denn der ist von damals. Du kannst dir sicher vorstellen, dass ich dann keinen Bock mehr hatte, hier weiter zu entwickeln. Meine Zeit war mir da einfach zu schade. Eventuell sollte man mit Entwicklern etwas netter umgehen. Deshalb habe ich dann den ioBroker.onkyo-vis ins Leben gerufen und für mich und andere angepasst.
Aber lassen wir die Vergangenheit.
Wie stellst du dir das vor? Deine Vorschläge machen Sinn und fließen sicher mit ein. Soll der bisherige erstetzt werden? Ich will auf jeden Fall die bisherige discovery funktion des moduls <u>nicht</u> benutzen. Das node_eiscp ist viel zu umfangreich und meiner Meinung nach unnötig, da 99% nur 2 Zonen haben. Die ganzen Datenpunkte, die über das Modul abgefragt werden, braucht niemand (meine Meinung).
Unser Ziel ist es, 2 Zonen abzubilden und die NET Funktionen des Onkyo. Und zwar so, dass man das auch mit VIS nutzen kann. Denn in meinen Augen ist der bisherige "offizielle" Adapter absolut unbrauchbar für VIS. Ich lasse mich aber gerne vom Gegenteil überzeugen, falls das nicht so ist.
Die Rollen, Typen, Einheiten und Datenpunkte in common mache ich natürlich noch so, dass es passt. Die Objekte gehören ja auch noch in die "io-package.json" und nicht im main, usw.
Danke auch für die Hinweise. Der Adapter ist ja doch schon in die Jahre gekommen. Admin3 muss auch noch rein, und, und, und …
Gruß Eisbaeeer
-
Ich denke auch das node-eiscp zu umfangreich und vor allem nicht gepflegt ist. Das Umschalten der einzelnen Modi (Stereo, 5.1 usw..) braucht man nicht wirklich. Ich denke ein Auswahl von Quellen und Lautstärke in den einzelnen Zonen sollte reichen.
-
Hallo Bluefox
Das Thema Material hatte ich auch schon verfolgt und mitgelesen. Das kann eventuell was werden, wobei ich selbst kein Fan von diesem Adapter bin.
Grundsätzlich wollte ich schon vor langer Zeit den ioBorker.onkyo weiterentwickeln und hatte auch einen pull-request erstellt. Damals war die Anforderung der Nutzer nur, den Adapter VIS kompatibel zu machen, so wie er schon in ccu.io funktionierte. Meine Änderungen wurden damals verworfen bzw. wieder rückgänging gemacht. –> Kannst du in diesem Thread sogar nachverfolgen, denn der ist von damals. Du kannst dir sicher vorstellen, dass ich dann keinen Bock mehr hatte, hier weiter zu entwickeln. Meine Zeit war mir da einfach zu schade. Eventuell sollte man mit Entwicklern etwas netter umgehen. Deshalb habe ich dann den ioBroker.onkyo-vis ins Leben gerufen und für mich und andere angepasst.
Aber lassen wir die Vergangenheit.
Wie stellst du dir das vor? Deine Vorschläge machen Sinn und fließen sicher mit ein. Soll der bisherige erstetzt werden? Ich will auf jeden Fall die bisherige discovery funktion des moduls <u>nicht</u> benutzen. Das node_eiscp ist viel zu umfangreich und meiner Meinung nach unnötig, da 99% nur 2 Zonen haben. Die ganzen Datenpunkte, die über das Modul abgefragt werden, braucht niemand (meine Meinung).
Unser Ziel ist es, 2 Zonen abzubilden und die NET Funktionen des Onkyo. Und zwar so, dass man das auch mit VIS nutzen kann. Denn in meinen Augen ist der bisherige "offizielle" Adapter absolut unbrauchbar für VIS. Ich lasse mich aber gerne vom Gegenteil überzeugen, falls das nicht so ist.
Die Rollen, Typen, Einheiten und Datenpunkte in common mache ich natürlich noch so, dass es passt. Die Objekte gehören ja auch noch in die "io-package.json" und nicht im main, usw.
Danke auch für die Hinweise. Der Adapter ist ja doch schon in die Jahre gekommen. Admin3 muss auch noch rein, und, und, und …
Gruß Eisbaeeer `
Ich errinere mich gar nicht, dass ich an onkyo gearbeitet habe und onkyo habe ich auch nicht.Ich schlage vor, dass ich dir die rechte für repo gebe und dazu auch ein paar empfelungen. Und du entwickelst da weiter.
node_eiscp gefehlt mir auch nicht. Da hängt mein PR auch noch seit Monaten. D.h es ist eine unflexible Abhängigkeit.
Wenn ein PR nicht abgenommen wurde, tut mir Leid. Ich weiss, wie schwer das ist, die Entwickler zu bekommen und bis jetzt alle PRs abgenommen wurden (ausser ping, aber da läuft noch was)
-
Hallo sveni_lee und Bluefox
@Bluefox: Also ich hatte das damals in ccu.io als TCP socket programmiert. Das hat wunderbar funktioniert. Damit würde dann der node_eiscp komplett entfallen. Das wäre eine sehr schlanke Lösung und man bräuchte kein zusätzliches node-module.
Für Tipps bin ich immer dankbar und nehme diese auch gerne an. Ich war damals nur pampig, weil der pull-request erst gemacht wurde und dann ohne Rückfrage einfach rückgängig gemacht wurde. Ich bin "nur" hobby Programmierer und mache das nicht beruflich. Deshalb bin ich nicht perfekt und mache auch Fehler. Aber ich bin offen. Danke für das Vertrauen
@sveni_lee: Ich muss dir leider mitteilen, dass mein Receiver wohl schon zu alt ist. Meiner gibt leider keine XML per NLA aus. Hab alles getestet, spottify, smb, dlna. Keine Daten. Der NLA ist bei mir nicht vorhanden. In diesem Fall musst du von deiner Seite testen und den Teil beiliefern.
Vorschlag: Ich baue den -dev mal auf Socket um und lege die jetzt schon vorhandene Objekte nach der neuen Struktur an (Zone1 und Zone2). Das heißt aber, wir programmiere den Adapter fast komplett neu. Wir lassen den bisherigen unberührt, bis der neue funktioniert.
Was meint ihr?
-
Geht für mich in Ordnung… kannst Du mir mal sagen welches Modell du hast?
Hab jetzt mal getestet... läuft bei mir! Ich würde dann einen PR aus den dev schicken...
Auf node-eiscp zu verzichten wäre ne gute Idee...
Gesendet von iPhone mit Tapatalk Pro
-
Ist der TX-NR626
-
Der geht aber 100%… ich hab nen 525
Gesendet von iPhone mit Tapatalk Pro
-
Der geht aber 100%… ich hab nen 525 `
Ok, dann warte ich mal auf den pull-request und teste dasCover Art wäre schon ein tolles feature. Rufst du tuneIn auch direkt auf?
@sveni_lee: Hast du noch eine neuere EISCP Excel als diese hier: "ISCP AV Receiver v124-1.xls"
-
hab Dir grad den PR geschickt…
Du brauchst die geänderte eiscp.js und eiscp-commands.json ansonsten werden die Befehle nicht unterstützt...
Du kannst das aber einfach in den node-modulen ändern und den adapter neu starten.
TuneIn habe ich noch gar nicht in Angriff genommen... könnte ich aber noch tun
Ich mache das immer so, dass ich das ganze an der Onkyo Remote3 probiere und den kompletten Netzwerkverkehr mit Wireshark über meine
Fritzbox mitschneide und Auswerte... halt old school reverse engeneering :lol:
Hast Du eventuell eine Vorstellung für die Grafische Umsetzung für ein Widget? Was sollte da alles rein?
-
… halt old school reverse engeneering :lol:
Hast Du eventuell eine Vorstellung für die Grafische Umsetzung für ein Widget? Was sollte da alles rein? `
Ha, Oldscool passt. Ich programmiere im Notepad++
Entwicklungswerkzeuge wäre sicher einfacher, aber im selbstgeschriebenen Code ist einfach noch die Handschrift zu erkennen.
Grafisch bin ich nicht der Held. Ich würde mich aber da an z.B. Sonos anlehnen. Ist dann für den User einfacher, da schon bekannt.
-
@sveni_lee: Hast du noch eine neuere EISCP Excel als diese hier: "ISCP AV Receiver v124-1.xls" `
Evtl hilft es ja. Keine Ahnung welche unserer beiden Dokumente neuer ist
-
Notepad++ habe ich auch sehr lange benutzt. Bin jetzt auf Sublime3 portable umgestiegen. Hab immer alles auf einem USB-Stick dabei und mach sehr viel auf Arbeit nebenbei… Geht aber leider nicht mehr lange da ich zum 01.08. die Stelle wechsel und dann wieder richtig arbeiten muss :lol:
Das jetzige Widget ist ja an Sonos angelehnt... dann bleibt es dabei.
Ich hab auch die v124-1 als Grundlage genommen. Ich hatte auch ne neuere gesehen aber da hat sich an den commands nichts geändert.
