Yamahareceiver Binding problems

Tags: #<Tag:0x00007f6ce405d090>

(Tomasz Maruszak) #21

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.

(Ganesh) #22

@zarusz the dropbox jar isn’t downloading. Can you upload the binary to some github repo?

(Ganesh) #23

Never mind, the file got downloaded. However, it didn’t work on my 2.1.0-1 (latest official stable) release. I tried to get OH2.2 working in an independent manual location, but no luck so far. The initial deployer seem to go in an infinite deploy-undeploy-deploy cycle no matter what initial package I select (“simple”, “standard”, “minimal” etc.). Will try it whenever a stable or at least Test / Beta / Alpha / Release Candidate is published. I am no fan of SNAPSHOTS unless all developers are from same organization. :slight_smile:

(Tomasz Maruszak) #24

@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 :wink:

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) #25

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

(Tomasz Maruszak) #26

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">

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) #27

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.

(Ganesh) #28

Also there is a feature called Input Rename. A user can give a different name to an input, say HDMI1 => TV. Never tried this myself though. Not sure if the binding will have to take care of this specifically.

(David Graeff) #29

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


(Ganesh) #30

I agree. Most users don’t even know how to operate openhab, let alone the configuration and contribution here on this community on right thread/github branch. The binding has to “work” out of the box. @David_Graeff , give us some idea whats missing in current code, and how can we fix it. Or do we need to contact Yamaha engineers?

(Tomasz Maruszak) #31

@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) #32

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

(Jerome) #33

I think json would be needed anyway to support Musiccast devices too.

(Ganesh) #34

I like Yamaha for their excellent hardware. Wireless music streaming is something, in my opinion, should be handled by Kodi or Android or Apple iOS (Airplay). And Openhab being opensource platform, should team up with Kodi on dominating “living room” software market. I think Kodi and Openhab team should come up with an open standard for wireless music streaming. There is DLNA standard I think, but it never worked for me.

(Ganesh) #35

I can test this on my AVR. Let me make the change and if it works I will submit a PR. The json API will need a new binding I believe. Provided, enough developers are interested in supporting Yamaha’s intention to enter music library management and streaming devices market. Personally I use Kodi for music library management and playback. And I never had a situation where a music needs to be played back in multiple rooms. Important announcement (fire alert) needs to be played back in multi rooms. Music is very personal to each individual.

(Jerome) #36

I am using MusicCast in Multiroom with one source nearly everday, so i think it depends on the individual usecase for everyone.
I have never worked with Kodi before and i dont have a need for it at the moment.

With your approach i would not be Independent like i would be with a native binding.
I would have to dig into kodi, which i would need then only for using my yamaha hardware.
This sounds not efficient for me and my usecase.

(Udo) #37

I’m struggling with the Yamahareceiver binding for a while - getting the warning “Cannot delegate update” on all items:

2017-11-14 20:21:48.268 [WARN ] [nternal.profiles.ProfileCallbackImpl] - Cannot delegate update 'OFF' for item 'RXA2040Main_Zone_Zone_channels_Power' to handler for channel 'yamahareceiver:zone:5f9ec1b3_ed59_1900_4530_00a0deb772fc:Main_Zone:zone_channels#power', because no handler is assigned. Maybe the binding is not installed or not propertly initialized.

It’s not possible to send command to the receiver - that means the receiver is not responding.
But all items receiving correct updates from the receiver (operated via web-interface).

I’m now here:

  • RX-A2040 with zone: main, 2,3,
  • latest OH snapshot 2.2
  • .jar from the dropbox above

Yamahareceiver - Cannot delegate update
(Udo) #38

Update: same behavior after complete new install - only with yamaha binding.
I’m using now the http-binding to make progress with my concerns.


Switch Yamaha_Main "Yamaha Main" (gYamahaHTTP) { http=">[ON:POST:<YAMAHA_AV cmd=\"PUT\"><Main_Zone><Power_Control><Power>On</Power></Power_Control></Main_Zone></YAMAHA_AV>] >[OFF:POST:<YAMAHA_AV cmd=\"PUT\"><Main_Zone><Power_Control><Power>Standby</Power></Power_Control></Main_Zone></YAMAHA_AV>]" }

I could deliver logfiles or any other necessary information …

(Ganesh) #39

Try deleting and adding the thing. I have seen this problem in other bindings as well. The correlations between Things, Items and Links, sometimes gets corrupt.

(Udo) #40

Thank’s for the hint.
While reinstalling and using a current snapshot #1098 I did so.
And it’s working again.