How to receive data with TcpBinding

Hi all, I would need some support to understand how TCP binding works in OpenHab 2.x.
Up to know, I was using OpenHab 1.x with serial binding, so I have some experience on that.

My goal is making OpenHab (OH in the later) communicating with an application (APP in the later) of mine, running on the same Linux PC. I’d like to use this “external” APP to achieve proper level of flexibility within the logics I need to implement. So I am intended to use TcpBinding, with APP acting as a TCP server and OH as TCP client, over (localhost on same PC).

Of course let me know if I have some alternatives to make OH and APP communicating each other,.

Currently I succeeded to TRANSFER data from OH to APP by adding .items file:

Switch AppliqueSwitch "Applique" <none> (GrFloor, gAppl) {tcp="[ON:'myCustomOnString'], >[OFF:'myCustomOffString']"}

I can see 2x connections in my APP where I can receive myCustomOnString and myCustomOffString over TCP when sliding the AppliqueSwitch by the GUI; so far so good.

What I am struggling is how to RECEIVE from APP to OH. I browsed a lot but, sadly, I must say there is too poor documentation which do not clarify what-to-do, what is possible to do or not to do.

Anyway, I did some trials:

  1. I added to .items file:
String TcpRx "TcpRx"    {tcp="<[]"}
  1. I sent from APP the string MYSAMPLESTRING to estabilised OH connection
  2. I can see in OH logs in /var/log/openhab2/
[WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input MYSAMPLESTRING to match command OFF on item AppliqueSwitch 
[WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input MYSAMPLESTRING to match command ON on item AppliqueSwitch 

respectively when I send data from TCP server to first or second connection from OH.

This happens even without configuring the tcp.cfg file in the field descirbed in

So it sounds that my custom MYSAMPLESTRING is being received in OH, but I don’t know how to use it. I think I need to create somehow a rule in .rules file to parse it and perform some logic, but I am getting confused at this point, since it is not clear what should be configured and where, what syntax should be used, which files should be affected.

It would be enough just receiving some string/data from TCP server and move the relevant switch accordingly.

Can you please give me some hints? How can I receive my own data from APP to OH?


Why don’t you use MQTT instead of TCP ?

You have lots of higher level choices. MQTT would be most flexible the HTTP REST API is another good option.

The tcp binding is designed mostly for oh to control devices that don’t support any higher layer protocol. It’s not designed as a way to control oh from some other application. That’s what the rest API is for.

Thanks everybody for the helping answers.
I was digging in and I finally found a working solution:

I keep using TcpBinding, but in a slight different way then written before:

  1. in .items file:
Switch ExternalLamp                  "Lamp"                  <none>               (OU_Outside, gFaroTavolo)
String txCmdString "txCmdString" (All) {tcp=">[]"}
  1. in .rules file:
var Integer EXTERNAL_LAMP = 17
rule "ExternalLamp"
		Item ExternalLamp received command
		strVal = "none"
            case ON: strVal = "1"
            case OFF:strVal = "0"
			default: logError("ExternalLamp","*** INVALID CMD")               
	    if(strVal != "none")
			ohCmd = "$" +  EXTERNAL_LAMP.toString.leftPad(2,"0") + "_" + strVal + "#"
			sendCommand(txCmdString, ohCmd)

That is, I use txCmdString item in each rule for each “switch” item formatting a custom string that I parse in APP.
In this example, I send over TCP:

  • $17_0# to notify to APP lamp switch has been turned OFF by OH
  • $17_1# to notify to APP lamp switch has been turned ON by OH

APP implements a simple TCP server listening on port 1234.

I use rest API to “directly” change from APP the value of the switch item (, for example:

curl -X POST --header "Content-Type: text/plain" --header "Accept: application/json" -d "ON" ""
results in my OH switch to be tuned ON.

That’s properly working, thanks a lot!