[Develop] Onkyo Adapter - VIS Weiterentwicklung
-
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.
-
Merge ist durch. Die node dateien auch hochgeladen. Dev Adapter installiert. Die Datenpunkte von dir sind auch erstellt. Bin gespannt, ob meiner das auch kann. Test leider erst heute Abend
Idee: Ich hab mir den node_eiscp durchgeschaut. Grundsätzlich sind da die Funktionen enthalten, die wir eh brauchen. Auch dort wird ein Socket erstellt, der reconnect ist auch drin. Eigentlich bräuchten wir den nur entschlacken. Die Funktion "eiscp-commands.json" kann entfallen, da wir die Abfrage im Adapter realisieren. Den XML Part hast du ja schon reingepackt. Wir erstellen einen schlankeren neu und nehmen den als Basis. Man muss sich ja nicht mehr Arbeit machen als nötig
Was meinst du ?
-
hört sich für mich gut an…
Ich hab noch ein kleines Problem entdeckt... irgendwie kommen die NLAX... doppelt vom eiscp. Ich denke da hab ich noch einen Fehler drin.
Ist auch nicht so schön gelöst finde ich eventuell fällt Dir ja noch was besseres ein.
Wichtig ist noch, dass Du erst einmal am AVR die Freigabe auf deine Home-Media machst falls Du deinen Server Passwort gesichert hast..
-
Ich hab noch ein kleines Problem entdeckt… irgendwie kommen die NLAX... doppelt vom eiscp. `
Schau ich mir an. SMB Freigabe ist schon gemacht.Ein Package für iobroker javascript und Sublime wäre cool. Dann könnte mich der Editor echt verführen. Benutzt du ein package in Sublime?
-
nein, ich hab da kein package. Ob es so etwas gibt kann wohl nur Bluefox beantworten.
Ich hab den Editor, weil ich ab und an mal was für KODI Addons mache und da is der schon ganz gut weil man die py auch mal ausführen kann um zu sehen ob es geht… Ich meine mich aber zu erinnern das es ein "Problem" mit packeges gibt, wenn man das ganze portable nutzt..
-
Also mein Onkyo sendet Daten in das Objekt: Receiver_ListINfo, das "Receiver_Info" bleibt allerdings leer. Heisst doch, er sendet keine XML?
Konnte nur schnell heute morgen testen. Gestern Abend konnte ich nicht ans Gerät. Ich schau mal am WE tiefer rein.
-
schick mal folgendes an den Onkyo… NRIQSTN
Receiver_Info wird nur gefüllt wenn er eine NRI zurückgibt. Das sind die AVR Infos mit Modelbezeichnung, Firmwareinfo usw...
Hat er denn eine JSON in den Receiver_ListInfo geschrieben?
