@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
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
@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
@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
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.
- 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)
- In the OH2 console, run
feature:uninstall openhab-binding-pioneeravr
to remove the installed 2.0.0.b2 binding / feature - In the OH2 console, run
bundle:install -s ...
to install my build of the binding - 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.