[Develop] Onkyo Adapter - VIS Weiterentwicklung

Eisbaeeer

Hey cool.

Ich erinnere mich wieder an die Struktur. Deshalb hab ich auch verstanden, wie du die Navigation aufgebaut hast.

Ich hatte das damal auch so zerlegt: NLT11020000000401001B1100GOTHAM-CITY

Hatte immer geschaut, welche Teile sich ändern, wenn ich mit der Fernbedienung navigiert hatte. Das mit der XML ist natürlich auch ein feiner Weg.

Also, die Fehler stammen definitiv aus dem node_module eiscp. Ich überlege mir gerade, das komplette Modul aus dem Adapter rauszuschmeißen und wie auch schon in ccu.io das im RAW Format zu übertragen. Damit würde sich in den Objekten nichts ändern und die ganzen Fehlermeldungen für Receiver, die eh keiner hat (3 Zonen und mehr) wären dann Geschichte.

Ich muss zugeben, dass ich bisher null komma null mit Widget´s zu tun hatte. Ich hab noch keines programmiert. Von daher gefällt mir deine Funktion, die Navigation über Touch zu nutzen.

Woher kommt jetzt genau die XML Datei? Sendet die der Onkyo? Falls das der Fall ist, könnte ich die XML parsen und in die Datenpunkte schreiben und auch Befehle hinter die Objecte legen.

Es ist schon so lange her, dass ich den Onkyo gebaut hab ;-)

Wäre gut, wenn wir unsere beiden Bausteine zusammenbauen könnten.

sveni_lee

ja, die sendet der Onkyo…

hier mal ein Auszug aus der kommunikation rot -> zum Onkyo; blau -> vom Onkyo

~~![](</s><URL url=)https://i.imgur.com/PDll4AX.jpg" />

mein Problem ist/war das isch mir der xml im tempalte.js nicht allzuviel anfangen kann und darum eine JSON daraus mache

hier mal eas ich in der onkyo.js gemacht habe…

   eiscp.on("data", function (cmd) {
        adapter.log.debug('Got message: ' + JSON.stringify(cmd));
        adapter.log.info('EISCP String: ' + cmd.iscp_command);
    // Here we go to select the RAW feedback and take it to the right variable. The RAW is in cmd.iscp_command
    if (adapter.config.fixedvars) {

        var chunk = cmd.iscp_command.substr(0,3);
        var string = 	cmd.iscp_command.substr(3,80);

		if (string.includes("ISCP")) {
			string = string.substring(0, (string.indexOf('ISCP')))
		}

        adapter.log.debug('chunk: ' + chunk);
        adapter.log.debug('string: ' + string);		

	if (chunk == 'NRI') {
		adapter.setState (adapter.namespace + '.' + 'Receiver_Info', {val: (cmd.iscp_command).slice(3, -3), ack: true});
					}
	if (chunk == 'NLA') {
		sequenz = string.substr(1,4)
		adapter.setState (adapter.namespace + '.' + 'NET/USB_Sequenz', {val: sequenz, ack: true});
		adapter.log.debug('sequenz: ' + sequenz);
		var xmlrepeat = ((cmd.iscp_command).slice(12).substring(0, ((cmd.iscp_command).slice(12).indexOf(''))+11))
		parser.parseString(xmlrepeat, function (err, result) {
			var jsonrepeat = JSON.stringify(result);
			adapter.setState (adapter.namespace + '.' + 'Receiver_ListInfo', {val: jsonrepeat, ack: true});
			adapter.log.debug('Adapter SET Reciver_ListInfo: ' + jsonrepeat);
			});
//		adapter.setState (adapter.namespace + '.' + 'Receiver_ListInfo', {val: ((cmd.iscp_command).slice(12).substring(0, ((cmd.iscp_command).slice(12).indexOf(''))+11)), ack: true});
		adapter.log.debug('Adapter SET Reciver_ListInfo: ' + ((cmd.iscp_command).slice(12).substring(0, ((cmd.iscp_command).slice(12).indexOf(''))+11)));
//		adapter.setState (adapter.namespace + '.' + 'net-usb-list-info-allitems', {val: ((cmd.iscp_command).slice(12).substring(0, ((cmd.iscp_command).slice(12).indexOf(''))+11)), ack: true});
					}

	if (chunk == 'NJA') {
		var covertype = string.substr(0,1)
		adapter.log.debug('Covertype: ' + covertype);
			if (covertype == '0') {
				var image_type = 'bmp';				
			}
			if (covertype == '1') {
				var image_type = 'jpg';
			}

		var packetflag = string.substr(1,1)
		adapter.log.debug('packetflag: ' + packetflag);
			if (packetflag == '0') {
				var hextob64 = new Buffer(cmd.iscp_command.substr(5), 'hex').toString('base64')
				imageb64 = hextob64;
			}
			if (packetflag == '1') {
				imageb64 = imageb64 + new Buffer(cmd.iscp_command.substr(5), 'hex').toString('base64');
			}
			if (packetflag == '2') {
				imageb64 = imageb64 + new Buffer(cmd.iscp_command.substr(5), 'hex').toString('base64');

				// string generated by canvas.toDataURL()
				var img = 'data:image/' + image_type + ';base64,' + imageb64;
				adapter.setState (adapter.namespace + '.' + 'Cover_Transfer', {val: img, ack: true});				
			}

	}

und das im eiscp-Modul

	on('data', function (data) {

		if(first) {
			xml = eiscp_packet_extract(data);
			first = false;
			var result = iscp_to_command(xml);
			result.iscp_command = xml;
			result.host  = config.host;
			result.port  = config.port;
			result.model = config.model;

			if(result.command == 'receiver-information' | result.command == 'net-usb-list-info-allitems') {
			xml= data.toString('ascii', 18);
			}

			if (xml.includes("NLAX") && xml.includes("")) {
				xml = xml.slice(xml.indexOf("NLAX"));
				var result = {};
				result.iscp_command = xml;
				result.host  = config.host;
				result.port  = config.port;
				result.model = config.model;
				self.emit('data', result);
				first = true
			}

			else if (xml.includes("") && !xml.includes("NLAX")) {
					self.emit('debug', util.format("DEBUG (indexOf('')) command %s", xml));
					self.emit('data', result);
					first = true
			}

		} 
		else {  
			xml = xml + data.toString('ascii'); // evtl. data.toString() ?
			self.emit('debug', util.format("DEBUG (XML) command %s", xml));

			var result = iscp_to_command(xml);
			result.iscp_command = xml;
			result.host  = config.host;
			result.port  = config.port;
			result.model = config.model;

			if (xml.includes("")) {
				self.emit('data', result);
				first = true

			}
		}   

		if(result.command !== 'receiver-information' && result.command !== 'net-usb-list-info-allitems') {
			first = true;

			self.emit('debug', util.format("DEBUG (received_data) Received data from %s:%s - %j", config.host, config.port, result));
			self.emit('data', result);

		}	
	});
````~~

Eisbaeeer

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?

sveni_lee

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...

Eisbaeeer

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

sveni_lee

moin moin…

da war ja aber einer fleißig....

Ich hab die Änderungen schon auf Github verfolgt... :D

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

Eisbaeeer

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

sveni_lee

da hast Du mir ja ganz schön Arbeit gemacht… :D

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?

Eisbaeeer

Hmm, teste erstmal alles durch ;-)

Bluefox

~~@Eisbaeeer:~~

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',

Eisbaeeer

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

sveni_lee

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.

Bluefox

~~@Eisbaeeer:~~

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)

Eisbaeeer

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?

sveni_lee

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

Eisbaeeer

Ist der TX-NR626

sveni_lee

Der geht aber 100%… ich hab nen 525

Gesendet von iPhone mit Tapatalk Pro

Eisbaeeer

~~@sveni_lee:~~

Der geht aber 100%… ich hab nen 525 `
Ok, dann warte ich mal auf den pull-request und teste das ;-)

Cover 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"

sveni_lee

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?

Eisbaeeer

~~@sveni_lee:~~

… 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.

Community Forum

NEWS

[Develop] Onkyo Adapter - VIS Weiterentwicklung

Support us

417

32.5k

81.8k

1.3m