TCP Binding "there is no active channel"

[openhab-bot]

From quellt...@gmail.com on November 15, 2012 14:18:10

I have a Java TCP Socket server running on my local pc.

I've added the example code from the OpenHAB wiki Switch Light_OnOff "Alarmbeleuchtung" (Garden) { tcp=">[ON:127.0.0.1:3000:cmd_on], >[OFF:127.0.0.1:3000:cmd_off]" }

I get the error message 14:08:18.679 ERROR o.o.b.t.AbstractChannelEventSubscriberBinding[:1047] - there is no active channel for [itemName=Light_OnOff, command=ON] When the switch is enabled/disabled

Socketserver recognizes the client connection but doesn't get a message

I've tried it with: OpenHab runtime 1.0.0 TCP Binding 1.1.0 and also with OpenHab runtime 1.1.0 TCP Binding 1.1.0

(There's no tcp binding in my addon-1.0.0 download file)

@WinXP 32Bit

Original issue: http://code.google.com/p/openhab/issues/detail?id=146

[openhab-bot]

From kai.openhab on November 15, 2012 05:20:37

Owner: karel.go...@gmail.com

[openhab-bot]

From karel.go...@pharco.be on December 04, 2012 16:00:32

Sorry for the late answer - I do not actively read the mailbox karel.goderis@gmail.com

I have tried to replicate the problem. I have the following configuration set-up ( based on latest repo):

demo.items: Switch Light_OnOff "Alarmbeleuchtung" (Garden) { tcp=">[ON:127.0.0.1:3000:cmd_on], >[OFF:127.0.0.1:3000:cmd_off]" }

demo.rules: rule "Crontest" when Time cron "0/5 * * * * ?" then sendCommand(Light_OnOff, OFF) end

In a terminal window I execute the following command, to listen to TCP port 3000: nc -l 3000

Then I do a debug run and this is what I get in the OH logs: (I removed the non-relevant lines) osgi> 00:20:23.552 DEBUG o.o.b.t.internal.TCPActivator[:51] - TCP/UDP binding has been started. 00:20:24.649 DEBUG o.o.b.t.AbstractChannelEventSubscriberBinding[:509] - TCPBinding Selector Thread has been started 00:20:24.651 DEBUG o.o.b.t.AbstractChannelEventSubscriberBinding[:265] - TCPBinding Parser Thread has been started 00:20:24.654 DEBUG o.o.b.t.AbstractChannelEventSubscriberBinding[:190] - TCPBinding Reconnect Thread has been started 00:20:24.662 DEBUG o.o.b.t.AbstractChannelEventSubscriberBinding[:265] - UDPBinding Parser Thread has been started 00:20:24.663 DEBUG o.o.b.t.AbstractChannelEventSubscriberBinding[:509] - UDPBinding Selector Thread has been started 00:20:40.004 DEBUG o.o.m.r.i.e.ExecuteRuleJob[:73] - Executing scheduled rule 'Crontest' 00:20:40.011 INFO runtime.busevents[:42] - Light_OnOff received command OFF 00:20:40.013 INFO runtime.busevents[:46] - Light_OnOff state updated to OFF 00:20:45.004 DEBUG o.o.m.r.i.e.ExecuteRuleJob[:73] - Executing scheduled rule 'Crontest' 00:20:45.010 INFO runtime.busevents[:42] - Light_OnOff received command OFF 00:20:45.011 INFO runtime.busevents[:46] - Light_OnOff state updated to OFF

In the terminal window, where I have the "server" running, I have the following output: Karel-Goderis-MacBook-Air:~ kgoderis$ nc -l 3000 cmd_off cmd_off

At first sight I can not replicate your problem. Can you try the same as me and tell if you have a different output?

Karel

[openhab-bot]

From kai.openhab on January 05, 2013 14:13:03

Please reopen the issue in case the problem still exists.

Status: Rejected

[openhab-bot]

From ianlinda...@gmail.com on February 13, 2013 01:15:24

I have managed to reproduce this on Win 8 x64. It's a string parsing issue, in the binding if you have "ON:" you get the error with "on:" it works. I haven't fully tested yet but the error does not appear in the log.

Ian

[openhab-bot]

From karel.go...@pharco.be on February 13, 2013 01:43:47

Hi Ian

I need to verify this, and also, verify if this problem exists with other bindings. From my distant recollection, I think I have never implemented code to format the incoming strings and so on to UPPER or lower case. Keep me posted with diagnosis...

[openhab-bot]

From ianlinda...@gmail.com on February 13, 2013 12:54:40

I'm having problems with the error as I can get it to mostly not work in either case. It seems to be related specifically to the TCP binding... However, the good news I build a snapshot from a couple of weeks ago and it seems to work there... so whatever has changed seems to have fixed the bug.

I was wondering if it was something to do with the order in which bindings are initialized? As very rarely the Plugwise binding seems to die at startup because some other components aren't running. If I still have the logs I'll post them as a separate issue.

[openhab-bot]

From karel.go...@pharco.be on February 13, 2013 23:10:21

Hi

A month or two ago I refactored the whole tcp binding to use Quartz threads amongst other things.

You could try in increase the logging level a bit (debug mode) so that we can investigate ?

The TCP device you are connecting to is behaving "correctly"? Is not dropping connections rapidly, or it responds fast to connection attempts.

"No active channel" is most likely due to openhab sending a value to the remote end (you switch ON), but the underlying TCP connection is not connected (yet)/(anymore)

K