Yamahareceiver Binding problems

Rickytr · September 29, 2017, 7:24pm

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

Rickytr · September 29, 2017, 8:21pm

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

zarusz · September 29, 2017, 9:09pm

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.

Rickytr · September 29, 2017, 10:03pm

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.

zarusz · September 30, 2017, 5:54am

@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.

Rickytr · October 1, 2017, 10:15am

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

Kai · October 7, 2017, 3:00am

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.

zarusz · October 7, 2017, 2:11pm

@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

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):

input_mapping_config.png1378×1003 75.4 KB

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.

Rickytr · October 8, 2017, 3:37pm

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

MHerbst · October 8, 2017, 6:00pm

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

zarusz · October 8, 2017, 8:13pm

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?

Confectrician · October 8, 2017, 8:24pm

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

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

zarusz · October 8, 2017, 9:31pm

At first I was also thinking the same. The only problem is that we would have to build this database (and keep on updating the addon) as users report how it works for their model. I am not sure if this direction is pragmatic…

I have a feeling (pure speculation) the existing mapping present in 2.2 the code accounted for a smaller user base but didn’t work out for the majority, thus removing this logic in code and letting the minority user base adjust mapping via configuration would be more optimal. I am awaiting feedback here…

On the documentation note please let me know if it is clear enough.

zarusz · October 9, 2017, 1:36pm

@ganesh.ingle it seems you have encountered the same issue (and here) I ran into myself with the OH2.2 SNAPSHOT few weeks ago.

Please perform the actions mentioned in the link, which is:

Stop OH2.2 service
Delete tmp and cache (/var/lib/openhab2/cache and /var/lib/openhab2/tmp)
Remove the JAR/kar files from addons folder
Start OH2.2 service
Drop the yamaha JAR to addons folder
Wait some time

Also, I am almost certain the yamaha JAR won’t work in OH2.1. You need to deploy it to the OH2.2 SNAPSHOT runtime.

David_Graeff · October 9, 2017, 8:03pm

We do feature testing for the dab feature and for the go menu back command already. We can also feature test if it’s HDMI1 or HDMI_1. Less configuration is always preferable.

Cheers David

zarusz · October 13, 2017, 10:26am

How would we go about detecting what the input name an AVR requires?

For instance, my AVR specifies HDMI_X as supported input, but reports HDMIX on status update (and in the selection command too) - see the <HDMI_1>Kodi:2</HDMI_1> here:

<YAMAHA_AV rsp="GET" RC="0">
    <System>
        <Config>
            <Model_Name>RX-S601D</Model_Name>
            <System_ID>0EE27BE3</System_ID>
            <Version>1.81/3.70</Version>
            <Feature_Existence>
                <Main_Zone>1</Main_Zone>
                <Zone_2>1</Zone_2>
                <Zone_3>0</Zone_3>
                <Zone_4>0</Zone_4>
                <Tuner>0</Tuner>
                <DAB>1</DAB>
                <HD_Radio>0</HD_Radio>
                <Rhapsody>0</Rhapsody>
                <Napster>0</Napster>
                <SiriusXM>0</SiriusXM>
                <Spotify>1</Spotify>
                <Pandora>0</Pandora>
                <JUKE>1</JUKE>
                <MusicCast_Link>1</MusicCast_Link>
                <SERVER>1</SERVER>
                <NET_RADIO>1</NET_RADIO>
                <Bluetooth>1</Bluetooth>
                <USB>1</USB>
                <iPod_USB>1</iPod_USB>
                <AirPlay>1</AirPlay>
            </Feature_Existence>
            <Name>
                <Input>
                    <HDMI_1>Kodi:2</HDMI_1>
                    <HDMI_2>Kodi</HDMI_2>
                    <HDMI_3>HDMI3</HDMI_3>
                    <HDMI_4>HDMI4</HDMI_4>
                    <HDMI_5>HDMI5</HDMI_5>
                    <HDMI_6>HDMI6</HDMI_6>
                    <AV_1>AV1</AV_1>
                    <AV_2>AV2</AV_2>
                    <AV_3>AV3</AV_3>
                    <AUX>AUX</AUX>
                    <AUDIO_1>AUDIO1</AUDIO_1>
                    <AUDIO_2>AUDIO2</AUDIO_2>
                    <AUDIO_3>AUDIO3</AUDIO_3>
                    <Bluetooth>Bluetooth</Bluetooth>
                    <USB>USB</USB>
                </Input>
            </Name>
        </Config>
    </System>
</YAMAHA_AV>

Unless, you are thinking about building a mapping configuration for each known model and applying the config during feature detection based on model name. Yet, I think building the mapping based on user feedback would take time…

Going back to my initial question, do we know for what AVR models was the built in mapping logic added (see my previous post)?

David_Graeff · October 15, 2017, 3:24am

Feature testing is done by just sending the command to the AVR and analyse the result. This means, that the AVR switches inputs on binding start (and switches back as well, if we write good code). This way no mapping needs to be created.

David_Graeff · October 15, 2017, 10:01am

No I guess not. The input constants stay the same. The binding reads the name property today already to support an optional set name.

Cheers
David

zarusz · November 4, 2017, 9:02pm

@ganesh.ingle I think @David_Graeff already provided an idea for the solution in an earlier post. Mainly during addon initialization we would have to switch the inputs to detect what comes back from the AVR (and restore original input). This would make the addon stateful. I think this is the best way forward.

On my side, I cannot implement this change currently as I switched apartments and left my AVR in another city - nowhere to test the changes. Unless you can wait, feel free to take a stab at the PR.

David_Graeff · November 5, 2017, 11:28am

Another idea is to implement the json protocol. I assume that they have fixed those naming issues and all receivers 2014+ support the new protocol.

Cheers David