Use TCP interface? about test-code HOT 16 CLOSED

Thanks for the offer. I have done some initial testing - but without success. Any assistance would be appreciated. I have placed a test driver at:
"https://github.com/DaveGut/Hubitat-TP-Link-Integration/blob/master/tcpTest/tcpTest.groovy"

This driver

• runs the UDP version of the refresh - returning results as info messages.
• runs the TCP version - returns the results as warn messages (for ease of reading

Did not have success. The UDP worked; not the TCP. Possible causes:

• TCP comms miscoded
• Encryption not being done as I expected (see note in Method tcpEncrypt). This method is the same as the udpEncrypt except the header.

from test-code.

I'll take a look.
Just so you have a testbed, here's a CLI you can use that uses TCP (It's a modified version of a proof of concept someone else wrote):
https://gist.github.com/dberlin/b980a27557e56d8eef81a6be55752ddc

from test-code.

Note: The first 4 bytes of the TCP response are the length of the message (minus the 4 byte header), in network byte order.
I wonder if your json parsing is failing because of trying to parse that

from test-code.

For the UDP, no. The Hubitat code decrypts the message and I have captured that message. If the length of the decrypted return is greater than 1023 characters, the return message truncates. I used to concatenate this with the second message (when I used the node.js server as a bridge) and then successfully parse.

What I am seeing in testing is there is nor return to the parse method (before doing any parsing). I think the encryption is not being done correctly or the comms are not going through.

from test-code.

from test-code.

Thanks. I agree with your comments (my error in the code). There are still queries on Hubitat on actual format for the send message. Unfortunately, I do not have the wireshark setup for capturing Hubitat to Switch traffic (sigh). What I will try is direct the message to my PC running a node.js TCP server and see if that sees the message (I have done that in the past with minor success).
Dav

from test-code.

Created a quickie TCP Node.Js server and tested on my PC. It works.
Generated Command (from tcpEncrypt):
0000001dd0f281f88bff9af7d5ef94b6d1b4c09fec95e68fe187e8caf08bf68bf6

Command received at PC:
A new connection has been established.
Data received from client
<Buffer 00 00 00 1d d0 f2 81 f8 8b ff 9a f7 d5 ef 94 b6 d1 b4 c0 9f ec 95 e6 8f e1 87 e8 ca f0 8b f6 8b f6>
Closing connection with the client

Line-by-line compare (PC on top)
0000001dd0f281f88bff9af7d5ef94b6d1b4c09fec95e68fe187e8caf08bf68bf6
0000001dd0f281f88bff9af7d5ef94b6d1b4c09fec95e68fe187e8caf08bf68bf6
UDP : d0f281f88bff9af7d5ef94b6d1b4c09fec95e68fe187e8caf08bf68bf6

Node.js server:
test .js.txt

from test-code.

Success. I am getting and doing the initial processing (to known JSON input) using RAW TCP. Final code is below (for your records).
Thanks for the not, push, and assistance.

Dave

tcpTest.groovy.txt

from test-code.

dberlin,
Again thanks for the help. Issue:
TP-Link has been busy disabling TCP communications on port 9999. Hubitat support both TCP Protocol.RAW_LAN messages and TCP rawSocket messages (differences in implementation / overhead).
Bulbs: These support the TCP rawSocket messages. Do not support the TCP Protocol.RAW_LAN.
Early Plugs and Switches: Support both TCP protocols.
HS-107 Multi-Plug: These support the TCP rawSocket messages. Do not support the TCP Protocol.RAW_LAN.
HS-300 Multi-Plug with EM: Does not support either TCP protocol.

from test-code.

from test-code.

If you have Hubitat, you can test yourself. Attached is the driver for a manual installation
Create the virtual device using the below driver.
Enter the IP address of any plug/switch other than HS-300.
Turn on logging
Run Refresh (it will run UDP, raw TCP, and RAW_LAN)
Expected result for a HS-115: successful return from each method.
Enter the IP address of your HS-300.
Run the refresh again
Note there is NO response from the TCP protocols.

I have attached the driver and a copy of the log files for the HS-105 and HS-300.

HS-300 Return.txt
HS-105 Return.txt

TEST DRIVER.groovy.txt

Dave

from test-code.

That of course does not mean that the problem is not with Hubitat. I did note (physical observation) that on the raw TCP socket, the device turned on or off (if sent the command) - but did not respond. Not true for the RAW_LAN protocol suggested by the Hubitat staff.

Do you perhaps know the port that the Kasa App uses (it may be 1040 or some other port).

from test-code.

from test-code.

from test-code.

from test-code.

Did some further testing. The Raw_Tcp commands return correct data for the three Energy Monitor queries. It does not work for refresh on the HS-300, but does work for refresh on the LB120/130. I could not test on the HS-110 (no device to test).
Result: I will test again on Jul 31 and see if the returns are fragmented. If not fragmented, I will use the Raw_TCP to get Energy Monitor data (and modify code to remove work-around). If fragmented, no changes.
Experimentation indicates that the problem is in the devices, not the Hubitat commands. go figure.
The new test driver is below, if you have any EM devices.

Dave
TEST DRIVER.groovy.txt

from test-code.