Having problems with the TCPHelper Class

[mrburns42]

I am trying to use the TCPHelper class in a script.  I started with python.  My python script ran and seemed to execute, but the OnStringReceived method never got executed.  I can see TCPIP activity by monitoring the port with netcat.   Yet, HG never triggered.  I can see the python script starting up, so it is actually getting into the run section of the code.  It is just not executing the sub-routines.

After hours of fussing with the python script,  I turned to C#, since the serial port helper example used that language.  I attempted to directly port the serial port example to my code.  However, with C#, nothing seems to happen.  The code starts, but I never even get into the run section of the code.  Even though I set the trigger section to return true.   Attached is the exported C# code.  (Right now, this is informational only.  If it sees TCPIP events, it would only print them out.)

Questions:

1.  What did I do wrong in the C# code?
2.  The python script, I had to prefix commands with "hg."  Is this required for C#?
3.  The Virtual LED symbol next to the module turns RED when I ran the python version.  The Virtual LED is YELLOW with the C# version.   What do the colors mean?

Thanks for any pointers.

[Gene]

Program.Notify takes two arguments.

Code: [Select]

Program.Notify("Title", "Message...");

see attachment.
P.S. Did you click Compile after changing the code? =)

[Gene]

This is the correct version of your program.
Double che IP and Port since if these are not right the TcpClient will hang for a long time before going to timeout.

g.

[mrburns42]

Gene,

You were correct.  I was modifying the code without compiling it.  I started with a Python script, so I got into the habit of just saving the script and then restarting it.

After recompiling the code,  it now makes the connection to TCPIP port.   I get the connected message.   However, it still does not seem to receive the strings that can be seen in netcat.   

It only takes less than one second from initializing the TCPClient to getting the connect message, so I know the IP address and port is there.   I also tried sending data, to the port.   That method is called without anything bad happening, but the message never appears at the TCPIP port because netcat does not report it.

The funny thing is that one time when I disabled the C# program, then I got a large flood of X10 RF data in the log.  The CM19A is a USB to RF X10 interface.   The log had entries for X10 events that happened hours before the program was disabled.  Below are some samples of what came out in the log.

19:25:35.546   X10_RF String   11/27 16:37:48 Rx RF HouseUnit: C3 Func: Off    1001   HomeAutomation.HomeGenie.Automation
19:25:35.540   X10_RF String   11/28 01:27:21 Rx RF HouseUnit: C3 Func: On    1001   HomeAutomation.HomeGenie.Automation
19:25:35.536   X10_RF String   11/28 01:26:54 Rx RF HouseUnit: C3 Func: On    1001   HomeAutomation.HomeGenie.Automation
19:25:35.522   X10_RF String   11/27 16:36:33 Rx RF HouseUnit: C3 Func: On    1001   HomeAutomation.HomeGenie.Automation

The first timestamp is from HG, of course.  The "X10_RF String"  indicates that the string message handler is my C# code fires.  The date, time stamp and the rest of the X10 data came from the mochad driver.   Both the driver and HG are running on the same Raspberry Pi, so I would expect their timestamps to be close.  Notice that when HG got the messages is vastly different than when mochad posted them to TCPIP.  It is almost like they are being buffered up somewhere in a non-sequential order.

I tried to recreate the situation by starting the C# program, sending some data to the port, and then disabling the C# program.  However, other than the one time,  this still did not produce any messages. 

Anyway, thanks for the help.  I will keep playing with it and seeing if I can get it to dump the data again.

[Gene]

Thanks for you detailed report. I suspect then that the TcpHelper is not working properly.
I'll check the code and make some test soon. Once I got this working I'll post an update to the TcpClientLib.dll here so you can test.

Cheers,
g.

[Gene]

Hi mrburns42,

had a chance to fix bugs in TcpClient helper.
I'm attacching the fix. Just stop the service, replace the two files in the HomeGenie folder and restart it.
-------
    - Fixed issues affecting TcpClientHelper (issue #48)
    - Fixed bug in releasing resources used by SerialPortHelper, NetHelper and TcpClientHelper
-------
There's a new property "TcpClient.EndOfLine" that let the user specify the line separator used in text messages sent by the server (default is set to "\n").
Also attacching a demo IRC chat client app I used for testing.

Cheers,
g.

[mrburns42]

Hi Gene,

It Works !!!!!!!!!!!!!!!!!!!!!!!!!

Thank you so much for the super quick troubleshooting.   When I send an RF X-10 command now I get an immediate Program Notify message.   When I look at the log file I see the following:

10:08:41.536   X10 RF String   11/29 16:08:41 Rx RFSEC Addr: 3F:00:00 Func: Contact_normal_min_DS10A   1000   HomeAutomation.HomeGenie.Automation
10:08:41.535   X10 RF Bytes   31-31-2F-32-39-20-31-36-3A-30-38-3A-34-31-20-52-78-20-52-46-53-45-43-20-41-64-64-72-3A-20-33-46-3A-30-30-3A-30-30-20-46-75-6E-63-3A-20-43-6F-6E-74-61-63-74-5F-6E-6F-72-6D-61-6C-5F-6D-69-6E-5F-44-53-31-30-41-0A   1000   

So, it is firing twice, once for bytes and once for strings.  I suspect this is normal, as strings are groups of bytes.   In later code, I guess I will just turn off the Bytes portion or make it a "do nothing" method. 

Also, I noted that HG has the correct time in its timestamp of 10:08 AM.  The timestamp from mochad is GMT apparently because it is six hours ahead which is the offset for where I live.   

I do not have time to check transmit yet,  as the wife wants me to climb on the roof and install XMAS lights in  a forty mile per hour wind.   I will try to test later today.

Thanks again.

[Gene]

Hey mrburns42,

glad it worked =)
Yes you can turn off bytes receiving if you don't need it.
The timestamp used by HG is in UTC format, you don't have to worry about conversion since in the UI will always be reported as user's local time.
Please update on any further progress you make with this and also if you need any help, I'll be glad helping.

Cheers,
g.

[mrburns42]

OK,  I have verified that the TCPHelper Class can also send TCPIP messages as well as receive them on my installation.  At first, it did not work for me because I put the TcpClient.SendMessage() call inside the Receive Message Handler.   (This was the easiest place since the main program was already running in the background.)   I incorrectly assumed that this is a subroutine within the program code, it would have the same scope and would access the same TCPHelper instance.   This is apparently a faulty assumption.  The SendMessage did not work from there.  However, when I moved it to immediately before the main code goes into background mode, then it worked.