OpenHAB 3 TCP binding

the issue was I needed to use the 3.2.0 version of the Jar file.
it works fine now thanks to j_N_K for providing

Is there still no TCP binding for OH3? Without I am not able to control my JVC projector anymore :frowning:

No news for a long time.

Have you tried the NodeRed workaround?

what exactly do you want to do ? Send commands via TCP or also receive feedback via TCP ?
I assume it should be possible to create something on the command line that can be executed e.g. via executeCommandLine.

Send commands via TCP or also receive feedback via TCP ?

Feedback is also required. Implementation was done and posted in a different thread: Binding Request: JVC Projector - #24 by omatzyo

Did you have a look to GitHub - bezmi/jvc_projector: Python library to control JVC projectors as long as the TCP binding is not available in OH3 ?

Did you have a look to GitHub - bezmi/jvc_projector: Python library to control JVC projectors
I will probably have to and will have to rewrite the configuration.

I am not that familiar with python yet. It seems that I will have to wrap the linked python script. What is the best way to do so, using the exec binding? The script needs some additional steps to do at the beginning (configure IP address, create instance, perform actual method and so on). Is it possible to pass this information to the script with the exec binding?

What are the commands that you would like to execute ?

I tried passing the commands to the python interpreter within one String. I have to separate the commands with “\n” in that case. But it does not work. I added the following to exec.whitelist:
python.exe -c "exec('from jvc import JVCProjector\nprojector = JVCProjector(\"192.168.130.180\")\nprint(projector.power_state())')

The command in exec.things is:
command="python.exe -c \"exec('from jvc import JVCProjector\\nprojector = JVCProjector(\\\"192.168.130.180\\\")\\nprint(projector.power_state())')"

…but it actually does not work. It must be something with the line feeds which breaks the syntax I guess.

So now I am reducing the exec-command to “python.exe myscript.py %2$s” and will have to do the rest in python. It will probably work, but it takes a lot of time for me. Well, kind of frustrating how much effort the migration from v2 to v3 actually is…

If somebody else is interested, as described above it works with this little additional python-script:

import sys
from jvc import JVCProjector
projector = JVCProjector("192.168.130.180")
class_method = getattr(JVCProjector, sys.argv[1])
print(class_method(projector))

This way I can pass the function to execute (e.g. “power_state”) to the script.

1 Like

There was a OH3 port of the TCP Binding - but it disappeared again: link I dunno what happened but it seems the OH Foundation asked to remove it.

Could be that you now find it at: Central Repository: org/smarthomej/addons/bundles/org.smarthomej.binding.tcpudp/3.2.8

I downloaded tcudp 3.2.8 and tried to use it, but without success. I hope someone here can help me with it.

I am using OH 3.2.0 on Windows 10 machine. My attempted use of tcudp binding is for the purpose of communicating with an esp32 device which is intended to serve as an intermediary between OH and the serial port of a Devialet amplifier. The esp32 chip is running a ready-made program called ser2net (see Ser2Net - Let's Control It) which is meant to receive tcp data (in my case from OH) and forward it to the serial output port of the esp32 which has previously been connected with another device (in my case, the Devialet amplifier). The ser2net documentation mentions that “The ESP Easy firmware can be used as a generic Ser2Net gateway. This will bring serial communication to the wireless network. This will only work if the controller supports a lan connection where it will use ‘telnet like’ communication to the other end.”

I verified that this kind of communication is indeed working using the Arduino serial monitor and starting a telnet session from a remote machine toward the ip address of esp32, on port 3000 (which ser2net is setup to monitor). Upon receiving the telnet connection request, the ser2net program responds:

Error : Ser2N: Client connected!

The “error” mention here is probably incorrect, as there does not appear to be any error: the telnet connection is thereafter working fine: strings get successfully sent in both directions between the telnet client and the Arduino serial terminal. Then, when I terminate the telnet client, the Arduino terminal reports:

Error : Ser2N: Client disconnected!

So far so good, but unfortunately things do not work as I expected with my OH tcudp setup.

What I did :

  1. I created a tcpudp client thing that I configured as using the tcp protocol for the ip address of my esp32, port 3000. I then linked a string-type channel of that thing with a string item named “TCP_send_test”. As long as this item remains uninstantiated, the status of the tcpudp thing remains marked as “Unknown”.

  2. I included the following element in my sitemap:

     Selection item=TCP_send_test mappings=[1="1", 2="2",3="3",4="4",AUTO="AUTO",QUIET="QUIET"]

This allows me to instantiate the TCP_send_test item at will to a string such as “4” or “AUTO”. When I do that for the first time, the status of the tcudp thing changes to “Online” and the Arduino serial terminal reports:

Error : Ser2N: Client connected!

However the string to which the TCP_send_test item was instantiated does not appear on the Arduino terminal. Thereafter, the status of the tcudp thing remains unline “Online”, and any new instantiations of the TCP_send_test string have the same effect on the remote terminal, that is, the same message gets printed:

Error : Ser2N: Client connected!

but the strings do not appear to be received the Arduino terminal. Conversely, strings sent from the Arduino terminal do not appear to be received by OH.

I am including the log of a session in which OH gets started with “org.smarthomej.binding.tcpudp” set to DEBUG. I am not expert enough to see if all the stuff reported at the time of the tcudp startup (between 13:41:44.043 and 2022-02-18 13:41:44.114) is perfectly normal. But I note that afterwards, when the TCP_send_test gets instantiated, nothing related is shown in the log, even though we know that the binding does react since the “client connected” message gets shown each time on the Arduino terminal. The instantiation process is shown, as expected, in the event log:

2022-02-18 13:43:22.899 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'TCP_send_test' received command QUIET
2022-02-18 13:43:22.900 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'TCP_send_test' predicted to become QUIET
2022-02-18 13:43:22.903 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TCP_send_test' changed from NULL to QUIET

I hope you can offer me some clues as to what is going wrong in my setup.

Many thanks in advance.

Careful; in openHAB terms, this allows you to send a command to the openHAB Item when you click at the GUI.
The command will be forwarded to the TCP channel for action.
Unless you’ve changed the Item default, it will also invoke the autoupdate feature which will guess at a likely outcome and update the Item state to the prediction. In the case of a String type, the predicted state is just a copy of the string command of course.
Sometimes it is important to understand the flow of actions.

Okay, there’s the autoupdate action, and nothing more of interest.

You could consider disabling autoupdate on your Item so that its state only reflects updates coming from the TCP channel (if any), make it easier for you to experiment.

We’ll need to see that, as it doesn’t work.

What strings do you need to send to get a response?

I’m guessing that if openHAB sends the string “1” only, this is not a ‘telnet like communication’.

Many users of ESPEasy with openHAB use MQTT methods.

Thanks, but it is not clear to me what it means when you say that “the command will be forwarded to the TCP channel for action”. My understanding of channel profiles is rather sketchy, but I am using the default profile. So, I was assuming that nothing more than the string value I am sending to my item would be forwarded to the channel. Is that wrong? If it is, how can I make sure that only my desired string will be sent to the channel?

Here is the code for the TCP thing:

UID: tcpudp:client:c9a0ae2145
label: TCP/UDP Client
thingTypeUID: tcpudp:client
configuration:
  protocol: TCP
  delay: 15
  port: 3000
  host: 192.168.2.253
  refresh: 30
  encoding: ascii
  timeout: 3000
  bufferSize: 2048
channels:
  - id: Devialet
    channelTypeUID: tcpudp:string
    label: Devialet
    description: ""
    configuration:
      mode: READWRITE

At this time, I was not concerned with whatever the remote serial device would be sending back, because that device is not even connected yet. Instead I am using the Arduino serial terminal to check whether or not the commands from OH are being received. The ser2net documentation mentions the following: “You can test communication using the good old telnet tool, just connect to the ESP IP address and start typing. Characters should appear on the serial port. You can verify this using the Serial Monitor from Arduino IDE.”

The crucial point is that when I connect to my esp32 with a remote telnet, the strings I am sending to the esp32 get posted on the Arduino serial monitor. Moreover, the strings I am typing in the Arduino monitor get posted on my remote telnet session. This appears to confirm that the ser2net program on my esp32 is working as expected and therefore, that the problem lies in the way tcudp is trying to communicate with it (i.e. differently from a telnet client).

In that respect, I note that every time tcudp tries to send something to the esp32, the ser2net program responds “connected”, but fails to post the string that was presumably sent by tcudp. The opposite “disconnected” event is never posted. This is in contrast with a telnet session where one must first explictly connect (acknowledged by ser2net), then go on with the session and finally explictly disconnect (acknowledged by ser2net).

Right: I guess I would need to understand exactly what “telnet-like communication” is.

As for MQTT, I know. Actually, I am already using it in an application where OH is communicating with an esp32 that interfaces with my Mistubishi heatpump. The difference is that in that case I had the luck to find a ready-made espeasy program that interfaces MQTT with the serial port of my heatpump. No such luck with my Devialet amplifier and I couldn’t even find a more generic espeasy program that interfaces MQTT with general serial commands. Thus, I would need to write the whole esp32 progarm myself, which, at this time, happens to be not so easy for me.

Yes,it is as simple as that. The string command arrives for the binding to deal with, and none of that has anything to do with Item state or ‘instantiate’ it.

Sounds good. openHAB must first open a TCP connection - a handshaking interchange with the ESP - before anything can be sent.

After that is complete, the binding should send a simple TCP packet containing ascii “1”

Don’t know myself; but I think there is negotiation before any data gets exchanged.

TCP binding is just that; not a telnet client.

Tanks a lot for your help!

Since there is still no OH3 UDP-Binding, maybe this is a helpful and simply workaround for someone:

import java.io.IOException;
import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;

rule "Wohnzimmer Gyverlampe AN"
        when
                Item WZ_Feuer_Lampe changed to ON
        then
                logInfo("gyver.rules", "Schalte Wohnzimmer Feuerlampe AN")
                val socket = new DatagramSocket()
                try {
                        val address = InetAddress.getByName("192.168.0.162")
                        val msg = "P_ON"
                        val packet = new DatagramPacket(msg.getBytes(), msg.getBytes().length, address, 8888)
                        socket.send(packet)

                        logInfo("gyver.rules", "Wohnzimmer Feuerlampe AN")
                } catch (IOException e) {
                        e.printStackTrace()
                } finally {
                        socket.close()
                }
end

Cheers

there is one via third party marketplace ( TCP/UDP Binding )

TCP/UDP Binding (SmartHome/J version) does anyone know this was removed [removed on request of the openHAB Foundation] ?