OpenHAB 3 TCP binding

Does anyone know if there is a plan to create an OH3 TCP binding? It is in table 1 of the list and shown as supported but there is no PR reference for it.

I have an OpenEVSE that connects using a wifi-serial TCP adaptor. My solar inverter also pushes out TCP status updates which I am hoping to capture and decode.

I was using the v1 binding in OH2 but the memory leak meant I had to reboot every couple of days so I had disabled it but I would like to integrate these two devices back into OpenHAB.

Supported has a different meaning which is explained in that issue too above the table.

Edit:

So it seems that no one has ported that yet.

1 Like

Thanks.

As it is a v1 binding, I am pretty sure it wouldn’t work if installed manually.

Yes.
This is more meant as a “could work in openHAB2” because there is the legacy/compatibility layer still implemented.

I had a look at the tcp binding.
It should not be that hard to add this at a later point. (The table states 25 lines of Java code needed in oh1)
There was simply no need so far as it seems.

Make that 3528. The 25 is the number of users in the poll that indicated they use this binding. So it’s relatively actively used.

Looking at the binding code, even with 3528 loc, it doesn’t look to complicated. However, some of the features look like they should not be implemented in the binding itself, but be used from what the framework already supplies. So the biggest challenge will be to figure out what functionality it actually should do.

1 Like

Ups sorry, i was in the wrong column indeed. :smiley:

IMO it should offer fairly simple functionality:
If a linked string item is updated, it should send the string to the TCP connection. If it receives an input (either asynchronously or as a response), it should update the string item with that.

That’s obviously the simple requirement, which spawns some others such as:
Can it offer either client or server connections?
Is there a need for pre/post-amble additions to the string?
Should the binding handle switches (e.g. send a command when the switch goes Off → On and a separate command when it goes On → Off) or should the binding stay simple and implement switches through rules?
How should it handle different character sets?
Are transformations of incoming strings implemented in the binding or in rules?

These things are never as simple as they first appear and probably all 25 (26 including me) voters have different use cases!

I’m don’t entirely understand the technical aspects of @barneyd’s comments but am interested in inclusion of the TCP binding in OH3 and wanted to contribute to the conversation with my use case:

  • I use the TCP binding to interface with my alarm system.
  • The device is a serial to Ethernet IP adapter and plugs directly into the alarm panel motherboard.
  • I use a text item which gets updated by the device and to which I can send commands.
  • Through rules I have enabled automatic arming/disarming of the system based on presence including monitoring of PIRs and notifications to my phone when movement is detected (had to implement this to avoid the cat triggering the alarm when he struts around on the dining room table when we aren’t home).

Item:

String		ELK_Bridge		"Alarm Code [%s]" { tcp=">[192.168.1.4:2101:default]" }

Rule samples:

rule "Arm and Disarm alarm"
	when
		Item ArmDisarm received command
	then
		switch ArmDisarm.state {
			case ON : ELK_Bridge.sendCommand("8300660A0000E4F?")
			case OFF : ELK_Bridge.sendCommand("83005600000E91?")
		}
end

and

rule "Update Security"
	when
		Item ELK_Bridge received update
	then
		if (ELK_Bridge.state.toString.substring(0,2) == "82"){				//Status Report Data
			switch ELK_Bridge.state.toString.substring(8,10) {
				case "11" : {								                    //Zone Detector Low Battery
					switch ELK_Bridge.state.toString.substring(10,14) {
						case "0000" : ELK_Text.postUpdate("Zone Detector Battery Normal")
					}
				}
				case "12" : {								                    //Miscellaneous Alarms
					switch ELK_Bridge.state.toString.substring(10,14) {
						case "0000" : ELK_Text.postUpdate("No Zones")
						case "0100" : ELK_Text.postUpdate("Zone 1")
					}
				}
				case "13" : {								                    //Miscellaneous Alarms
					switch ELK_Bridge.state.toString.substring(10,14) {
						case "0001" : ELK_Text.postUpdate("Duress Alarm")
						case "0002" : ELK_Text.postUpdate("Panic Alarm")
						//etc
					}
				}
				case "14" : {								                    //Arming Status
					switch ELK_Bridge.state.toString.substring(10,14) {
						case "0000" : ELK_Text.postUpdate("Unarmed")				
						case "0100" : ELK_Text.postUpdate("Area 1 Armed")
						//etc
					}
				}

The tcp.cfg is configured thus:

tcp:addressmask=false
tcp:itemsharedconnections=true
tcp:bindingsharedconnections=true
tcp:directionssharedconnections=true
#tcp:postamble=\r\n
tcp:queue=false
tcp:updatewithresponse=false
tcp:charset=ASCII
#tcp:port=5008
tcp:refreshinterval=250
udp:refreshinterval=250

Just thought I’d add this information as a real-world example in case it is useful if/when someone finds the time and interest to update the binding.

Hi, I would be interrested in an openhab 3 tcp/udp binding, too.

I use it to communicate to a loxone miniserver (in parallel to the loxone binding)

@Lukie that’s almost exactly the same as my OpenEVSE vehicle charger, which I can enable and disable and also send commands and receive status messages. In these cases, OpenHAB is a client. The other case I have is my solar inverter, which tries to connect as a client to OpenHAB as a server to pass status messages. In the case of the old binding, that would be signified by a { tcp="<[ type definition. The problem is it needs a different character set because some of the contents of the status message are outside the standard ASCII range.

In terms of the switches, under the old binding, you could have configured the switch item to send the commands directly by setting it up as:

Switch ArmDisarm "Alarm arm.disarm switch" { tcp=">[ON:192.168.1.4:2101:'MAP(alarm.map)'], >[OFF:192.168.1.4.2101:'MAP(alarm.map)']" }

with the file alarm.map being:

ON=8300660A0000E4F?
OFF=83005600000E91?

It’s probably a useful function for tcp controlled switches as it’s simpler than creating a rule for each one. If you had similar devices on multiple IP addresses, you’d only have to create the map file once and it would work for multiple instances.

You can still keep the String item for parsing incoming messages. In the current binding, you could parse the incoming string with a transformation map rather than a rule.

Your use of the binding illustrates how a simple new binding would work, with all of the other functions performed outside the binding but there is a question of whether to suggest some of this is done by the binding itself, as it is with the v1 version.

Hi,

I’m also interested in a simple TCP binding for OH3.
As Barney already told,

If a linked string item is updated, it should send the string to the TCP connection. If it receives an input (either asynchronously or as a response), it should update the string item with that

Does anyone knows the status of this binding?

I’m also interested in a TCP binding for OH3. I use it for my door bell which is connected to a mobotix front door camera. Here my real world example.

The config file

# all parameters can be applied to both the TCP and UDP binding unless
# specified otherwise

# Port to listen for incoming connections
port=5100

# Cron-like string to reconnect remote ends, e.g for unstable connection or remote ends
#reconnectcron=0 0 0 * * ?

# Interval between reconnection attempts when recovering from a communication error,
# in seconds
#retryinterval=5

# Queue data whilst recovering from a connection problem (TCP only)
#queue=true

# Maximum buffer size whilst reading incoming data
#buffersize=1024

# Share connections within the Item binding configurations
itemsharedconnections=true

# Share connections between Item binding configurations
bindingsharedconnections=true

# Share connections between inbound and outbound connections
directionssharedconnections=false

# Allow masks in ip:port addressing, e.g. 192.168.0.1:* etc
addressmask=true

# Pre-amble that will be put in front of data being sent
#preamble=

# Post-amble that will be appended to data being sent
#postamble=\r\n

# Perform all write/read (send/receive) operations in a blocking mode, e.g. the binding
# will wait for a reply from the remote end after data has been sent
blocking=false

# timeout, in milliseconds, to wait for a reply when initiating a blocking write/read
#  operation
#timeout=3000

# Update the status of Items using the response received from the remote end (if the
# remote end sends replies to commands)
updatewithresponse=false

# Timeout - or 'refresh interval', in milliseconds, of the worker thread
refreshinterval=250

# Timeout, in milliseconds, to wait when "Selecting" IO channels ready for communication
#selecttimeout=1000

# Used character set
charset=ASCII

The items file

   Switch Klingel {tcp="<[ON:192.168.0.10:5100:'REGEX((ON))']", autoupdate="false" }

In addition I have a rule that send a push notification to the iOS App, a TTS on the echo dots and a message to the TV, so everyone will realize it in the house. :slight_smile:

I would really appreciate a new TCP binding for OH3 in order to get rid of the second OH2 installation.

Best Regards,
Marcel

As an interim measure until the TCP binding is updated for OH3 (if ever), you might consider using Node-Red. By using a TCP node which I connected to my TCP listener item in OH3 I was able to replicate the functionality of the TCP binding. I’ve only been testing it for a couple of hours but it seems pretty solid so far.

I achieved this using 2 flows. Flow 1 was a TCP In node connected to a OH-Out node which is mapped to my Elk_Bridge item. This flow receives the TCP stream and passes it to OH. Flow 2 is the OpenHAB-In node, also mapped to the Elk_Bridge item and is connected to a TCP Out node. To assist with testing, I used a debug node in place of the OH node to make sure I wasn’t going to trigger anything.

I have very little experience with Node-Red but I surprised myself with how easy this was to set up. I use openHABian so all I needed to do was install the Node-Red package using the built in config.

Of course my preference is to have less dependence on systems outside of OH, and I definitely didn’t want to run an instance of OH2 just for this alone, so I think this is a good workaround until such time (thinking optimistically here) that the TCP binding is updated. I’ll have to check, but this was the last thing holding me back from going fully OH3, so I’ll be able to progress my migration now.

1 Like

@Lukie , that is brilliant. I am now receiving data from my solar inverter into a string item and processing it with rules. I still need to do a bit of fiddling about to extract the particular fields from the data but I would have needed to do that whatever the means of ingesting the data.

I haven’t cracked how to do sending and receiving data from my EVSE charger yet. I need to look again at how you did the two way comms with the Elk_bridge.

Great as an interim but I’d still rather keep things simple and be able to communicate using a tcp binding.

I had a go using your method, which looks as though it should work for my situation. In Node-Red I see the item change when I change the string and the TCP node says it is connected but the string never appears to reach the charger. I get no response in the other flow and the status of the charger doesn’t change.

@barneyd I’m not very familiar with Node-Red but maybe this can help you. Below are my flows as well as a screenshot of how they look in the GUI. The darker green nodes with “msg.debug” in them are the debug nodes and they populate the debug window on the right hand panel. I didn’t connect the OH node until I could see things happening over there. They are currently deactivated, as symbolised by the half-hidden rectangle to the right of each node. If you’re having trouble you probably don’t want to hear this but I actually did very little configuration and it pretty much worked correctly for me on the first attempt, so there was no real troubleshooting or having to wrestle with settings to get this to work.

Hopefully the info below helps…

[
    {
        "id": "a198c74b.08af98",
        "type": "tab",
        "label": "TCP",
        "disabled": false,
        "info": ""
    },
    {
        "id": "e557f99a.4d646",
        "type": "tcp in",
        "z": "a198c74b.08af98",
        "name": "",
        "server": "client",
        "host": "192.168.1.4",
        "port": "2101",
        "datamode": "stream",
        "datatype": "utf8",
        "newline": "",
        "topic": "",
        "base64": false,
        "x": 300,
        "y": 160,
        "wires": [
            [
                "4e31965b.aae1",
                "6f67c0b2.62582"
            ]
        ]
    },
    {
        "id": "4e31965b.aae1",
        "type": "debug",
        "z": "a198c74b.08af98",
        "name": "",
        "active": false,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 570,
        "y": 200,
        "wires": []
    },
    {
        "id": "6f67c0b2.62582",
        "type": "openhab2-out",
        "z": "a198c74b.08af98",
        "name": "",
        "controller": "cab40e46.548e5",
        "itemname": "Elk_Bridge",
        "topic": "ItemUpdate",
        "payload": "",
        "x": 570,
        "y": 120,
        "wires": [
            []
        ]
    },
    {
        "id": "4108b948.b90148",
        "type": "openhab2-in",
        "z": "a198c74b.08af98",
        "name": "",
        "controller": "cab40e46.548e5",
        "itemname": "Elk_Bridge",
        "x": 340,
        "y": 360,
        "wires": [
            [
                "fb896b5d.ff7438",
                "688700d6.44531"
            ],
            []
        ]
    },
    {
        "id": "fb896b5d.ff7438",
        "type": "debug",
        "z": "a198c74b.08af98",
        "name": "",
        "active": false,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 570,
        "y": 400,
        "wires": []
    },
    {
        "id": "688700d6.44531",
        "type": "tcp out",
        "z": "a198c74b.08af98",
        "host": "192.168.1.4",
        "port": "2101",
        "beserver": "client",
        "base64": false,
        "end": false,
        "name": "",
        "x": 600,
        "y": 320,
        "wires": []
    },
    {
        "id": "cab40e46.548e5",
        "type": "openhab2-controller",
        "name": "OH3",
        "protocol": "http",
        "host": "localhost",
        "port": "8080",
        "path": "",
        "username": "",
        "password": ""
    }
]

Hello all.
I just want to join the group of persons being interested in a TCP binding for openHAB 3.

The openHAB integration of my beamer in my home theater (as I recently posted here: BenQ Beamer via RS232, Serial-to-Ethernet converter and TCP/UDP Binding) just stopped working after upgrading to OH3 yesterday.

So in case there’s anybody out there being able to create a TCP binding for OH3 he/she would be my openHAB hero of the month :wink:
(I’d do it myself if I’d knew how to)

Kind regards,
Ralph…

Hello all,
I’m also interested in the TCP/UDP binding.
As I see in this community thread some users use it in OH3.

From where do you got the executable .jar file? Have you copied it to the “addons” folder of the OH3 installation?

Thanks in advance!

Hi, I do not think there is a binding available for OH3, Lucas uses Node Red as a workaround

I’ve got a Mobotix T24 as door station.
In OH2, I’ve configure it to send a TCP command to launch a DingDong playsound command in openHAB.Today, I don’t know how to integrate it with OH3 … So I also requesting the TCP binding :slight_smile:

1 Like