# TCP Binding CPU spam, failst o reconnect, old bugs, just seriously broken but undocumentedly so **URL:** \ **Category:** Bindings\ **Tags:** tcpbinding\ **Created:** [November 17, 2018, 10:14am UTC](https://community.openhab.org/t/tcp-binding-cpu-spam-failst-o-reconnect-old-bugs-just-seriously-broken-but-undocumentedly-so/56962 "2018-11-17T10:14:29Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Alex\_Berg](https://community.openhab.org/user_avatar/community.openhab.org/alex_berg/32/42179_2.png) [@Alex\_Berg](https://community.openhab.org/u/Alex_Berg)\ **Post date:** [November 17, 2018, 10:14am UTC](https://community.openhab.org/t/tcp-binding-cpu-spam-failst-o-reconnect-old-bugs-just-seriously-broken-but-undocumentedly-so/56962/1 "2018-11-17T10:14:29Z")
TCP (UDB) Binding spams logs even though tcp-connection is active and working. It spams with the frequency set in reconnectcron once the tcp connection is active the first time since openhab restart `[WARN] [ding.tcp.AbstractSocketChannelBinding] - Channel for /10.0.0.4:7000 is not reconnecting.` When the remote tcp-server is shutdown it immediately starts increasing its spam very quickly towards max cpu, which is for me is 10.000 reconnect attempts / sec `[INFO] [ding.tcp.AbstractSocketChannelBinding] - The channel for /10.0.0.4:7000 is now connected` `[WARN] [ding.tcp.AbstractSocketChannelBinding] - Channel for /10.0.0.4:7000 is not reconnecting.` I suspect it tries to reconnect every 250 ms, and thinks it succeeds, yet fails, and then schedules yet another cron job, and so goes bananas. I’m writing this because I have spent a fair amount of time trying to get TCP binding to work, and now I discover this is well documented in the issue list, yet not in the TCP binding wiki. I’ll post update there afterwards. I found many others having issues with tcp-binding here, but it looked like most got it to work. As a side-note here’s a solution by JGluch that I suspect works to replace tcp with mtqq+python server: [[SOLVED] Optoma beamer via RS232 over TCP/IP connector - #10 by JGluch](https://community.openhab.org/t/solved-optoma-beamer-via-rs232-over-tcp-ip-connector/38719/10) During all my messing about, I misunderstood the direction, and forgot that “\<” means openhab listens on port, and “\>]” means openhab connects to remote server. So it makes no sence trying to receive on one, and send on the other. So ignore comments in code about that and just go with what worked for me, namely just one item binding with {tcp=“\>[10.0.0.4:7000:]”} This is the GitHub issue I found: > > > Hey there. I have the classy problem of openhab dying after some hours and could… break it down to one addon: > > Here, have a look at my config: > > \`\`\` ini > \# openhab.cfg > \################################# TCP - UDP Binding ################################### > tcp:retryinterval=60 > tcp:queue=false > tcp:refreshinterval=2000 > \`\`\` > > \`\`\` java > // items > String AACC "LEDs" \ (Lichter) { tcp="\>\[192.168.1.100:2323:'REGEX((.\*))'\]" } > String Leroy\_X10receiver "X10Receiver.net \[%s\]" /\*\*/ /\*\*/ { tcp="\>\[192.168.1.100:9000:'REGEX((.\*))'\]" } > \`\`\` > \## Reproduction > \- Listen to TCP 9000 and 2323 on 192.168.1.100 > \- Openhab ESTABLISHES TCP connection > > \_(Everything works fine and WILL stay fine here)\_ > \- Break connection by putting 192.168.1.100 to STANDBY (Is Windows) > \- Connections time out with CLOSE\_WAIT > \- 192.168.1.100 will never answer with a CLOSING or CLOSED > \- TCP Binding stays stuck in a loop and is spamming: > > \`\`\` > \[...\] > The channel for /192.168.1.100:2323 is now connected > The channel for /192.168.1.100:9000 is now connected > The channel for /192.168.1.100:2323 is now connected > The channel for /192.168.1.100:9000 is now connected > The channel for /192.168.1.100:2323 is now connected > The channel for /192.168.1.100:9000 is now connected > \[...\] > \`\`\` > > \_(repeats with every worker (refresh) cycle)\_ > > Open file descriptors rise to a non-critical value. Memory rises to the limits of Xmx Java Heap Space (but not to the system's limits) until it finally breaks: > > \`\`\` > 2015-06-06 05:19:36.108 \[INFO \] \[t.AbstractSocketChannelBinding\] - The channel for /192.168.1.100:2323 is now connected > 2015-06-06 05:19:36.556 \[INFO \] \[t.AbstractSocketChannelBinding\] - The channel for /192.168.1.100:2323 is now connected > 2015-06-06 05:19:37.010 \[INFO \] \[t.AbstractSocketChannelBinding\] - The channel for /192.168.1.100:2323 is now connected > Exception in thread "fileinstall-addons" Exception in thread "qtp14920870-44" java.lang.OutOfMemoryError: Java heap space > at org.eclipse.jetty.util.thread.QueuedThreadPool.newThread(QueuedThreadPool.java:450) > at org.eclipse.jetty.util.thread.QueuedThreadPool.startThread(QueuedThreadPool.java:430) > at org.eclipse.jetty.util.thread.QueuedThreadPool.dispatch(QueuedThreadPool.java:361) > at org.eclipse.jetty.server.nio.SelectChannelConnector$ConnectorSelectorManager.dispatch(SelectChannelConnector.java:295) > at org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:703) > > \`\`\` > > By the way - the binding won't re-connect the tcp socket, even if I start 192.168.100 again. It just keeps spamming. > Without the TCP Binding the system ran fine multiple days - although being some kind of useless, of course ;) > > If I can provide you anything more, please tell me! Here are some graphs. From the logs you can see it broke at about 05:19 AM. > > (timestamps from log and graphs may differ in timezone (was UTC instead of CEST) > > !\[cpul\](https://cloud.githubusercontent.com/assets/2018039/8041451/8e70da14-0e18-11e5-85e5-5c6c8351e34f.png) > !\[cpuu\](https://cloud.githubusercontent.com/assets/2018039/8041452/8e756cbe-0e18-11e5-8303-8a2e3ccc1e2f.png) > !\[mem\](https://cloud.githubusercontent.com/assets/2018039/8041453/8e75f9b8-0e18-11e5-93a9-f8a7cc3ddfdc.png) > !\[openfd\](https://cloud.githubusercontent.com/assets/2018039/8041454/8e770cf4-0e18-11e5-8ddf-0663b1b1b697.png) > !\[tcp\](https://cloud.githubusercontent.com/assets/2018039/8041455/8e811eec-0e18-11e5-88c5-08f095a651b8.png) > \## I’m on OpenHAB 2.4 M5, TCP Binding 1.13.0-M5. I’ve tried many different settings, I’ll post some of what I’ve done below, but I suspect the setup matters little, because its just a bug, but perhaps there’s a way around the bug. I’ve tried defaults with tcp.cfg params _shared_, and tried with all true, and all false. Items file ```auto // When tested below options, I had no receiving binding like tcp="<[]" // Worked: // String TCP_Lyngdorf "Lyngdorf TCP" (gHifi) ["Hifi"] { tcp=">[10.0.0.4:7000:'REGEX((.*))']" } // Input received from lyngdorf, eg 'TCP_Lyngdorf changed from !VOLDN to !VOL(-280)!' // String TCP_Lyngdorf "Lyngdorf TCP" (gHifi) ["Hifi"] { tcp=">[10.0.0.4:7000:REGEX((.*))]" } // Input received from lyngdorf, eg 'TCP_Lyngdorf changed from !VOLDN to !VOL(-280)!' // String TCP_Lyngdorf "Lyngdorf TCP" (gHifi) ["Hifi"] { tcp=">[10.0.0.4:7000:default]" } // Input received from lyngdorf // String TCP_Lyngdorf "Lyngdorf TCP" (gHifi) ["Hifi"] { tcp=">[10.0.0.4:7000:]" } // Input received from lyngdorf // String TCP_Lyngdorf "Lyngdorf TCP" (gHifi) ["Hifi"] { tcp=">[*:10.0.0.4:7000:]" } // Data sent to and input received from lyngdorf // Didn't work: // String TCP_Lyngdorf "Lyngdorf TCP" (gHifi) ["Hifi"] { tcp=">[10.0.0.4:7000:*]" } // input not received // String TCP_Lyngdorf "Lyngdorf TCP" (gHifi) ["Hifi"] { tcp=">[:10.0.0.4:7000:]" } // data not sent ////////// > listed first // String TCP_Lyngdorf "Lyngdorf TCP Send [%s]" (gHifi) ["Hifi"] { tcp=">[*:10.0.0.4:7000:],<[*:10.0.0.4:7000:]" } // => There is no channel that services [itemName=TCP_Lyngdorf, command=!VOLDN] // with directionssharedconnections=true // I don't think it connected, nothing was sent ////////// < listed first // String TCP_Lyngdorf "Lyngdorf TCP Send [%s]" (gHifi) ["Hifi"] { tcp="<[*:10.0.0.4:7000:],>[*:10.0.0.4:7000:]" } // => Channel for /10.0.0.4:7000 is not reconnecting. // with directionssharedconnections=true // connects and sends data // Lyngdorf wasn't sending data when this happened, I think. something weird. I dont Think it got data when I got it to work, not sure ///// // String TCP_Lyngdorf_Receive "Lyngdorf TCP Rec [%s]" (gHifi) ["Hifi"] { tcp="<[*:10.0.0.4:7000:]" } // String TCP_Lyngdorf "Lyngdorf TCP Send [%s]" (gHifi) ["Hifi"] { tcp=">[*:10.0.0.4:7000:]" } // => Channel for /10.0.0.4:7000 is not reconnecting. // with directionssharedconnections=true // connects and sends data ////////// all sharing disables // String TCP_Lyngdorf_Receive "Lyngdorf TCP Rec [%s]" (gHifi) ["Hifi"] { tcp="<[*:10.0.0.4:7000:]" } // String TCP_Lyngdorf "Lyngdorf TCP [%s]" (gHifi) ["Hifi"] { tcp=">[*:10.0.0.4:7000:]" } // with *share*=false // port=0 // => The channel java.nio.channels.SocketChannel[closed] has encountered an unknown IO Exception: No route to host // Strangely enough TCP_Lyngdorf_Receive gets no events, and TCP_Lyngdorf still receives data returned from tcp as seen // in ItemStateChangedEvent but no update 'received update' is returned // WHEN server tcp down, we get logs ' The channel for /10.0.0.4:7000 is now connected' and // rapidly increasing spam in logs towards 7 pr ms starding tith 1/2 pr sec ///////// String TCP_Lyngdorf_Receive "Lyngdorf TCP Rec [%s]" (gHifi) ["Hifi"] { tcp="<[*:10.0.0.4:7000:]" } String TCP_Lyngdorf "Lyngdorf TCP [%s]" (gHifi) ["Hifi"] { tcp=">[*:10.0.0.4:7000:]" } Switch Lyngdorf "Lyngdorf TDAI-2170" (gHifi) ["Hifi"] Rollershutter LyngdorfVolumeSteps "Lyngdorf Volume [%d]" (gHifi) ["Hifi"] Number LyngdorfVolumeNum "Lyngdorf Volume [%d]" (gHifi) ["Hifi"] Switch LyngdorfSubscription "Lyngdorf TDAI-2170 Subscription" (gHifi) ["Hifi"] Number LyngdorfInput "Lyngdorf Input [%d]" (gHifi) String LyngdorfInputName "Lyngdorf Input [%s]" (gHifi) ``` Some of my rules ```auto rule "Lyngdorf" when Item Lyngdorf received command or Item LyngdorfVolumeSteps received command or Item LyngdorfInput received command or Item LyngdorfInputName received command then var c=transform("MAP", "lyngdorf_TDAI2170.map", receivedCommand.toString) // logWarn("hifi.rules", "LyngdorfVolumeSteps send: "+receivedCommand+" => '"+ c+"'") TCP_Lyngdorf.sendCommand(c) end ////////// Receive item /////////////////// rule "Lyngdorf TCP Received - Command" when Item TCP_Lyngdorf_Receive received command then logWarn("hifi.rules", "New received command: "+TCP_Lyngdorf_Receive.state) end rule "Lyngdorf TCP Received - Update" when Item TCP_Lyngdorf_Receive received update then logWarn("hifi.rules", "New received update: "+TCP_Lyngdorf_Receive.state) end rule "Lyngdorf TCP Received - changed" when Item TCP_Lyngdorf_Receive changed then logWarn("hifi.rules", "New changed update: "+TCP_Lyngdorf_Receive.state) end ////////// ORG Send item /////////////////// rule "Lyngdorf TCP - changed" when Item TCP_Lyngdorf changed then logWarn("hifi.rules", "Changed: "+TCP_Lyngdorf.state) end rule "Lyngdorf TCP - Command" when Item TCP_Lyngdorf received command then // TCP_Lyngdorf.sendCommand("!SUBSCRIBEVOL") logWarn("hifi.rules", "Command: "+TCP_Lyngdorf.state) end // Below receives both commands and updates, but fortunately commands and status differ in values from Lyngdorf rule "Lyngdorf TCP - Update" when Item TCP_Lyngdorf received update then if (TCP_Lyngdorf.state !== null) { var fullState = TCP_Lyngdorf.state.toString() var splitArray = fullState.split("\r\n") for (String stateLine : splitArray) { // logError("hifi.rules", "Update TCP_Lyngdorf line: '"+stateLine+"'") if (stateLine.matches("!.*!")) { // logInfo("hifi.rules", "Update - Matches !.*!: '"+stateLine+"'") var value = transform("REGEX", ".*!VOL\\((-?\\d+)\\)!.*", stateLine) if (value !== null) { var valueInt = Integer.parseInt(value) logInfo("hifi.rules", "Update Volume: "+stateLine+" => "+value+", int="+valueInt) // LyngdorfVolumeSteps.postUpdate(new Percent(1-(-15-valueInt)/(15-70))) LyngdorfVolumeNum.postUpdate(valueInt/10.0) } else if ((value = transform("REGEX", "!SRC\\((\\d+)\\)!", stateLine)) !== null) { // !SRC(9) is data we send to Lyngdorf, !SRC(9)! is response state data var valueInt=Integer.parseInt(value) LyngdorfInput.postUpdate(valueInt) LyngdorfInputName.postUpdate(transform("MAP", "lyngdorf_TDAI2170_status.map", value)) logInfo("hifi.rules", "Update Source: "+stateLine+" => "+valueInt) } else if ((value = transform("REGEX", "!PWR\\((ON|OFF)\\)!", stateLine)) !== null) { // !SRC(9) is data we send to Lyngdorf, !SRC(9)! is response state data if (value == "ON") { Lyngdorf.postUpdate(ON) } else { Lyngdorf.postUpdate(OFF) } logInfo("hifi.rules", "Update PWR: "+stateLine+" => "+value) } else { logInfo("hifi.rules", "Update - No matching transform found: "+stateLine) } } else { // all commands sent to Lyngdorf end up here // logInfo("hifi.rules", "Update - Not a status string from lyngdorf, no matching !.*!: '"+stateLine+"'") } } } end ``` my map (the out-going map) which works ```auto ON=!ON OFF=!OFF UP=!VOLUP DOWN=!VOLDN SUBSCRIBE=!SUBSCRIBE UNSUBSCRIBE=!UNSUBSCRIBE SUBSCRIBEVOL=!SUBSCRIBEVOL UNSUBSCRIBEVOL=!UNSUBSCRIBEVOL Squeezebox=!SRC(2) Tv=!SRC(3) ChromecastAudio=!SRC(4) Pc=!SRC(7) UsbPc=!SRC(6) ChromecastTv=!SRC(9) 1=!SRC(1) 2=!SRC(2) 3=!SRC(3) 4=!SRC(4) 5=!SRC(5) 6=!SRC(6) 7=!SRC(7) 8=!SRC(8) 9=!SRC(9) 10=!SRC(10) ``` ---
**Author:** ![scratch009](https://community.openhab.org/user_avatar/community.openhab.org/scratch009/32/13597_2.png) [@scratch009](https://community.openhab.org/u/scratch009)\ **Post date:** [April 15, 2023, 11:11am UTC](https://community.openhab.org/t/tcp-binding-cpu-spam-failst-o-reconnect-old-bugs-just-seriously-broken-but-undocumentedly-so/56962/2 "2023-04-15T11:11:49Z")
Are you still using this method to control your Lyngdorf amp? I have a TDAI3400, up until now I’ve been using a harmony IR hub, but would be nice to send and read volume levels so I wanted to see if I can use RS232 or TCP connection. I need to dive into this but wonder if you still use this way in openHAB? thanks, philippe ---
**Author:** ![Alex\_Berg](https://community.openhab.org/user_avatar/community.openhab.org/alex_berg/32/42179_2.png) [@Alex\_Berg](https://community.openhab.org/u/Alex_Berg)\ **Post date:** [April 15, 2023, 12:03pm UTC](https://community.openhab.org/t/tcp-binding-cpu-spam-failst-o-reconnect-old-bugs-just-seriously-broken-but-undocumentedly-so/56962/3 "2023-04-15T12:03:46Z")
Hi Philippe, No I no longer use my Lyngdorf amplifier. Best Alex