Transitioning from datasocket to tcp to read data at IP address, error 56/66

[colamo95]

Recently, the IP address hosting a temperature data readout window changed in order to be moved to a private VLan network and was given a net10 IP. This new IP address can no longer be opened/parsed by DataSocket. I have attempted to transition to using TCP/IP protocol to read the data from the IP address, and have had what appears to be some success using the TCP Open function (via port 80, unclear if this is the port i am supposed to be using). However, the TCP Read function times out with either error 66 or 56 depending on whether I set the timeout to infinity or not. The dataout node outputs an empty string. I am currently trying to read 10000 bytes, but don't know if this is what I actually should be doing. Here is an image of the site, in case that is useful:

Another quick note, when opening the IP in google chrome, it says it is an unsecure connection first. Not sure whether that could be accounting for the error I am seeing. 

Here is a screenshot of my labview vi for this portion of the code:

 

I'm a relative newbie dealing with this, so the more advice the better! :)) Thanks in advance for any and all help. 

[Sebastian.Weber · Accepted solution]

Hi!

There are two problems here.

First, please read  in the help how exactly the TPC-read VI works. The way you use it, it expects 10'000 bytes to be received within the timeout. If it does not receive 10'000 bytes, it returns the bytes received so far, and an error.

Second, you are dealing with a webserver. To load a webpage, the HTTP protocol is used. After opening the network connection, the server will give a short information about it self, and the client will also give some information - including a request to return a certain webpage (the HTML). Since you don't send anything, the server will never send back 10'000 bytes, and your code runs into a timeout.

Before you start to fix all this: LabVIEW already provides functionality to retrieve webpages using the VIs in

Data Communication > Protocols > HTTP:

---

@colamo95 wrote:

Another quick note, when opening the IP in google chrome, it says it is an unsecure connection first. Not sure whether that could be accounting for the error I am seeing. 

No. It simply says that it HTTP instead of HTTPS is used. HTTPS encrypts the transferred data and uses certificates to check if the server is really the server you wanted to connect to. Hardware devices with web interface typically do not support HTTPS, and browsers like complain about this. It's completely normal.

[colamo95]

Thank you for the advice! This has already helped a lot. 

I have some follow up questions. When I run the http protocol, I get an empty string out from the body output of the http GET function. Below I attach my current set up:

 

This version runs without any errors, but the output monitor returns and empty string. 

Ultimately, I am hoping to report temperature and humidity data by searching for key words in the body of this website. 

Any advice on why I am not getting anything returned in the "body" output? Thank you so much for all your help already. 

 

[Mark_Yedinak]

You need to know the specific URL for the data that you want to get. It looks like you are simply using the IP address of the device. Generally, this will default to index.html if not specified. However, it may not be a GET request. It could be implemented using a POST request as well. You should see if your device has the REST API documented. That would be useful. The other option would be to use Wireshark and a browser to capture the communication. That way you could see exactly what is being sent back and forth which would give you a better idea of what you need to do in your code.

[colamo95]

 Thanks @Mark_Yedinak

The suggestion to use Wireshark was great. I went ahead and tried it and filtered by my target source IP address. 

It appears that all of the protocols are filed under TCP or TLSv1.2. I didn't see any HTTP protocol in the list for this particular connection.

I am very new to all this and am not exactly sure how to proceed. Am I correct in thinking (based on Wireshark) that I should be using a TCP connection instead of HTTP in this case then?

Thanks so much again!

[Mark_Yedinak]

Wireshark is not very useful if you are using TLS since the data is encrypted. As you captured the trace you were using HTTPS, not HTTP. Can you try it using HTTP, which would be port 80. HTTP is not encrypted and then you can look at the data itself. If you are restricted to only HTTPS then you will need to get documentation for the REST API in order to determine what you code should be doing.

[Sebastian.Weber]

Hi

What you obsere with wireshark is a https connection. Port 443 is standard for it, and TLS is the encyption protocol usey by https. And since the data is encrypted, you do not see any HTML code in wireshark.

Now, I'm pretty sure you do not need https  to communicate with a piece of hardware, however, browsers like chrome will always try to use https instead of http.

Now, I'd go ahead like this:

Most browsers come with web developer tools. This can look like in the screenshot below from my firefox.

On the tab Network analysis, it shows which requests the client sent to the server. For example, it first asked for "/". The google server responded with a HTML document. This document contains references to other content, and the browser loads that with additional requests. For example, the big Google logo is a PNG file loaded as googlelogo_color_272x92dp.png.

When clicking one of the requests, you get further details on the right side, including the exact request sent and the response received.

Please analyze what exactly is requested from your device, and where the desired data is.

For example, it is possible that the main html page loads a script, which in turn loads a dataset every 5s from the server and displays it on the screen. In this case, the desired data is not in the main html file, it is in those datasets. Once you found this, you know which file really to request from the device. And since such datasets are often plain text, XML or JSON, they are even simpler to parse than HTML.

Now, you know what to request, but the device still does not return anything?

A request also contains some header lines indicating what type of data and dataencoding the client expects. You may find something like

Accept: image/webp,*/*
Accept-Encoding: gzip, deflate, br

which indicates that the client expects an image, and that the image can be sent for example gzip-compressed.

Some servers do not return data unless the client sends such header lines. So play around with those, LabVIEW's HTTP lib also has a VI to set headers.

And since I don't believe the device insists of https: It does not matter if the browser uses https or http, since that only says that encryption is used or not - the content of the entire data communication is the same.