mikerodrigues / onkyo_eiscp_ruby Goto Github PK

It seems that the new models are more strict regarding the header parsing.
see here:
paulianttila/openhab@31cfe65

When I send a PWRQSTN to my TX-NR636, I get this:

$ ./onkyo.rb PWRQSTN
/home/eric/.gem/ruby/2.2.0/gems/onkyo_eiscp_ruby-2.0.0/lib/eiscp/message.rb:60:in 'initialize': No value specified. (RuntimeError)
    from /home/eric/.gem/ruby/2.2.0/gems/onkyo_eiscp_ruby-2.0.0/lib/eiscp/parser/iscp_parser.rb:23:in 'new'
    from /home/eric/.gem/ruby/2.2.0/gems/onkyo_eiscp_ruby-2.0.0/lib/eiscp/parser/iscp_parser.rb:23:in 'parse'
    from /home/eric/.gem/ruby/2.2.0/gems/onkyo_eiscp_ruby-2.0.0/lib/eiscp/parser.rb:16:in 'parse'
    from /home/eric/.gem/ruby/2.2.0/gems/onkyo_eiscp_ruby-2.0.0/lib/eiscp/receiver.rb:164:in 'send_recv'
    from ./onkyo.rb:149:in '<main>'

There's some very basic stuff in command.rb

Translating between human readable names/descriptions for commands/parameters/values.

Would be nice to have something that allows command line arguments using names/descriptions as well, a la:

onkyo.rb system-power on

Possibly extending EISCP::Message.parse

This is - by far - the best implementation of eISPC I have found (and I have tried many).

Lots of repetition in this file.

discover method should be a command that utilizes Receiver's code via include or something

ECNQSTN is basically just a command that's not in the yaml file, and it would be nice to able to do things like Receiver.discover, Receiver.pause, Receiver.input("TV) without defining each of those methods in Receiver. This might be a bit high level for me, maybe something like:

Receiver.system-power("on")
Receiver.system-power("01")
Receiver.input-selector("TV")

When using the send_recv the result is always the same response, !NLSC-P
It seems that this is because every time send_recv is called, a new connection to the receiver is made. Testing with TCPSocket.new seems to indicate that the message is sent to indicate a new connection to the server has been made.

The documentation does specify that the client should make a continuous connection to receive updates so I'll either need to do away with send_recv or have it handle the NLSC-P message everytime. Either way, any method that makes a connection is going to have to handle the NLSC-P response. Distinction should be made between the initial NLSC-P response (indicating that client's connection), and subsequent NSLC-P responses, indicate other clients have connected.