Hexadecimal string in tcp binding

Continuing the discussion from Exec binding for UDP commands:

I want to control the switching on and off of my monitor in Telnet via the new TCP binding, I communicate well with it but the hexadecimal string received by the monitor contains an additional value that I cannot explain to myself

The frame expected by the monitor is: “hAAh11h00h00h01h12”
and when I send this frame the monitor receives
“hC2hAAh11h00h00h01h12”

This is against the rule I use.

rule “TV Samsung Power”
when
Item Val_samsung_PWR received update
then
if (Val_samsung_PWR.state == ON){
var String MyNumber = “u00AA\u0011\u0000\u0001\u0001\u0013” // SAMSUNG POWER ON
TCPUDPClient_TCPsendString.sendCommand(MyNumber)
logInfo (“TV Samsung Power”, “TV On”)
}
if (Val_samsung_PWR.state == OFF){
var String MyNumber = “\u00AA\u0011\u0000\u0001\u0000\u0012” // SAMSUNG POWER OFF
TCPUDPClient_TCPsendString.sendCommand(MyNumber)
logInfo (“TV Samsung Power”, “TV Off”)
}
end

Why is there an additional hC2 value before the hAA header.
Thanks for your help.

I‘ll check that.

FYI, if I only send h11\h00\h01\h01\h13
Where
h11\h00\h01\h00\h12
I don’t have the problem
and if I send only hAA, I find hC2/hAA
.

It’s very strange

But you’re not 'sending either of these, you are creating a string command in some fashion, and exactly how you do that may be relevant.
I’m sure it’s as you already showed n the rule, but lets be clear.
It does all rather feel like encoding issue of bytes > x80.

I continued my tests and it turns out that the phenomenon only appears for hex values ​​greater than or equal to h80.

It might be a clue

If the first bit is 1;
h7F = \b01111111
h80 =\b10000000
so it seems that the processed value is limited to 7 bits and not 8.

Is it somehow related to 1 at first bit? For java and its signed by default types it can cause troubles if you get unsigned values.

Set the “Fallback Encoding” to ISO-8859-1 and it works.

Thanks

But I am not a developer and beginner with OpenHAB.
How do we do this exactly?

I’m on a raspberry 4, openhabian and openhab 3.2

Go to the thing configuration page, click on „Advanced“, scroll down to „Fallback Encoding“, enter „ISO-8859-1“, click on „Save“. Done.

thanks i will look at that tomorrow.

Hello

I made the modification in “thing” and indeed it is the correct frame now. However, there remains a problem, I use the “Hercules” utility under Windows to test the control of the monitor and it works very well but with OpenHAB nothing happens even though the good frames sent are indeed linked.
How can I check what the monitor is responding when I am connected with OpenHAH?

Wireshark?

1 Like

Sorry

I not understand.

Wireshark is a utility you can use to capture network packets, to examine these monitor messages.

1 Like

ok i’m looking at this. thank you

Hello

I’ve done various tests and checks but I don’t understand what’s going on.
I compared the frames sent by the TCP thing and the frame sent from the “Hercules” utility with a PC and they are identical.
With the “Hercules” utility I have the answer to send (see img_1) how can I see the answer in the TCP thing?

If anyone can help me that would be great

How have you setup your TCP Thing to listen for incoming data?

see below if its correct


The problem seems solved.
I have to send the frame twice, obviously according to the openhab log file, the first opens the connection and the second triggers the command.

FYI, sending with my PC only required one frame.

anyway thank you for your help.