Pioneeravr binding - volume up/down

@Stratehm, so far so good since the restart with the new jar, did you implement thread handling changes or similar?

Good news.

I have only enabled TCP KeepAlive and fixed connection closing when an error occurs.

@Stratehm, I think we can consider this fixed now, not a single issue since your fix was applied. Is this fix now in master as well? Again, big thanks for the quick fix :smile:

Also, more of a cosmetic follow up question, are the logs supposed to be ā€œfilledā€ with status updates for the pioneer binding? Are these as intended, some sort of early debug or similar? The below lines appear about 2 times per second in my OH2 logs right now.

2016-01-14 10:42:15.529 [INFO ] [ome.event.ThingStatusInfoEvent] - ā€˜pioneeravr:ipAvr:5F9EC1B3-ED59-79BF-4530-745e1c770747ā€™ updated: ONLINE
2016-01-14 10:42:15.530 [INFO ] [ome.event.ThingStatusInfoEvent] - ā€˜pioneeravr:ipAvr:5F9EC1B3-ED59-79BB-4530-00E036FB0397ā€™ updated: ONLINE
2016-01-14 10:42:15.533 [INFO ] [smarthome.event.ItemStateEvent] - FamilyRC_Mute updated to UNDEF
2016-01-14 10:42:15.535 [INFO ] [smarthome.event.ItemStateEvent] - FamilyRC_Vol updated to UNDEF
2016-01-14 10:42:15.536 [INFO ] [smarthome.event.ItemStateEvent] - FamilyRC_Input updated to
2016-01-14 10:42:15.537 [INFO ] [smarthome.event.ItemStateEvent] - FamilyRC_Power updated to OFF
2016-01-14 10:42:15.566 [INFO ] [smarthome.event.ItemStateEvent] - LivingRC_Mute updated to UNDEF
2016-01-14 10:42:15.568 [INFO ] [smarthome.event.ItemStateEvent] - LivingRC_Vol updated to UNDEF
2016-01-14 10:42:15.569 [INFO ] [smarthome.event.ItemStateEvent] - LivingRC_Input updated to
2016-01-14 10:42:15.570 [INFO ] [smarthome.event.ItemStateEvent] - LivingRC_Power updated to OFF

Iā€™m facing the exact same issue as @tobo.

My VSX-529 does not responde to VOLUME_SET (***VL) commands. The way I worked around this in OH1 was by creating 2 Dimmer items: AVR_Volume_Target (virtual) and AVR_Volume_Status (bound). The dimmer in my UI exercised the Target item and with a few rules, I would send the Status item INCREASE / DECREASE commands until Status == Target. I imagine the same thing can be done with OH2 but I havenā€™t tried it yet - still getting my feet wet with OH2.

Would it be a LGTM accepted solution to add this type of functionality at the binding level?

My thoughts were to probe the AVR by sending a VOLUME_SET query and receive either a VOL*** (supported) or R (unsupported) response. For models where setting the volume directly is unsupported, the binding could easily just send repeated INCREASE / DECREASE commands until the desired volume level is reached.

The advantage of doing this in the binding would allow other users of these types of AVRs to actually have a ā€œsupportedā€ thing in OH2 instead of getting an ā€œipAvrUnsupportedā€ thatā€™s unusable in the UI.

If thereā€™s interest in this, Iā€™ll dig in and see what I can whip up.

For me, since the WAF is the most important part of making automation fly, Iā€™m good with the +/- buttons to increase and decrease the volume. I use this on both receivers now, even the one supporting ***VL.

Iā€™m of course encouraging any increase in functionality, one thing Iā€™d use this for would be to set a starting volume in scenarios.

In the long run, I will not be keeping this receiver. However, this seems like an ā€œeasyā€ enough challenge to tackle that will get me familiar with the new OH2 architecture.

I got my IDE setup last night and started browsing through the binding and I donā€™t think it will be that difficult to implement (famous last words).

Iā€™ll see what I can come up with and report back.

Nice, let me know when you have something that you want help testing!

Also, fiddling around with the Rotini user interface today Iā€™ve come up with a couple of new use cases so it would def be good to have support for this ā€œfakedā€ percentage :slight_smile:

@Stratehm Did you push your TCP fixes into master? I had some issues when going OH2 beta 2 that went away by going back to your posted version above. It would be good to merge that fix for multiple reasons since it seems that people might be looking at adding additional functionality now :slight_smile:

@tobo If you donā€™t mind, please test my pioneeravr-2.0.0.201603141816 build with your AVR and report back.

The AVR will still show up in your Inbox as an ā€œunsupportedā€ Thing, but you should now be able to add it and link the Volume channel to a Dimmer.

Let me know if it works for you.

Edit: Link removed. See my more recent builds below

Tried it out somewhat with the following results in the logs.

At first startup (seems to be benign):
2016-03-13 19:41:41.879 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/opt/openhab2-beta/addons/org.openhab.binding.pioneeravr-2.0.0-SNAPSHOT-mgbowman-alpha1.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.pioneeravr [180]
Another singleton bundle selected: osgi.identity; osgi.identity=ā€œorg.openhab.binding.pioneeravrā€; type=ā€œosgi.bundleā€; version:Version=ā€œ2.0.0.201601051652ā€; singleton:=ā€œtrueā€

    at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1245)[8:org.apache.felix.fileinstall:3.5.0]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1217)[8:org.apache.felix.fileinstall:3.5.0]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:509)[8:org.apache.felix.fileinstall:3.5.0]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)[8:org.apache.felix.fileinstall:3.5.0]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)[8:org.apache.felix.fileinstall:3.5.0]

When setting the volume using a slider it just sends the value as usual however.

What Iā€™m guessing here is that my receiver, altough not supporting ***VL, is still being listed as a " ā€œPioneer AVR over IPā€ and not ā€œPioneer AVR over IP (unsupported)ā€. I even tried removing the item and re-adding without any change.

Not sure about the WARN message - Iā€™m still getting familiar with OH2. It might have something to do with the way I built the bundle. I just ran ā€˜mvn packageā€™ in the root pioneeravr binding directory - not 100% if this was all that was needed.

Regardless, the binding would only work for ā€œunsupportedā€ models as I wrote it that way to be less intrusive in the existing code. I will refactor the code so that it works for ā€œsupportedā€ models and post another build on my github. Iā€™ll also try testing it in a clean OH2 install to try and debug that exception youā€™re getting.

Hopefully Iā€™ll post another version sometime later tonight - will let you know.

Thanks man, appreciate the effort :slight_smile:

And just to clarify, the WARN is only seen on the first startup using the your binding, when restarting itā€™s not there so something with first run/initializing.

@tobo I think I discovered the root cause of your WARN message, I think you had the original binding / feature already installed.

New build is here pioneeravr-2.0.0.201603141816

Toying around with the new OH2 console hereā€™s how I recommend testing this.

  1. In the Paper UI, delete the pre-existing Pioneer ipAvr Thing youā€™ve already configured (not sure if this is necessary but it seems like the best approach to start with a clean state)
  2. In the OH2 console, run feature:uninstall openhab-binding-pioneeravr to remove the installed 2.0.0.b2 binding / feature
  3. In the OH2 console, run bundle:install -s ... to install my build of the binding
  4. In the Paper UI, re-create the Pioneer ipAvr Thing as usual and you should be able to link the Volume channel to a Dimmer and have it work as expected

I tested this procedure on a clean install of openhab-offline-2.0.0.b2

If youā€™re watching the openhab.log, you should see something similar to:
AVR @192.168.1.x:8102 - VOLUME_SET commands are UNSUPPORTED

Let me know how it goes for you.

Edit: Link removed. See my more recent builds below

openhab> bundle:install -s https://github.com/mgbowman/openhab2-addons/releases/download/pioneeravr-2.0.0.201603141816/org.openhab.binding.pioneeravr-2.0.0.201603141816.jar
Bundle ID: 181
Error executing command: Error installing bundles:
Unable to start bundle https://github.com/mgbowman/openhab2-addons/releases/download/pioneeravr-2.0.0.201603141816/org.openhab.binding.pioneeravr-2.0.0.201603141816.jar

Will fiddle around with it some more but that was the first try at least.

Removed the ā€œ-sā€ and that seemed to do the trick, also seemed to have three bundles of pioneer installed so i disabled the two lower ones and then actived 181 with bundle:start 181.

Bingo, now it works, big thanks!

Iā€™ll try it out some more but seems to be working as intended.

@tobo Glad to hear it!

I too had varying success with bundle:install -s ..., Iā€™m still getting familiar with the new console.

I would imagine you could just swap bundles but I couldnā€™t try. The 2.0.0.b2 bundle assigns my AVR a Thing UID of pioneeeravr:ipUnsupportedAvr and my 2.0.0.201603141816 bundle assigns it a pioneeeravr:ipAvr Thing UID. The different UID is what I think made OH2 pull its hair out when I tried to just swap bundles.

Thereā€™s still a little refactoring to be done on my patch before I can submit a PR upstream - it was a quick 'n dirty implementation. Iā€™ll let you know when I have something else to test and hopefully Iā€™ll figure out an easier way to swap the bundles.

@mgbowman sounds good, let me know when you need more assistance. Also, it might be worth to see if @Kai has any insights on the above or my question below.

Is there an agreed upon/standardized way for bindings.to report an unknown state, right now itā€™s UNDEF for the Pioneer binding, when receiver turned off, for items like mute/volume/input. Iā€™d like to.know if thatā€™s correct/undecided/incorrect before i push for support for that state, in Rotini as an example.

I would like to know this as well.

The behavior your describing is due to this chunk of code:

I know the 1.x binding did not do this so Iā€™m interested to know if this is ā€œdesiredā€ behavior.