Yamahareceiver Binding problems

yamahareceiver
Tags: #<Tag:0x00007f6ce6035c28>

(Riccardo Rossi) #1

I’m using openhab 2.2.0 build 1051 and I have some minor problems with Main zone of my yamaha receiver.
To change the input I set the HDMI’s to HDMI1, HDM2 etc. and with this the command goes well but it seems that current input is read as HDMI_1, HDMI_2 etc. . In event log I find this:

017-09-29 21:12:08.195 [ome.event.ItemCommandEvent] - Item ‘AMP_Input’ received command HDMI1
2017-09-29 21:12:08.205 [vent.ItemStateChangedEvent] - AMP_Input changed from HDMI_1 to HDMI1
2017-09-29 21:12:08.417 [vent.ItemStateChangedEvent] - AMP_Input changed from HDMI1 to HDMI_1

every time I switch and HDMI input.

Another minor problem is that yamaha things seems to update something every minute:

2017-09-29 21:18:37.970 [me.event.ThingUpdatedEvent] - Thing ‘yamahareceiver:zone:5f9ec1b3_ed59_1900_4530_00a0dea1f5e0:Main_Zone’ has been updated.
2017-09-29 21:19:38.058 [me.event.ThingUpdatedEvent] - Thing ‘yamahareceiver:zone:5f9ec1b3_ed59_1900_4530_00a0dea1f5e0:Main_Zone’ has been updated.
2017-09-29 21:20:38.116 [me.event.ThingUpdatedEvent] - Thing ‘yamahareceiver:zone:5f9ec1b3_ed59_1900_4530_00a0dea1f5e0:Main_Zone’ has been updated.
2017-09-29 21:21:38.255 [me.event.ThingUpdatedEvent] - Thing ‘yamahareceiver:zone:5f9ec1b3_ed59_1900_4530_00a0dea1f5e0:Main_Zone’ has been updated


(Ganesh) #2

I use Yamaha receiver and OH2.1.0. Not such problem in my setup.
Maybe some bug got introduced between 2.1.0 to current version of the plugin. Try switching to latest version. Try closing all your browsers, they might be submitting thing config updates due a strange bug.
Do you have any other REST JSON api clients that might be submitting config updates to the binding?


(Riccardo Rossi) #3

I didn’t have this kind of problems in 2.1. I think the one I’m using is the latest version…


(Ganesh) #4

Should submit a bug to maintainer


(Tomasz Maruszak) #5

I also have OH2.2 build 1051 and in my case it works as expected. Here is how it looks when changing from tuner input to HDMI1:

2017-09-29 22:47:15.821 [ome.event.ItemCommandEvent] - Item 'Yamaha_Input' received command HDMI1
2017-09-29 22:47:15.828 [vent.ItemStateChangedEvent] - Yamaha_Input changed from TUNER to HDMI_1
2017-09-29 22:47:15.907 [vent.ItemStateChangedEvent] - Yamaha_Input changed from HDMI_1 to HDMI1

Here is my sitemap:

Selection	item=Yamaha_Input				mappings=[HDMI1="Kodi",HDMI2="PC",AUDIO1="TV",TUNER="Tuner",Spotify="Spotify",Bluetooth="Bluetooth","NET RADIO"="NetRadio"]

In my case the input command HDMI1 is later read back as HDMI_1 from the device, but then converted back (presumably by the addon?) to HDMI1. This does not seem to happen for you @Rickytr

When I was contributing a PR for this yamaha binding version (unrelated to input selection) I experienced a similar weird behavior back then, but looking now this seems to be resolved (at least for my Yamaha model). I recall when testing what flies over the network wire, my model required HDMI1 as command, but then reported back HDMI_1 upon device status read (pretty much inconsistent).

Also looping in @David_Graeff to weigh in.

I suggest to submit an issue on GitHub and I could look into this if you’d be able to help test on your model @Rickytr.


(Riccardo Rossi) #6

This is exactly what’s happening. And I think that the continuous updating of the yamaha thing is related to this strange behaviour of input. I’ll submit the issue on Github. Thanks a lot.


(Ganesh) #7

I will look into this at least at code level. I don’t have OH2.2 setup. If Yamaha2.2 plugin deploys on my OH2.1, the problem will reproduce on my site. Then I can test it properly. I got Yamaha RXV475 AVR.


(Ganesh) #8

@Rickytr Did you update the yamaha firmware to latest? Might be issue on Yamaha side.


(Tomasz Maruszak) #9

@Rickytr can you please verify one more thing before submitting a bug? Go into the PaperUI -> Configuration -> Things -> (Yamaha Receiver thing) -> Edit -> Show more and check the refresh interval setting. On my setup this is set to 30 seconds.

Please paste the ticket ID once you do that.


(Riccardo Rossi) #10

The refresh interval is at 60 seconds and the receiver is updated.
The ticket is #2758.


(Ganesh) #11

I can confirm this issue on OH2.2 and Yamaha RX-V475. It is introduced somewhere in between 2.1 to 2.2 enhancements of this binding. It seems input selection HDMI, Net Radio, AirPlay is not working. The Surround Program selection also doesn’t work. Input switch to AV, Audio, Server, Spotify, Tuner, Usb, V-aux works correctly.


(Ganesh) #12

I rolled back to 2.1.0 binding, which is far more stable in terms of connectivity and basic functionality.
I had to modify openhab-addons-2.2.0-SNAPSHOT.kar to remove references to yamaha binding from openhab-addons-2.2.0-SNAPSHOT-features.xml and delete binding jar from within the kar. I then had to extract old binding jar from openhab-addons-2.1.0-SNAPSHOT.kar and copy to deploy folder. @Kai I wish there was a simple mechanism to roll back binding versions to previous stable ones if a user is much more comfortable with those. User may want to try 2.2 but still want to stick with known working stuff from 2.1.


(Kai Kreuzer) #13

I would wish all users help bringing the snapshot version on par with the previous release (by reporting bugs and helping analyze the problems) - after all, when we do a 2.2 release, it should not be a step back for anyone, but the bindings should be better than before instead.


(Tomasz Maruszak) #14

@Rickytr and @ganesh.ingle taking aside the the refresh rate for now, I was able to reproduce the sane #2758 issue with HDMI on my Yamaha AVR.

I made some changes in an attempt to fix the HDMI input selection.

Could you guys verify on your AVRs ?

Here is what I observed:

  • My Yamaha requires HDMI1 as command and reports HDMI1 on status update.
  • The 2.2 Yamaha binding converts the HDMI1 to HDMI_1 which causes the error on my Yamaha model (and probably for @Rickytr). Looking at the code comments, this was required by some Yamaha models. Unfortunately, this breaks other models :slight_smile:

Here is the proposed implemented fix:

  • I have added a thing configuration that allows the user to map input names and customize for their specific AVR. It works in this way:
    • When input status update is obtained the addon checks if there is user defined mapping it could use
    • Otherwise, it falls back to the existing logic (i.e. HDMI1 => HDMI_1)
  • This should work for other edge cases (i.e. USB, iPod_USB)
  • Here is how you configure the mapping (PaperUI > Configuration > Things > Edit > Yamaha Receiver XXX):

How to deploy the fix?

  • Make sure you are on OH2.2.
  • Download JAR from DropBox
  • Drop the JAR into your addons folder.
  • If needed adjust the mapping setting in the thing configuration.

Debugging
If you want to see some useful logs while debugging add something like this to userdata\etc\org.ops4j.pax.logging.cfg

log4j2.logger.yamaha.name = org.openhab.binding.yamahareceiver
log4j2.logger.yamaha.level = TRACE

After binding init you should see something like this:

2017-10-07 15:21:18.723 [TRACE] [ernal.protocol.xml.InputConverterXML] - User defined mapping: HDMI1=HDMI1,HDMI2=HDMI2,HDMI3=HDMI3,HDMI4=HDMI4,HDMI5=HDMI5,HDMI6=HDMI6
2017-10-07 15:21:18.726 [TRACE] [ernal.protocol.xml.InputConverterXML] - Number of user defined mappings found: 6
2017-10-07 15:21:18.905 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name Spotify to Spotify
2017-10-07 15:21:18.912 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name JUKE to JUKE
2017-10-07 15:21:18.919 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name MusicCast Link to MUSICCAST_LINK
2017-10-07 15:21:18.915 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name AirPlay to AIRPLAY
2017-10-07 15:21:18.930 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name SERVER to SERVER
2017-10-07 15:21:18.944 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name NET RADIO to NET_RADIO
2017-10-07 15:21:18.947 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name Bluetooth to Bluetooth
2017-10-07 15:21:18.947 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name USB to USB
2017-10-07 15:21:18.956 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name TUNER to TUNER
2017-10-07 15:21:18.967 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name HDMI1 to HDMI1 - as per user defined mapping
2017-10-07 15:21:18.970 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name HDMI2 to HDMI2 - as per user defined mapping
2017-10-07 15:21:18.973 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name HDMI3 to HDMI3 - as per user defined mapping
2017-10-07 15:21:18.975 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name HDMI4 to HDMI4 - as per user defined mapping
2017-10-07 15:21:18.978 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name HDMI5 to HDMI5 - as per user defined mapping
2017-10-07 15:21:18.982 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name HDMI6 to HDMI6 - as per user defined mapping
2017-10-07 15:21:18.990 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name AV1 to AV1
2017-10-07 15:21:18.990 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name AV2 to AV2
2017-10-07 15:21:18.999 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name AV3 to AV3
2017-10-07 15:21:18.999 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name AUDIO1 to AUDIO1
2017-10-07 15:21:19.002 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name AUDIO2 to AUDIO2
2017-10-07 15:21:19.006 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name AUDIO3 to AUDIO3
2017-10-07 15:21:19.009 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name AUX to AUX
2017-10-07 15:21:19.013 [TRACE] [.protocol.xml.ZoneAvailableInputsXML] - Zone Main_Zone - available inputs: AIRPLAY, AUDIO1, AUDIO2, AUDIO3, AUX, AV1, AV2, AV3, Bluetooth, HDMI1, HDMI2, HDMI3, HDMI4, HDMI5, HDMI6, JUKE, MUSICCAST_LINK, NET_RADIO, SERVER, Spotify, TUNER, USB

Note: User defined mappings have as per user defined mapping and the rest comes is the existing addon mapping logic.

After switching to HDMI 1 you should see this:

2017-10-07 15:25:52.312 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from HDMI1 to command name HDMI1
2017-10-07 15:25:52.464 [TRACE] [ernal.protocol.xml.InputConverterXML] - Converting from state name HDMI1 to HDMI1 - as per user defined mapping
2017-10-07 15:25:52.469 [TRACE] [internal.protocol.xml.ZoneControlXML] - Zone Main_Zone state - power: true, input: HDMI1, mute: false, surroundProgram: 5ch Stereo, volume: 32.608696
2017-10-07 15:25:52.492 [DEBUG] [eiver.handler.YamahaZoneThingHandler] - Input changed to HDMI1

Lastly, here is my sitemap fragment if that helps:

Selection	item=Yamaha_Input				mappings=[HDMI1="Kodi",HDMI2="PC",AUDIO1="TV",TUNER="Tuner",Spotify="Spotify",Bluetooth="Bluetooth","NET RADIO"="NetRadio"]
Selection	item=Yamaha_Surround			mappings=["2ch Stereo"="2ch Stereo","5ch Stereo"="5ch Stereo",Straight="Straight","Chamber"="Chamber","Sci-Fi"="Sci-Fi","Adventure"="Adventure"]

Let me know.


(Ganesh) #15

@zarusz Thanks for your efforts on this. I will try it on my Yamaha RXV 475 model. We should document the mappings for each Yamaha model. Users should try out and report to maintainer or here on forum, what is working on their model.


(Riccardo Rossi) #16

@zarusz I installed the new version and everything seems to work well. I think this is a brilliant solution. Thanks a lot.


(Martin Herbst) #17

I really like this solution. You should create a PR for it


(Tomasz Maruszak) #18

Thanks everyone for the feedback. Yes, the plan is to make a PR once we test this. I know the input selection was a pain due to differences between models. I have added some documentation to the addon README, that will make its way to the PR.

Now, I propose we drop the existing mapping logic coded into the addon, and let the users leverage the introduced thing setting (Input mapping) to cater for their (older) models that work in this weird way (HDMI1 vs HDMI_1). Unfortunately, this might mean breaking functionality for some users, but I believe it would be more clean going forward. @David_Graeff please share your insight here.

To recap, the existing mapping logic is like this:

  • Each space to _ AND make upper case:
    • Example: Net Radio => NET_RADIO
    • Example: Hdmi 1 => HDMI_1
    • Example: AUDIO 1 => AUDIO_1
  • HDMI X => HDMI_X
  • HDMIX => HDMI_X

This could be replaced by the proposed thing mapping setting.

What do you think?


(Jerome) #19

The Binding Documentation Article would be the best place for something like this. :slight_smile:

@zarusz:
I like your proposal und would appreciate it. :slight_smile:


(Ganesh) #20

Known working mappings for a given model can be auto-populated by the binding from its internal database. I believe it does know the model.