Harman Kardon AVR


(Mikael Gustafsson) #1

Hi,

I just stumbled across this and this. It looks to me that the AVRs could be controlled, at least for basic functions like volume, on/off, source, using the http binding. I don’t have a device to test with, but am thinking of buying one and one big advantage would be if it worked with OpenHAB. Anybody able to test this?


(Lutz Fricke) #2

+1, I would like to see that too


(rooster) #3

I could try to add support to the av binding I’m currently working on. But unfortunately I don’t have Harman kardon receiver to try it with.


(Mikael Gustafsson) #4

That would certainly be nice. Unfortunately I can’t help, at least not yet and also I don’t know if there’s a way to get status back from the receiver.


(rooster) #5

HK seems to use an http api, which is not optimal for getting status back in any case. That’s actually the main reason I took the route of implementing Yamaha socket api as it provides status without constantly actively checking the api for changed statuses. The already existing Yamaha binding did the work ok, but I just hated the fact there was a delay in getting back the status changes.


(David Graeff) #6

What is a Yamaha socket API? Can that be used in the current Yamaha binding?


(rooster) #7

Yamaha YNCA protocol is used to communicate via TCP socket (likely also through RS-232), so when connected binding can “listen” to what’s going on at the receiver. I think the current Yamaha binding works through the http api, meaning it’s the binding that does request for states from the receiver on defined frequency instead of waiting for the receiver to send them.

http://files.remotecentral.com/library/22-1/yamaha/index.html

And yes, it would likely be quite simple to add that to the yamahareceiver binding as well, but my purpose was a bit two-fold as I also wanted to create a framework for other TCP Socket protocols, Denon receivers, epson projectors and some DIY things. Hence support for Yamaha eISCP was a good proof of concept :slight_smile:


(David Graeff) #8

Usually you combine functionality if there is a lot of shared code. Proof me wrong, but the only shared code here is tcp code, and that is basically already handled by ESH and OH and java?

Thanks for the hint with the tcp support though, I’ll add that to the Yamaha binding.

Cheers David


(rooster) #9

Couldn’t agree more on the principles of shared code. Here, my thinking is that all basic connection management as well as error etc handling is easily common, as well as the frame of the binding of course. All the protocols I’ve ran into so far have mainly the differences in the messages/payload structure, how I’ve done it so far is that the message content is defined in the xml files
for master volume for example:
Yamaha @MAIN:VOL={}
Denon MV{}
Epson Projector VOL {}
Onkyo MVL{}

And for specific protocols there may be requirements for handshakes etc which can be implemented to be done in connection initialization.
So generally there is a lot of shared code and very minor amount for actual device/protocol specific code,

If anyone is interested, take a look (not the tidiest ;): https://github.com/terolindberg/openhab2-addons/tree/avreceiver-dev/addons/binding/org.openhab.binding.avreceiver


(Joost Westra) #10

@Rooster Nice. It this already in a phase that we can test it for Harman Kardon receivers?