sky201503 / openhab

Automatically exported from code.google.com/p/openhab
GNU General Public License v3.0
0 stars 0 forks source link

Implement Onkyo Binding for AV-Receivers #216

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
It would be great to power on/off Onkyos AV-Receivers.

Original issue reported on code.google.com by christop...@gmail.com on 23 Mar 2013 at 5:00

GoogleCodeExporter commented 8 years ago
You mean the models with an Ethernet interface? Simple functions should already 
be possible through the TCP-binding.
I actually have a AVR with a serial port and I can control it through the 
serial binding.

Original comment by kai.openhab on 24 Mar 2013 at 8:07

GoogleCodeExporter commented 8 years ago
for Onkyo receivers there is also available the eISCP protocol (see 
https://sites.google.com/a/webarts.ca/toms-blog/Blog/new-blog-items/javaeiscp-in
tegraserialcontrolprotocol).

My TX-NR616 is pretty much waiting to be controlled by openHAB. So i'll 
volunteer as Beta-Tester :-) (at least)

Original comment by teichsta on 24 Mar 2013 at 9:21

GoogleCodeExporter commented 8 years ago
Just committed initial version of the Onkyo binding on my clone.

It's tested with Onkyo TX-NR818 model.

Usage:

openhab.cfg:
onkyo:hometheater.host=192.168.1.10
onkyo:hometheater.port=60128

item config:
Switch onkyoPower  {onkyo="ON:hometheater:POWER_ON, OFF:hometheater:POWER_OFF"}
Dimmer onkyoVolume {onkyo="INCREASE:hometheater:VOLUME_UP, 
DECREASE:hometheater:VOLUME_DOWN"}

Original comment by pauli.an...@gmail.com on 18 Apr 2013 at 7:33

GoogleCodeExporter commented 8 years ago
WAAAAH COOL :-)

Will Review after GeeCON latest - since there is much work to do!

THANKS for pushing this issue ...

Original comment by teichsta on 18 Apr 2013 at 8:23

GoogleCodeExporter commented 8 years ago

Original comment by teichsta on 7 May 2013 at 3:48

GoogleCodeExporter commented 8 years ago
I'd like to test this tomorrow with TX-NR616.
However, I could not find the compiled add-on.

Is this available somewhere? Pauli, could you attach it?

Thank you very much anyway :)

Original comment by honkton...@gmail.com on 7 May 2013 at 5:56

GoogleCodeExporter commented 8 years ago

Original comment by teichsta on 7 May 2013 at 8:25

GoogleCodeExporter commented 8 years ago
So, is there any news on this?
May someone please push/attach a compiled addon?

Thx

Original comment by honkton...@gmail.com on 16 May 2013 at 1:01

GoogleCodeExporter commented 8 years ago
So, I finally got to compile the addon myself just to find my TX-NR616 to NOT 
support the eISCP protocol :-(

Maybe other users want to try their Onkyo with openhab, so I attached the 
compiled addon for testing.

Original comment by hlw31...@gmail.com on 17 May 2013 at 7:40

Attachments:

GoogleCodeExporter commented 8 years ago
eISCP protocol spec v1.21 from year 2011 defines commands for 
TX-NR509/TX-NR609/TX-NR709/TX-NR809/... (previous models). So it's hard t 
believe that Onkyo has drop the eISCP support from TX-NR616 series.

Original comment by pauli.an...@gmail.com on 17 May 2013 at 4:51

GoogleCodeExporter commented 8 years ago
You're right-I was blinded by a portscan and the non-functioning onkyo-binding 
:-(
The port is hidden when scanned:

sascha@wandboard:~$ nmap onkyo
Starting Nmap 5.21 ( http://nmap.org ) at 2013-05-18 08:32 CEST
Nmap scan report for onkyo (10.0.0.40)
Host is up (0.029s latency).
rDNS record for 10.0.0.40: Onkyo.fritz.box
Not shown: 997 closed ports
PORT     STATE    SERVICE
23/tcp   filtered telnet
80/tcp   open     http
8888/tcp open     sun-answerbook

Thanks for your comment :)

Original comment by honkton...@gmail.com on 18 May 2013 at 6:33

GoogleCodeExporter commented 8 years ago
Non functioning onkyo binding? Do you have problems with the binding itself?

Original comment by pauli.an...@gmail.com on 21 May 2013 at 2:30

GoogleCodeExporter commented 8 years ago
Update: I can power ON/OFF successfully but volume is not working with "osgi> 
openhab send onkyoVolume 35
22:31:40.790 WARN  o.o.b.o.internal.OnkyoBinding[:88] - Doesn't find matching 
binding provider [itemName=onkyoVolume, command=35]
22:31:40.798 INFO  runtime.busevents[:42] - onkyoVolume received command 35
Command has been sent successfully."

Sending INCREASE or DECREASE commands returns successful, however nothing 
happens.

TR616 with Firmware 2013-04-11

Original comment by honkton...@gmail.com on 21 May 2013 at 8:35

GoogleCodeExporter commented 8 years ago

Original comment by teichsta on 21 May 2013 at 9:38

GoogleCodeExporter commented 8 years ago
Pauli, if've pushed your initial version to the default branch. Thank you very 
much for this contribution. As you will see i refactored the Eiscp protocol 
class to make it more readable. Since i am not at home at the home. Could you 
try with tomorrows daily build if still everything is working?

Pauli, could you also please add the Wiki-documentation for your new binding 
(http://code.google.com/p/openhab/wiki/OnkyoBinding)?

Thanks again for your contribution! And keep coding for openHAB ;-)

Original comment by teichsta on 21 May 2013 at 9:57

GoogleCodeExporter commented 8 years ago
@15: Thanks for adding it to default. I hope more people are then testing and 
giving feedback :)

@Pauli: I added a hack to send plain volume to the receiver. On this way I 
stumbled over a bug inside eiscp's getVolumeCmdStr function which affected low 
volumes.

On the group, I asked for help on how to check my changes in ;-)

Original comment by hlw31...@gmail.com on 22 May 2013 at 8:53

GoogleCodeExporter commented 8 years ago
Wiki page added

Original comment by pauli.an...@gmail.com on 29 May 2013 at 8:07

GoogleCodeExporter commented 8 years ago
Because not all Onkyo commands are currently supported, I tested one idea to 
improve the support.

1) added wildcard (*) support
2) Added advanced command support to send any kind of eISCP commands. Advanced 
command start with # character. Command itself is a direct eISCP command + Java 
String.formatted openhab command value (e.g. %02X).

example 1:

Dimmer volume { onkyo="INCREASE:hometheater:VOLUME_UP, 
DECREASE:hometheater:VOLUME_DOWN, *:hometheater:#MVL%02X" }

openhab send volume INCREASE -> binding send VOLUME_UP (eISCP command=MVLUP)
openhab send volume DECREASE -> binding send VOLUME_DOWN (eISCP command=MVLDOWN)
openhab send volume 30 -> binding send eISCP command MVL1E (set volume level to 
30)

example 2: Number zone4Selector { onkyo="*:hometheater:#SL4%02X" }
example 3: Switch onkyoPower { onkyo="*:hometheater:#PWR%02X" }

So whit this improvement, all eISCP commands should be supported.

User perceptive advanced command is not so easy to use, but least there a way 
to support most of the commands now and the future.

Original comment by pauli.an...@gmail.com on 30 May 2013 at 4:36

GoogleCodeExporter commented 8 years ago
Is the latest change with wildcard already pulled from Pauli's repo?

I just tested with snapshot #423 and this config:
Dimmer onkyoVol    { onkyo="INCREASE:amp:VOLUME_UP, DECREASE:amp:VOLUME_DOWN, 
*:amp:#MVL%02X" }

results in:
12:54:01.724 ERROR o.o.m.i.i.GenericItemProvider[:226] - Binding information of 
type 'onkyo' for item ‘onkyoVol‘ could not be parsed correctly.
org.openhab.model.item.binding.BindingConfigParseException: Unregonized command 
'#MVL%02X'
        at org.openhab.binding.onkyo.internal.OnkyoGenericBindingProvider.parseBindingConfig(OnkyoGenericBindingProvider.java:130)
        at org.openhab.binding.onkyo.internal.OnkyoGenericBindingProvider.parseBindingConfig(OnkyoGenericBindingProvider.java:135)
        at org.openhab.binding.onkyo.internal.OnkyoGenericBindingProvider.parseBindingConfig(OnkyoGenericBindingProvider.java:135)
        at org.openhab.binding.onkyo.internal.OnkyoGenericBindingProvider.processBindingConfiguration(OnkyoGenericBindingProvider.java:106)
        at org.openhab.model.item.internal.GenericItemProvider.dispatchBindings(GenericItemProvider.java:224)
        at org.openhab.model.item.internal.GenericItemProvider.getItems(GenericItemProvider.java:137)
        at org.openhab.core.internal.items.ItemRegistryImpl.allItemsChanged(ItemRegistryImpl.java:226)
        at org.openhab.model.item.internal.GenericItemProvider.modelChanged(GenericItemProvider.java:270)
        at org.openhab.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:176)
        at org.openhab.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:117)
        at org.openhab.model.core.internal.folder.FolderObserver.checkFolder(FolderObserver.java:162)

Cheers

Original comment by hlw31...@gmail.com on 12 Jun 2013 at 10:55

GoogleCodeExporter commented 8 years ago
Advanced command is not yet merged to main repo. 

I have improved binding since advanced command. Now binding also listening 
status updates from receiver and there is init command support, which can be 
used to query current value on startup.

Some test items:

Switch  onkyoPower1     { onkyo="ON:hometheater:POWER_ON, 
OFF:hometheater:POWER_OFF" }
Switch  onkyoPower2     { onkyo="INIT:hometheater:#PWRQSTN, *:hometheater:#PWR%02X" 
}
Dimmer  onkyoVolume     { onkyo="INCREASE:hometheater:VOLUME_UP, 
DECREASE:hometheater:VOLUME_DOWN, *:hometheater:#MVL%02X" }
Dimmer  onkyoVolume2        { onkyo="INIT:hometheater:VOLUME_QUERY, 
INCREASE:hometheater:VOLUME_UP, DECREASE:hometheater:VOLUME_DOWN, 
*:hometheater:SET_VOLUME" }
Switch  onkyoMute       { onkyo="*:hometheater:#AMT%02X" }
Switch  onkyoMute2      { onkyo="ON:hometheater:MUTE, OFF:hometheater:UNMUTE" }

Code is already available on my clone ("onkyo binding mods" branch). Code is 
pretty much complete, but I want tested little bit more before merge changes to 
main clone branch.

Original comment by pauli.an...@gmail.com on 12 Jun 2013 at 1:46

GoogleCodeExporter commented 8 years ago
Onkyo binding for testing purposes

Original comment by pauli.an...@gmail.com on 12 Jun 2013 at 6:04

Attachments:

GoogleCodeExporter commented 8 years ago
thanks for this update!

Original comment by teichsta on 13 Jun 2013 at 6:41

GoogleCodeExporter commented 8 years ago
can anybody confirm the new functionality is working?

Could then merge changes to default branch ...

Original comment by teichsta on 18 Jun 2013 at 5:34

GoogleCodeExporter commented 8 years ago
I verifyed and it's working great with my TX-NR616.
However - I'd like the status update to be configured to be scheduled like 
'check power state every 5 seconds' rather than only on startup. If my wife 
turns the thing on with remote/power button openhab won't notice :(

Original comment by honkton...@gmail.com on 18 Jun 2013 at 7:42

GoogleCodeExporter commented 8 years ago
Binding is listening status updates from receiver all the time, so item state 
should be changed immediately when state is changed on receiver (receiver will 
send an status update to binding). Startup query is just for synchronise 
current state from the receiver. 

Example. If you change volume via remote control, openhab item should be 
updated automatically as well.

Original comment by pauli.an...@gmail.com on 18 Jun 2013 at 8:12

GoogleCodeExporter commented 8 years ago
And I forgot the say, that power state should be updated as well. At least for 
me it working nicely. If I power on the receiver via power button or via 
remote, openhab item state is immediately updated to correct state.

Original comment by pauli.an...@gmail.com on 18 Jun 2013 at 8:21

GoogleCodeExporter commented 8 years ago
You're right - power state updates just fine. 

But when powered on, I get this every 5 seconds:
22:24:00.716 ERROR o.o.b.o.internal.eiscp.Eiscp[:578] - Error occured during 
message waiting
java.io.IOException: Illegal start char
        at org.openhab.binding.onkyo.internal.eiscp.Eiscp.waitStateMessages(Eiscp.java:485)

My items are defined like this:
Switch onkyoPower  { onkyo="ON:amp:POWER_ON, OFF:amp:POWER_OFF, 
INIT:amp:#PWRQSTN" }
Switch onkyoMute   { onkyo="ON:amp:MUTE, OFF:amp:UNMUTE" }
Dimmer onkyoVol    { onkyo="INCREASE:amp:VOLUME_UP, DECREASE:amp:VOLUME_DOWN, 
*:amp:#MVL%02X" }

What's the sense behind splitting power into two items?

Original comment by honkton...@gmail.com on 18 Jun 2013 at 8:27

GoogleCodeExporter commented 8 years ago
hmmm...binding is receiving something is not recognised by the binding. Every 
ISCP message should start with ! character, if not "illegal start char" 
exceptions is thrown. 

Could you run openhab with debug prints and attach a log file here?

What do you mean by splitting power into two items?

Original comment by pauli.an...@gmail.com on 18 Jun 2013 at 8:43

GoogleCodeExporter commented 8 years ago
Seems like I had a mixed-up runtime. I just restartet openhab several times and 
testing now shows it's working like expected. Running in debug I get this when 
power state is changed:
05:33:03.258 DEBUG o.o.b.o.internal.eiscp.Eiscp[:557] - Received status 
message: PWR01
05:33:03.259 DEBUG o.o.b.o.internal.OnkyoBinding[:346] - Received status update 
'PWR01' from device 10.0.0.40

No more Illegal start char :) Maybe the distribution bundle was not completely 
uninstalled - I don't know.

Concerning "two power items": You demo items in #20 split commands to device 
and power state into two items (onkyoPower1 & onkyoPower2). I understood it 
this way: You need to seperate commands and status into two items. However, 
testing shows this is not needed.

Thanks for this great bundle! Btw, is there a way to specify "play this 
streaming url" like some internet radio url? Would be great to hear my favorite 
radio when coming home and my wife gets hers ;)

Original comment by honkton...@gmail.com on 19 Jun 2013 at 3:39

GoogleCodeExporter commented 8 years ago
Well, seems to be having a bug after some time:
Today, I powered on the AVR and openhab did not get it. I checked the console 
and found 19:40:10.506 ERROR o.o.b.o.internal.eiscp.Eiscp[:578] - Error occured 
during message waiting
java.net.SocketException: Connection reset
        at java.net.SocketInputStream.read(SocketInputStream.java:134)

Original comment by honkton...@gmail.com on 19 Jun 2013 at 5:41

GoogleCodeExporter commented 8 years ago
Appendix for #30:
My AVR had network problems. Connecting to it via Onkyo-App for Android was 
also not possible. So no chance for the binding either.

However, recovering did not cause the binding to recover. Even stopping it on 
the console did not stop the Eiscp failures to disappear. Restarting openhab 
restored a stable state.
Maybe the binding needs to correctly stop the eiscp depency?

Original comment by honkton...@gmail.com on 19 Jun 2013 at 7:33

GoogleCodeExporter commented 8 years ago
I was able to reproduce the problem by unplugging the the receiver power plug. 

Now connection is reopened when any error occurs. eiscp listener thread is also 
stopped correctly during binding shutdown.

Original comment by pauli.an...@gmail.com on 20 Jun 2013 at 2:14

Attachments:

GoogleCodeExporter commented 8 years ago
This may be the source of the problem: I turn off power to the AVR when absent. 
Tested your attachment but got error:
Situation: AVR turned on, OH freshly started:
20:35:53.128 ERROR o.o.b.o.internal.eiscp.Eiscp[:595] - Error occured during 
message waiting
java.io.IOException: Illegal start char N
        at org.openhab.binding.onkyo.internal.eiscp.Eiscp.waitStateMessages(Eiscp.java:498)

also sending command does not work in this state. Restarting the onkyo-binding 
fixed it.

Original comment by honkton...@gmail.com on 20 Jun 2013 at 6:51

GoogleCodeExporter commented 8 years ago
Please run OH with debug level enabled, reproduce the problem and send log file 
to me.

Original comment by pauli.an...@gmail.com on 20 Jun 2013 at 7:12

GoogleCodeExporter commented 8 years ago
I could reproduce the (appearently same) error by fast power on and off.
Please see the attached logfile. AVR had power when OH was started.

Original comment by honkton...@gmail.com on 20 Jun 2013 at 8:07

Attachments:

GoogleCodeExporter commented 8 years ago
It seems that binding is receiving junk from the receiver. Binding tries to 
reopen connection, but still some junk is received. After a while, receiver 
rejects the connection (Verbindungsaufbau abgelehnt). I improved tracing of the 
binding, so could you rerun ones again?

You need to change onkyo binding log level to trace.

Add line 

<logger name="org.openhab.binding.onkyo" level="TRACE" /> 

to openhab-folder/Configuration/logback_debug.xml

Original comment by pauli.an...@gmail.com on 21 Jun 2013 at 10:34

Attachments:

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Here's the right trace. Got mixed up but now its correct. Thanks for pointin 
out, Pauli  :)

Original comment by honkton...@gmail.com on 21 Jun 2013 at 6:49

Attachments:

GoogleCodeExporter commented 8 years ago
Hopefully the problem is now fixed. Your receiver didn't send junk, but album 
cover picture.

Original comment by pauli.an...@gmail.com on 23 Jun 2013 at 9:58

Attachments:

GoogleCodeExporter commented 8 years ago
So far I only got this error:
19:32:55.214 ERROR o.o.b.o.internal.eiscp.Eiscp[:487] - Error occured during 
message waiting
java.io.IOException: Unexpedted data size
        at org.openhab.binding.onkyo.internal.eiscp.Eiscp.waitStateMessages(Eiscp.java:372)

I tried to reconstruct when the error occured, but I was unable to do so.

But it seems to recover fine when power is restored and overall very stable :) 

Original comment by honkton...@gmail.com on 23 Jun 2013 at 5:36

GoogleCodeExporter commented 8 years ago
Well, too soon to say it's all good.
If the AVR is disconnected for too long (>5Minutes), the bundle doesn't recover 
even when new commands (power on) are sent to the items.

Maybe a reconnect on error may solve this.
I also tried to send command on reconnect with networkhealth binding to recover 
but it won't :(

So current workaround is to restart when avr is back on.

Original comment by honkton...@gmail.com on 29 Jun 2013 at 12:01

GoogleCodeExporter commented 8 years ago
It's pretty difficult to fix/change anything without reproducing the problem. 
You should send debug logs to give more information about the problem.

Have you enabled avr network standby mode? Your problem seems to be related to 
unreliable connection between openhab and avr (broken TCP connection) rather 
than binding itself.

Anyhow...I added command resend functionality which close and reopen the 
connection when problem occurs during command send and also added connection 
supervisor, which query arv power state ones per 5 minutes to detect broken tcp 
connection.

Original comment by pauli.an...@gmail.com on 30 Jun 2013 at 7:39

Attachments:

GoogleCodeExporter commented 8 years ago
Thanks for your patience, Pauli.
Your version from #42 works just right *THUMBS UP*

Original comment by honkton...@gmail.com on 2 Jul 2013 at 3:41

GoogleCodeExporter commented 8 years ago
Hi Pauli,

I tried today your attached version from #42. Before I used the official 
version from the 1.3 snapshot build.
Now I see the following error in my logfile. Any idea what this could be?

19:25:22.675 DEBUG o.o.b.o.internal.eiscp.Eiscp[:145]- Connected to 192.168.0.7 
on port 60128
19:25:22.684 DEBUG o.o.b.o.internal.eiscp.Eiscp[:557]- Start connection tester, 
interval 300 seconds
19:25:22.685 DEBUG o.o.b.o.internal.eiscp.Eiscp[:493]- Data listener started
19:25:22.717 TRACE o.o.b.o.internal.eiscp.Eiscp[:347]- Waiting status messages

19:30:22.715 DEBUG o.o.b.o.internal.eiscp.Eiscp[:570]- Test connection to 
192.168.0.7:60128
19:30:22.716 DEBUG o.o.b.o.internal.eiscp.Eiscp[:281]- Send command: PWRQSTN
19:30:22.735 TRACE o.o.b.o.internal.eiscp.Eiscp[:310]- Sending 26 bytes: 
49534350000000100000001A0100000021315057525153544E0D
19:30:22.781 TRACE o.o.b.o.internal.eiscp.Eiscp[:367]- Received 25 bytes: 
49534350000000100000000901000000213150575230301A0D
19:30:22.782 TRACE o.o.b.o.internal.eiscp.Eiscp[:378]-  Packet [0]:
19:30:22.783 TRACE o.o.b.o.internal.eiscp.Eiscp[:396]-   Header size: 16
19:30:22.785 TRACE o.o.b.o.internal.eiscp.Eiscp[:409]-   Data size: 9
19:30:22.837 ERROR o.o.b.o.internal.eiscp.Eiscp[:527]- Error occured during 
message waiting
java.io.IOException: Illegal end of message
    at org.openhab.binding.onkyo.internal.eiscp.Eiscp.waitStateMessages(Eiscp.java:452)
    at org.openhab.binding.onkyo.internal.eiscp.Eiscp.access$1(Eiscp.java:340)
    at org.openhab.binding.onkyo.internal.eiscp.Eiscp$DataListener.run(Eiscp.java:498)
19:30:22.839 DEBUG o.o.b.o.internal.eiscp.Eiscp[:530]- Reconnecting...
19:30:22.843 DEBUG o.o.b.o.internal.eiscp.Eiscp[:145]- Connected to 192.168.0.7 
on port 60128
19:30:23.845 TRACE o.o.b.o.internal.eiscp.Eiscp[:347]- Waiting status messages

And this Is how my Items file looks like:

Switch onkyoPower "Zone 1 Power" 
<'grey/control_on_off'>{onkyo="ON:hometheater:POWER_ON, 
OFF:hometheater:POWER_OFF"}
Dimmer onkyoVolume2 "Vol 1 [%.1f]" <'grey/audio_volume_high'> { 
onkyo="INIT:hometheater:VOLUME_QUERY, INCREASE:hometheater:VOLUME_UP, 
DECREASE:hometheater:VOLUME_DOWN, *:hometheater:SET_VOLUME" }
Dimmer onkyoVolume "Vol 2 [%.1f]" <'grey/audio_volume_high'>  
{onkyo="INIT:hometheater:#MVLQSTN, INCREASE:hometheater:VOLUME_UP, 
DECREASE:hometheater:VOLUME_DOWN"}

Original comment by dongy...@gmail.com on 5 Jul 2013 at 6:39

GoogleCodeExporter commented 8 years ago
eISCP spec specify that every data should be end to "[EOF]" or "[EOF][CR]" or 
"[EOF][CR][LF]" characters depend on model. I have tried to implemented binding 
so that all 3 different variations should be supported, but it seems that I 
have not succeeded :(

Which AVR model are you using? My model always response data which end with 
"[EOF][CR][LF]"

21:46:42.755 TRACE o.o.b.o.internal.eiscp.Eiscp[:367] - Received 26 bytes: 
49534350000000100000000A01000000213150575230301A0D0A

I try to fixit it near future, but feel free to provide a batch :) Bug is 
probably between lines 437 - 462 on the file 
http://code.google.com/r/paulianttila-ihc-binding/source/browse/bundles/binding/
org.openhab.binding.onkyo/src/main/java/org/openhab/binding/onkyo/internal/eiscp
/Eiscp.java

Original comment by pauli.an...@gmail.com on 5 Jul 2013 at 7:18

GoogleCodeExporter commented 8 years ago
I'm using the Onkyo TX-NR 905 (as you see this is not one of the latest models 
:-)).
Will check the class and see if I can fix it.

Original comment by dongy...@gmail.com on 5 Jul 2013 at 7:32

GoogleCodeExporter commented 8 years ago
New binding for testing purposes.

Changes:
- Fixed "[EOF]" or "[EOF][CR]" or "[EOF][CR][LF]" end characters support.
- Update special command template value only when template contains % character.

End character fix was bigger than I expected, so I kindly ask all of you to 
test the latest version and report any problems.

Original comment by pauli.an...@gmail.com on 6 Jul 2013 at 8:25

Attachments:

GoogleCodeExporter commented 8 years ago
I got an error while playing with the binding.
My MasterZone was turned of for about 1-2h.
Zone2 played webradio during that time.
I turned on the MasterZone and received many information via eiscp:

[..]
18:32:32.144 DEBUG o.o.b.o.internal.eiscp.Eiscp[:521] - Received 1 messages
18:32:32.144 DEBUG o.o.b.o.internal.eiscp.Eiscp[:525] - Received status 
message: NLSU1-Last.fm Internet Radio
18:32:32.145 DEBUG o.o.b.o.internal.OnkyoBinding[:349] - Received status update 
'NLSU1-Last.fm Internet Radio' from device 192.168.1.18
[..]
18:32:34.655 DEBUG o.o.b.o.internal.eiscp.Eiscp[:525] - Received status 
message: NJA01F5F5F5F5F5F5F5F5F5F5F5F5F5F5[ --snip --] F5F5F5F5F5F5F5F5AFF5
18:32:34.655 DEBUG o.o.b.o.internal.OnkyoBinding[:349] - Received status update 
'NJA01F5F5F5F5F5F5F5F5F5F5F5F5F5F5[ --snip --] F5F5F5F5F5F5F5F5AFF5' from 
device 192.168.1.18
[many more of this long kind of messages]

Error occures:
18:32:34.710 ERROR o.o.b.o.internal.eiscp.Eiscp[:548] - Error occured during 
message waiting
java.lang.ArrayIndexOutOfBoundsException: 812
        at org.openhab.binding.onkyo.internal.eiscp.Eiscp.waitStateMessages(Eiscp.java:461)
        at org.openhab.binding.onkyo.internal.eiscp.Eiscp.access$1(Eiscp.java:340)
        at org.openhab.binding.onkyo.internal.eiscp.Eiscp$DataListener.run(Eiscp.java:519)
18:32:34.711 DEBUG o.o.b.o.internal.eiscp.Eiscp[:551] - Reconnecting...
18:32:34.714 DEBUG o.o.b.o.internal.eiscp.Eiscp[:145] - Connected to 
192.168.1.18 on port 60128

I tried some commands:
18:32:38.917 INFO  runtime.busevents[:42] - onkyoMute received command ON
18:32:38.917 DEBUG o.o.b.o.internal.OnkyoBinding[:129] - Received command 
(item='onkyoMute', state='ON', class='class 
org.openhab.core.library.types.OnOffType')
18:32:38.918 DEBUG o.o.b.o.internal.eiscp.Eiscp[:281] - Send command: AMT01
18:32:52.341 INFO  runtime.busevents[:42] - onkyoMute received command OFF
18:32:52.341 DEBUG o.o.b.o.internal.OnkyoBinding[:129] - Received command 
(item='onkyoMute', state='OFF', class='class 
org.openhab.core.library.types.OnOffType')
but nothing happens.

I don't get any updates from the avr anymore.

After restarting openhab, everything works again.

Original comment by christop...@gmail.com on 6 Jul 2013 at 4:45

GoogleCodeExporter commented 8 years ago
Thanks for the fast update Pauli.
I already merged yesterday the version from your clone with my workspace 
version in order to try to fix the end character problem. Good that I checked 
my mails to see that you already provided the bug fix :-)
First tests looks promising. Will do some more detailed test and report back to 
you.

Original comment by dongy...@gmail.com on 6 Jul 2013 at 7:25

GoogleCodeExporter commented 8 years ago
Updated binding for nightly builds after Jul 8 (fixed issue 141).

 Christoph: Enable trace logs to Onkyo binding and try to reproduce the problem and send full log to me.

Original comment by pauli.an...@gmail.com on 11 Jul 2013 at 7:09

Attachments: