Example Configuration for TCP Binding Client Thing

[Digitalvitamin]

When migrating from OH2.5 to OH3.2 I noticed that the TCP/UDP Binding was not part of OH3. Glad to have found it here! I run into an issue with the configuration, though.

With OH2.5 I simply had to configure an item like this: String OWinput { tcp=">[192.168.5.55:5000:default]"} and the binding would update the item by opening a client TCP connection to the given IP and wait for a string (because '>' was used).

Following the documentation for the smarthomej TCP binding I tried a tcp.thing config like this:

Thing tcpudp:client:string "TCPUDP String" @ "Test" [ host="192.168.5.55", port="5000", protocol="TCP", refresh="5"  ]
{
    Channels:
        Type string : input "OneWire Input" [ stateContent="" ]  // also tried stateContent="read"
}

At first I was not sure if this is the correct channel type for a client string. But according to the documentation it should be. Also I was not sure what I should put in as stateContentso I used the empty string because the property is mandatory. In addition I added an item like this:

String OWinput  { channel="tcpudp:client:string:input" }

After that I can see a warning in the log:

[WARN ] [g.tcpudp.internal.ClientThingHandler] - Empty stateContent configured for channel 'tcpudp:client:string:input' with capability 'read'. State updates are disabled.

The item is not updated and the Thing stays in state "UNKNOWN".

Question is: What do I set the stateContent to in order to read a simple string via TCP?

Could the documentation be extended to cover the client case and perhaps the channel type string? Thanks!

[J-N-K]

I always struggle with the textual configuration and it's super easy to provide invalid configurations, that's why I never use it and why there is no example in the documentation. If you have one that is working, feel free to contribute it.

Regarding your issue: I believe you hit a corner case that is currently not covered by the binding. For my understanding: You want to open a TCP connection, send nothing and wait for a value, correct? Is that value send within a definite time after the connection was opened (i.e. 1s or so, a short time that can be used as timeout) or is it more like "long-polling" (keeping the connection open until at some time in the future an event occurs)?

[Digitalvitamin]

Thanks for quick reply Jan,

I repeated the whole exercise with the UI config. It looks like this:

UID: tcpudp:client:input
label: TCP/UDP Client
thingTypeUID: tcpudp:client
configuration:
  protocol: TCP
  delay: 0
  port: 5000
  host: 192.168.5.55
  refresh: 10
  timeout: 60000
  bufferSize: 2048
location: HWR
channels:
  - id: input
    channelTypeUID: tcpudp:string
    label: OW Input
    description: ""
    configuration:
      mode: READONLY
      stateContent: "0"

(I also tried \n as stateContent.)

Yes, I just want to listen on the client connection. The server sends a new string every 10-30 seconds or so (followed by a new line). When I connect to the server using telnet, the updates are just printed on the screen. With the old binding each line was handled as an update to the item. Is this possible with the new version, too?

When using 0 as stateContent the item gets updated - but receives only the first 1 or 2 characters:

2022-02-20 18:23:36.059 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tcpudp:client:input' changed from OFFLINE (COMMUNICATION_ERROR): Read timed out to ONLINE
2022-02-20 18:23:36.060 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TCPUDPClient_OWInput' changed from 1 to 1_
2022-02-20 18:26:50.541 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TCPUDPClient_OWInput' changed from 1_ to 1
2022-02-20 18:28:59.522 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TCPUDPClient_OWInput' changed from 1 to 1_

Normally the input is much longer and a bit more frequent but starts with 1_ in any case. I assume the log only shows changes to the item and omits "changed from 1 to 1" cases.

Any idea why the content is cut off like this? Has it to do with the stateContent?

[J-N-K]

Currently a new connection is opened for each refresh and disconnected afterwards. So I think there are two independent issues.

• the "truncated values" (bug)
• the "keep connection open and wait for input" (feature)

I'll first try to fix the bug. How did you install the binding?

[Digitalvitamin]

If you do some kind of "long-polling" this might be ok too, I think. E.g. closing the connection after reading a line and opening again directly afterwards. But to reproduce the behaviour of the old binding keeping the connection open would be the way to go.

I installed the binding using the "JSON 3rd Party Addon Service".

[Digitalvitamin]

@J-N-K: Thanks for the fix! It looks like I can continuously receive updates when setting the timeout higher than the update frequency of the data. I guess this way a new connection is opened every time? Do you think this will impact performance? (running on a NAS)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.