Is there a possibility of adding Listen mode into the OH2 Binding for the Pioneer AVR?
Or is there a way of adding it manually rather than having to change the binding?
My device was discovered through PaperUI as a thing.
Any help that can be provided would be appreciated.
Looking for this as well. It seems like this was not documented in the openhab2-addons repo.
Also, there nothing about it in the actual code.
We might need to open a pull request for this. Until implementation, using the old PioneerAVR Binding should suffice.
Hey @Stratehm, you seem to be the owner of this binding. Are you interested to add the features of the 1.x binding as well? I am willing to help out in every way, especially by providing documentation, use-cases and testing. There is much rare information about the protocol spread over the internet.
If so, I’d start to create Issues for features, including the Pioneer protocol statements, recommended item types to link the channel to, and so on.
Looking forward to your answer 
Help is always welcomed. I could add the OH1 binding features to OH2 binding, but I want to fix the current features first.
I am currently doing an heavy refactor of the binding to allow to easily define features supported by each AVR model.
I’ll provide supported features for my VSX-830, as soon as you are ready. I assume you will create a Thing type that has all the features your binding supports so we can test them on our models and give feedback to you?
You are right.
Hi, has there been any progress (or further considerations) on this? I am - quite desperately - looking for a way to change the listening mode in PioneerAVR 2 binding, and came across this more-than-two-year-old topic. It started promising, but ended quite abruptly. Of course, I’m happy to help testing with my receiver.
Welcome @bjscheue to our community! Well, I haven’t heard anything new either and are considering to implement the features by myself. I have no experience in addon development, though and I have no urgent need for the features.
If you are feeling lucky, the features are in the openhab 1 binding. So if you want to give it a try I will help out where possible. If not, I will do it some time. Possibly this year.
Hey, thanks for your feedback. I also thought about implementing this myself, but I, too, haven’t done any addon/OpenHAB development yet, and I fear I will not find the time to dig deep enough into that foreign territory atm.
I toyed around a bit with the Pioneer IP interface, though, and found it quite light-weight and tame. Unfortunately, my receiver won’t allow me to set up a second TCP connection in parallel to the one opened by the Pioneer binding. But I wrote a little “proxy” which intercepts the TCP connection between the Pioneer Binding and my receiver, and allows me to inject additional commands. This is a dirty and ugly hack, of course, but it already comes very close to solving my problem.
Over the Easter weekend I’ll probably invest a little more time for a cleaner solution. I am thinking about a Pioneer/MQTT interface daemon, which sets up a TCP connection to the receiver and exposes an MQTT interface for sending/receiving Pioneer commands and status updates. This should actually be pretty easy, and it would allow to control the receiver via the generic MQTT device binding in OpenHAB.
Just to follow up on this: it works quite well for me with the way indicated in my previous post. I implemented a small bridge/proxy between MQTT and the Pioneer protocol. This allows me to talk to my receiver via the Generic MQTT binding. The bridge runs as a daemon in the background and is able to pass through any arbitrary command to the receiver and any status update the other way around, thereby giving full me access to all features of the receiver without a need to individually implement them all in the bridge script.
It’s admittedly not the cleanest way to do it, but it’s flexible (giving not only OpenHAB access to the receiver, but also any other MQTT-capable component), and it solved my problem with moderate effort.
Thanks, again, @gersilex for your offer to help. 
This sounds quite interesting and I am curious how you implemented this. Do you have any plans for sharing this?
It’s actually pretty simple: a Ruby script with three threads.
One thread listens on the TCP connection to the AVR. The format of incoming messages from the AVR is one or more letters followed by a number (or, in a few cases, a string of numbers and letters). When a message comes in, an MQTT message is issued, with topic stat/pioneer/ with message contents what follows after the initial letters. For instance, if the AVR says VOL120 (“current volume is 120”), an MQTT message to stat/pioneer/VOL with contents “120” is sent. Thereby, all status message become accessible through MQTT.
The second thread subscribes to MQTT messages for topics cmnd/pioneer/#. If a message with such a topic comes in, the third component of the topic and the contents of the message are concatenated and forwarded to the receiver. For instance, by publishing an MQTT message to cmnd/pioneer/VL with contents “100”, you can have “VL100” sent to the avr, which will set the volume level to 100.
The third thread periodically issues status requests (for audio+video status) to the avr. The thereby triggered status response messages are published by the first thread.
This direct 1:1 interface between MQTT and Pioneer’s protocol gives full access to all features. It just turned out that the Pioneer protocol design is not very clean and systematic, and sometimes it was a bit of a hassle to integrate it in OpenHab. For example, to mute the receiver you have to say “MO” (or, via MQTT, cmnd/pioneer/MO), and “MF” (or cmnd/pioneer/MF) to unmute. There is no “MUTE1”/“MUTE0”-like command which you could easily integrate via the Generic MQTT binding.
To make things a bit more convenient I added a few more MQTT topics that are generated (stat/pioneer/power, stat/pioneer/mute, stat/pioneer/volume,…) and understood (cmnd/pioneer/…).
The code is currently not very clean, and probably not production ready. It tries re-connecting quite aggressively to the avr, for instance (necessary in my case, because I turn it off completely rather than sending it to standby, and want it to respond quickly after re-powering). Not everyone might want to have it done that way in their network.
Nevertheless, I’d of course be happy to share if someone is interested and wants to give it a try.
Yes, the protocol is kinda weird, I read the protocol spec a few years ago. I think Pioneer knows about it but what can they do, now that this is kind of a “standard” ^^. I’d love to give your script a try!
Aw I was really going to give the binding development a shot again. But right now openHAB is in a transition state to new build infrastructure and only the bindings not yet moved can be developed on with the eclipse IDE. The other, already moved bindings cannot be seen there:
I’ll see if I can develop without Eclipse and only with maven. Read somewhere that this worked out for some people. At least I can prepare the features and apply them after the transition.
I started implementation work. The binding is already migrated to the new build system. Maggu posted a tutorial about how to develop the migrated bindings.