Recently i switched to OH2 from OH1.7 since the new binding for pioneer receiver actually supported multiple devices (OH1.7 only connected to the latest defined one in conf) and I’m happy with how it works apart from one caveat.
In the 1.7 binding there was support for the volume up (VU) and volume down (VD) commands used py pioneers telnet implementation. These functions have not been implemented in the 2.0 binding. The problem with this is that some newer (weirdly enough) models don’t support the command ***VL command to set the volume but rather just increasing/decreasing.
At the moment I’ve solved this by running one of my pioneer receivers that supports the ***VL on the 2.0 binding while using the 1.7 binding at the same time for the the reciever that only supports VU/VD.
Is there anyone that can have a look and update the 2.0 pioneeravr binding with these two additional channels? I’d be happy to help out in what way I can. It would be nice to be able to go full 2.0 for the Pioneers.
The binding binds VU/VD commands to INCREASE/DECREASE events and ***VL command to Percent events.
I suppose you use the PaperUI interface and AFAIK, there is no way to trigger INCREASE/DECREASE events through the dimmer rendered by PaperUI to control the volume since it lacks of UP/DOWN buttons. Only Percent events are triggerd by the dimmer.
I think you could achieve your needs with the Classic UI;
Sorry for not understanding exactly but are you saying the 2.0 binding actually supports VU/VD but the channels aren’t exposed in PaperUI?
I basically just use PaperUI for some basic Things addition and mapping to exposed channels but if I’m also working a lot in the config files for more detailed stuff. As mentioned, I’m using the 1.7 pioneerav as well and that’s all config file.
Indeed, the 2.0 binding actually supports VU/VD. The channel to send these commands is the same as the one which sends the ***VL command.
PaperUI does not tell to the binding to increase or decrease the volume (and so to use the VL/DL commands), but instead it tells to the binding to set the volume to a given value (so to use the ***VL command).
I thins the feature is not complete in PaperUI, there should be an increase and a decrease button displayed near the slider.
If you use Classic UI, you may try the following configuration:
In the *.things file:
I’ve now tried your solution and even disabling existing Things to be able to define them myself, everything working as expected which means that I get a working slider for pioneer1 (let’s call it that) and a non-functioning slider for pioneer2. No buttons that display + or -. Are you thinking setpoint, am I confused, is something overlooked?
Ahhhh, you are most correct, sir. That does send INCREASE/DECREASE. That didn’t work in the old binding so I never even thought of trying it
So, going into the classic UI using Chrome I get this behavior which is perfect, is there a way to get the same thing going in HabDroid? With the same sitemap that becomes a slider.
And yes, I saw the logs screaming when using quotations so I removed them.
I’m guessing I need to either make a button or similar in order to “trick” the binding to send INC/DEC or I need habdroid to be changed. Would you happen to know who to turn to in order to get some answers on this?
Maybe I was a bit premature in saying that everything is working now. I have both receivers up and running and when starting OpenHAB both of them are connected and updating as they should. After a while though I loose connection to the “first” receiver even though the “second” one works fine. I see these error messages about a broken pipe in the logs which is related to the problem, see below.
Anything I can do in order to investigate this further or help out?
2015-12-24 10:01:26.761 [ERROR] [.o.b.p.i.p.StreamAvrConnection] - Error occured when sending command
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method) ~[na:1.8.0_66]
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) ~[na:1.8.0_66]
at java.net.SocketOutputStream.write(SocketOutputStream.java:132) ~[na:1.8.0_66]
at java.io.DataOutputStream.writeBytes(DataOutputStream.java:276) ~[na:1.8.0_66]
at org.openhab.binding.pioneeravr.internal.protocol.StreamAvrConnection.sendCommand(StreamAvrConnection.java:156) [bundleFile:na]
at org.openhab.binding.pioneeravr.internal.protocol.StreamAvrConnection.sendPowerQuery(StreamAvrConnection.java:172) [bundleFile:na]
at org.openhab.binding.pioneeravr.internal.handler.AbstractAvrHandler.checkStatus(AbstractAvrHandler.java:143) [bundleFile:na]
at org.openhab.binding.pioneeravr.internal.handler.AbstractAvrHandler.access$2(AbstractAvrHandler.java:140) [bundleFile:na]
at org.openhab.binding.pioneeravr.internal.handler.AbstractAvrHandler$1.run(AbstractAvrHandler.java:84) [bundleFile:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_66]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_66]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_66]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_66]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_66]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_66]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]
I never had this problem with my AVR. Broken pipe means that the AVR has closed the connection on its side without telling us it has. It could happen on a network failure, on the AVR power off (or maybe going idle) or bad TCP socket implementation in the AVR (I do not think it is the case).
In all cases, the binding has a problem with handling such errors. I will try to improve the error handling. Since I cannot reproduce the problem, could you make some testing with the new binding ?
Of course, one test I plan to run is to just add the receiver that is currently giving me issues to see if it’s a thread thing or similar (meaning that a single receiver setup works but not a dual one). Just describe what else you want me to test out and I’ll be glad to help.
It seems that after a power outage at our house the connections does not get dropped anymore. I’ll let it run without restarting for a while but maybe that receiver just needed a breather. I’m hoping that the issue doesn’t come back.
