Where can I find information and discussions about @Guessed’s Onkyo Media plugin ?
There is a thread by that name in the Forum, but it is not really on Onkyo Media plugin, being more a discussion on how to develop a plugin, started by @TimAlls.
Thanks @JOD
From http://code.mios.com/trac/mios_onkyo-media-control
Discussion The Onkyo Receiver Plugin is discussed in this forum thread, along with it's development history: TODO: Feel free to ask questions on that thread, as well as make any suggestions & contributions to the future development of the Onkyo Receiver plugin's functionality.
Is there such a thread ? There is no link, and when we do a search, Tim’s thread (http://forum.mios.com/index.php?topic=6089.0) always comes as the most relevant.
Nope there wasn’t one, as folks didn’t seem to have much interest in it. I’ll make this one the “official” thread, and move it to the Luup Forum area.
Im trying to edit you Onkyo plug in and im having troubles adding more commands.
I have attached the D and I files.
You will notice i changed InputSelection2 due to when I tryed to upload the edited original, it would not override the original.
I have also added Zone2Control1 to the service files.
All I have changed was added more commands in the same format that you have and have verified the sendCommand codes with Onkyo.
All the files upload and i can see the command list on my iphone with SQ remote and attach them to buttons but it will not control amp, and on the UI is giving me an error stating “Onkyo[35]:Lua Engine Failed to Load”.
The editor im using seams to be a pure XML editor, it called XML Marker.
I have an Onyko TX-NR1007, Vera2 w/ current firmware, iPhone SQ remote.
Also, the original files u created will work and control my Onkyo. Thanks!
@kustominc,
I’ve outlined the details of the problems below.
When making changes to something, or even writing something from scratch, it’s best to start small in any changes you make, and test along the way as you make those changes.
This will help you to familiarize yourself with the system, and also better isolate ‘which change’ broke some functionality when it was added. It’s a slower process, but it works well on Vera given the lack of other tools.
In general, the MCV AV-Control IR Services are a “fixed” set of ServiceID’s and a corresponding fixed-set of Actions for those ServiceID’s. These Actions cover a wide variety of functions so not all AV-Devices will implement all Service’s or Actions from those services. If you’re adding something to an existing AV-Device, you should look to find the corresponding Service/Action from the existing set… since it’s not really possible to add new ones, at least not with a predictable outcome.
The Problems in the code include:
General…
a) The file has been converted to M$ format
Not sure if this will impede loading under Vera, probably not, but it makes it very hard to DIFF against the originals. You’ll want to be able to do DIFF Comparisons so you can see what changed, as part of the incremental development referenced above.
D_OnkyoReceiver1.xml…
a) You replaced [tt]InputSelection:1[/tt] ([tt]S_InputSelection1.xml[/tt]) with [tt]InputSelection:2[/tt] ([tt]S_InputSelection2.xml[/tt])
The latter definition doesn’t exist, nor does [tt]S_InputSelection2.xml[/tt], so this will cause your Device to fail during load.
b) You added [tt]Zone2Control:1[/tt], and [tt]S_Zone2Control1.xml[/tt], which don’t exist
Similar to the above, since it doesn’t exist the device won’t load.
I_OnkyoReceiver1.xml…
a) Change all the [tt]InputSelection:2[/tt] items back to [tt]InputSelection:1[/tt]
b) You added [tt]Zone2Control1[/tt] as a service, which isn’t part of the standard.
Look at the existing [tt]S_*.xml[/tt] files, for those that related to IR componentry, and see which one has the nearest codes for what you’re adding here.
In some cases, as you’re adding functions that overlap with the “primary zone” equivalent, it may be easier to build a new Plugin to handle just those.
eg. [tt]I_OnkyoReceiverZone1.xml[/tt], [tt]D_OnkyoReceiverZone1.xml[/tt]
and have those implement the same ServiceID and Action, but run the commands for the other Zone. You’ll get two devices in Vera, which will both need to be mapped to the same IR Controller, but it will be cleaner since the commands would otherwise “overlap”
Anyhow, hope this helps…
Just so im understanding you. You cannot edit or add the “s_” files? even tho I uploaded S_Zone2Control.xml to my files on Vera.
Your saying to create a new D and I file and use the existing names in the S files and just change the commands ex. “PWR00” to the new ones for my zone 2.
thanks
@kustominc,
There were no additional files attached above, just [tt]D_OnkyoReceiver1.xml[/tt] and [tt]I_OnkyoReceiver1.xml[/tt], so I assumed that’s all you had. Looking at the code, you’ve added two extra files ([tt]S_Zone2Control.xml[/tt] and [tt]S_InputSelection2.xml[/tt]) so both of these would have to be in your system for the Device defn to load correctly.
For general plugins, you’re free to write new Service Definition files, or import them from other places if they already exist somewhere. If they’re custom, generally no-one will know how to deal with them, so most things won’t provide for a rendition, but they’ll typically show up in places like Advanced-Scenes picker to let you “act” on the Actions they expose.
For AV-Control, there’s a “fixed list” of these [UPnP] Services that MCV themselves defined, and it’s undefined what will happen in the Control Points (like SQRemote) if you define new Service(s). It might work, it might not. It might work now, but not in the future, etc. Since there’s no guarantee for these cases, I’d lean towards using the existing MCV-defined services - there’s a lot more than the Services/Actions than I used for the Onkyo for all sorts of crazy stuff (like Audio modes, Theare modes etc)
Now, for your Secondary Zone, there’s a LARGE overlap of the functions with the functions of the Primary Zone. Things like Vol Up/Down for example, depending upon the Amp model. In this case, it may be simpler to define a secondary “set” of D_ and I_ files, with unique names, that are a copy of the originals and then tweak the Secondary command set into these. You’d retain the original ServiceID’s, and Actions, and would instead have a secondary Device that’s used to control the Zone 2 stuff… With more work, this could all be embedded into a single device, and a switch indicating whether it was “Zone 1, 2, 3…” but let’s keep it simple for now.
Hope this makes sense…
Thanks for your help.
I’ll try all the things u have said and post back to this an update.
Please bare with me as I am new, and trying to understand how these plugins work. I have an HT-RC270 with Ethernet port.
After I upload the D_OnkyoReceiver1.xml and I_OnkyoReceiver1.xml and create a device using these two files. I can set the IP address and follow the testing as shown here http://code.mios.com/trac/mios_onkyo-media-control and the testing works.
However is anything supposed to show up in the Receiver Control or Options Tab??
Because I couldn’t get anything, I looked at the Denon plugin and copied the .json file to an onkyo.json file and referenced it in the I_OnkyoReceiver1.xml file. Now I get some buttons in the Receiver Control, but not all of them work. Before I try to go through and start modifying the files, I just want to make sure that it I am doing the correct thing. Is the .json file required to create the buttons on the Receiver control?
Also under the Settings Tab, does the Configure Node, Poll now or I/O buttons do anything, or is that just for Z-Wave devices?
I’ve not bothered to create a JSON file as this is just a proxy so I can use a “real” remote to control the functions (over it’s Ethernet interface). This type of IR device gets exposed up to Control Points that understand MiOS IR stuff.
I use SQRemote on my iPhone to control the Amp using this, and also it on my iPad.
Didn’t figure anyone would ever want to use a UI from MiOS to do that sort of control… guessI figured wrong 
I have been planning on some house keeping on this plugin, mostly related to getting status information back from the Amp, along with implementing On/Off and keeping it in sync with the events coming back from the Amp. Given this, I’ll need to build a JSON anyhow.
The Dashboard display I’m thinking of will show the input currently selected, along with Basic on/off control/status.
For the Device’s Dialog, what specific buttons are you looking to see exposed?
I am still trying to figure out the best way to control everything. I was thinking that I want the ability to control volume and zone 2 source and volume through an android interface. I am using Homebuddy to control outdoor lights, and would like to be able to control the music that way also.
As I use my zone 2 on the deck mostly to stream internet music (Pandora, Mediafly ie.) I would love to have the ability to see the name of the streaming song and artist, with the ability to skip or navigate to other source.
I have attached the newest ISCP codes for onkyo. Maybe this will help to add more information.
I knocked out a quick JSON UI for it, with controls for displaying the On/Off and Volume status’s, as well as changing them from the Dashboard.
If you want to see it in action, it’s here:
http://code.mios.com/trac/mios_onkyo-media-control/changeset/8/trunk?old_path=%2F&format=zip
There are a few more files than the original, and they all need to be loaded up. The “core” ones will overlay the existing.
For now, I’ve hard-coded the Volume to never go above 70%, as the slider would let you go up to 100% and might blow your speakers if you accidentally did that. At startup time, it polls the Amp to get the current Volume and On/Off status. If you change it with a regular remote control, the Dashboard will follow.
The next items are really about displaying the Current Input selected, on the primary input, and to add Scene scripting to it for the common stuff (at least for those not already exposed by Advanced/Scene tab)
The Dashboard component really isn’t big enough to display a lot of “status” information, like the currently playing song/artist etc. The Dialog could do it potentially, but I’m not sure of the usefulness of that (I virtually never use the Vera UI when I’m listening to music, for example)
Also, additions to these Dashboard UI’s won’t show up on Android, iPhone, or Windows remotes (nless they’re literally running the full UI4 Dashboard… again I’m not convinced how many really do this.
What’s needed here is something along the lines of what we did for the Alarm Panels. This comes in two parts:
a) a standardization effort to define ServiceID’s to get information/status “back” from AV Gear AND;
b) the control points to adopt that standard in order to provide UI’s to cover them.
Not sure how realistic that is, given that most of the control points don’t even support the one-way IR ServiceID’s that already exist (except SQRemote)
I will take a stab at creating the standard if you will maintain it.
I will also see if I have time this weekend to integrate your changes into the Denon Plugin I have been working on.
[quote=“dfad1469, post:14, topic:168197”]@guessed
I will take a stab at creating the standard if you will maintain it.
I will also see if I have time this weekend to integrate your changes into the Denon Plugin I have been working on.[/quote]
LOL, nice try…
The problem is that the standard is, in large part, already defined UPnP standards… at least for the Media Control stuff. Not clear to me you really want to go down that road in terms of re-inventing it.
Basic On/Off, Volume and InputSelection would be as far as I’d ever go, so it can be automated in [mood] Scenes. The Control points could just natively implement the AV stuff from UPnP and avoid ‘the extra hop’ of going through Vera (Onkyo, Denon, etc all do UPnP already) at least for day-to-day control functions.
Do you know where I can locate the eISCP documentation for a Pioneer Elite VSX-52 a/v receiver by any chance? I have my receiver connected via Ethernet within my LAN (same as Vera). Would Vera be able to communicate with the Receiver and control basic on/off functions, without SQ Remote and without going through RS-232? I do use the iControlAV2 free android app from Pioneer, which is amazing by the way! (in case anyone was wondering) I would still really like it more so if I could at least kick on the receiver and perhaps activate Zone 2 from a Scene within Vera. Just the simple stuff (or what should be simple. LMAO!)
I am trying to modify your wonderful plugin for the Onkyo TX-NR807 to work for my Pioneer VSX-52. I’d kill to have the ability to at least turn on the receiver and activate Zone 2 when a scene is activated. e.g. Entertain Scene → Receiver Kicks on. That would be awesome. If you have any suggestions or advice I would be so grateful! 
EISCP is Onkyo’s marketing name for their API/Interface. Pioneer probably uses a different name for their protocol.
Some vendors make it hard to get these docs, so I made it part of my selection criteria when I bought the Onkyo.
If you can’t find it with a google search, then you mught try the AVSForum, or RemoteCentral. Try searching using criteria like :
Filetype:pdf api protocol pioneer receiver
As ofthen these protocols cover a range of devices from the same manufacturer
Awesome, I found it with a bit more digging. Thanks for the heads up @guessed.
Below are some Pioneer links, just in case anyone else is or was curious (not trying to hijack the thread).
http://www.pioneerelectronics.com/PUSA/Support/Home-Entertainment-Custom-Install
@guessed:
By looking at your D_OnkyoReceiver1.xml, In the serviceList you have several services, with their SCPDURL pointing to an xml
For instance this one S_DiscretePower1.xml
Where is this S_DiscretePower1.xml?
I was wanting to understand the details in creating a plugin, and thought I’ll look at one that was already operational , like yours.
Thanks for any input guessed.
Some of these, like discrete power, ship with Vera. You can see them listed in the Developer/Luup menus of Vera, and either download or view them via your browser.
You can also see them when you login to Vera over SSH (locally). They’re in /etc/cmh* … Depending upon whether they are part of the standard kit, or uploaded as a custom plugin…