Use TCP interface?
Closed this issue · 16 comments
Hey, so i notice this uses the UDP interface to the smart plugs, which has the fun issue of fragmentation (and it looks like you hit it on the forums).
The tp-link switches also respond on TCP port 9999, and there is now a raw TCP socket interface on hubitat that lets you control the sockets (and so you don't have to worry about multiple responses or fragmentation).
Any reason not to move over to using it?
(I'm happy to do porting work, just want to make sure i'm not missing something)
Unfortunately, discovery is still UDP broadcast only, which hubitat can't really do.
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.
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
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
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.
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
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
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
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.
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
Dave
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).
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.