Hello

I would like to send iammeter data to my shared hosting webserver.

The documentation in https://www.iammeter.com/docs/own-system#32-tcptlshttp indicates it is possible to have a iammeter upload data by HTTP. So on the iammeter's webpage http://192.168.184.122/basic.html, I selected HTTP and entered the HTTP address of the receiving page like iammeter.myserver.be/iammeter.php.

I expected the iammeter to send a http POST request with the JSON data to http;//iammeter.myserver.be/iammeter.php every minute, but that does not happen. I cannot see any access to the http;//iammeter.myserver.be/iammeter.php page (except when I test it from my browser)

What should I do?

please try to use an API address without the suffix "php"

such as 

iammeter.myserver.be/iammeter

Thanks for this fast reply @laoliu

OK. I tried iammeter.myserver.be/iammeter (without php), but unfortunately that does not solve the issue.

I also tried iammeter.myserver.be (which calls index.php), but that script is also not called.

Both addresses work from my browser on the same network as iammeter.

My iammeter software version is 

I tried myserver.be/iammeter and that works.

That is a constraint for me. Could that be solved in the future?

Is it difficult to have support for urls like sub.domain.com/directory/function.lang ?

In my opinion, it is an old style to introduce language suffixes(such as PHP , asp,etc) into URL, so we have not supported it in our code.

Could you please try like this ?

sub.domain.com/directory/lang/function

sub.domain.com/directory/php/function

Yes, having the .php extension is old style, but the purpose was to test excluding issues with things like .htaccess or a framework. I did not expect file extensions not to be supported.

I tried 

sub.domain.be/function but it does not work

domain.be/fuction works

domain.be/directory/lang/function also works

domain.be/function.php also does not work (that is not supported as indicated above)

Subdomain is not working here.

The urls are tested: when called through a browser, it works.

we will check this and reply to you later.

Hi please see my replies below

I have just tested and found that the IAMMETER API  is also a subdomain so it could work well. I do an experiment like this.

1 add a router record of subdomain in our LAN(point to the IP of 198)
2 input the subdomain address in the energy meter, there is also a . PHP suffix.
3 Run a tcp server in the ip that pointed by the subdomain

Then we saw the the data that posted by the HTTP, which include the correct field that HTTP protocol required.(you can find the "/iammeter.php" in the first line )  

because this is just a TCP server that without any function about the HTTP check.(although I think it seems like a correct HTTP content ,but I can not be completely sure)

So I do another experiment.

I run a simple HTTP server here https://github.com/lewei50/iammeter/tree/master/Tools/HttpServer/Node.js

And get such results in the below pics.

It also proves that both the subdomain and the suffix of "PHP" are OK.

I think there should be some setting mistake in the configuration of your server.

This is my suggestion in your testing:

1 You can also do the testing by this simple HTTP server  https://github.com/lewei50/iammeter/tree/master/Tools/HttpServer/Node.js and check whether the setting that includes both subdomain and suffix can work well.

2 You can also use some http test software (such as postman) to post the data directly to your server.

you can just post this simple content and check whether it could be received by your server successfully

{
	"version": "1.1",
	"mac":"xxxxxxxx",
	"SN": "yourSN",
	"Data": [220, 0.1, 20, 0.1, 0.1]
}

you can also input the different URL styles in the postman .

If there is any further result, please do not forget to let me know, thanks

Sorry for keeping you waiting. I have no access to my test iammeter this week.

Thank you for testing on your side. This is strange. I tested my urls with my browser and they all work with browser, but not with iammeter.

I see port numbers in your screen shots: 8000 and 8888.

But http should use port 80.

Could that explain the difference? 

laoliu

If there is any further result, please do not forget to let me know, thanks

Hi:

Yes, we post to port 80 of the URL(although the HTTP post function does not limit within port 80).

if we want to post to another port (not port 80), we should use the such format in the HTTP address

"abc.com:12345/uploadurl"

if there is no port after the domain, it means we use the default port (80)

The x-forwarded-xxx header is with regards to the load balancer.

please refer to https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html

I think the only difference between us is the HTTP server and the server configuration.

So strong recommend you use this simple HTTP server (what we used ) to do a test firstly

  https://github.com/lewei50/iammeter/tree/master/Tools/HttpServer/Node.js 

Hi 

The server is shared hosting and I have only limited control over it.

The server handles the POST requests with POSTMAN as desired, but the same url does not work with iammeter: the script is not called.

I see POSTMAN automatically generates some default http headers:

I removed headers one by one to see if that could explain why my script is not called.

The required http headers are (with example values)

POST /directory/lang/script.php HTTP/1.1

Connection: close

Content-Length: 236

Host: sub.domain.be

Content-Type: application/json

User-Agent: MXCHIP devicebit iammeter

If any of these headers is missing, the message is not accepted by the server.

There is no 'Content-Type' or 'User-Agent' header in the 2022-09-26 10:12 screenshot above. So I guess iammeter is not sending these http headers and that is why my server does not accept the http message from the iammeter.

Could the 'Content-Type' or 'User-Agent'  headers be added to the iammeter http requests?

Thanks

Polfo

Hi:

I do not think these two headers are a must in the HTTP post information.

It should be just your HTTP server code requirements, not the HTTP post requirements.

In my opinion, maybe the Content type is the key to this problem, maybe some HTTP server settings cause this problem. (you can remove this header from the postman and check whether the data would be accepted by your HTTP server)

Because there are already some large customers that use the HTTP post to upload data to their own server.
So we can not add such headers rashly(Unless we inform them to do the testing again).

If you want to develop your own server, you should get total control of both the server setting and the code.

If you can not change any settings finally, recommend considering use another method, such as MQTT ,like this 

https://www.iammeter.com/docs/integrate-with-mqtt-server

> maybe the Content type is the key to this problem, maybe some HTTP server settings cause this problem.
> (you can remove this header from the postman and check whether the data would be accepted by your HTTP server)

When I remove either Content-type or User-Agent from POSTMAN, the data is not accepted by my HTTP server.

laoliu

Hi:I do not think these two headers are a must in the HTTP post information.It should be just your HTTP server code requirements, not the HTTP post requirements.In my opinion, maybe the Content type is the key to this problem, maybe some HTTP server settings cause this problem. (you can remove this header from the postman and check whether the data would be accepted by your HTTP server)Because there are already some large customers that use the HTTP post to upload data to their own server.So we

https://www.rfc-editor.org/rfc/rfc2616#section-7.2.1

Any HTTP/1.1 message containing an entity-body SHOULD include a
   Content-Type header field defining the media type of that body. If
   and only if the media type is not given by a Content-Type field, the
   recipient MAY attempt to guess the media type via inspection of its
   content and/or the name extension(s) of the URI used to identify the
   resource. If the media type remains unknown, the recipient SHOULD
   treat it as type "application/octet-stream".

https://www.rfc-editor.org/rfc/rfc2616#section-14.43

14.43 User-Agent

   The User-Agent request-header field contains information about the
   user agent originating the request. This is for statistical purposes,
   the tracing of protocol violations, and automated recognition of user
   agents for the sake of tailoring responses to avoid particular user
   agent limitations. User agents SHOULD include this field with
   requests. 

https://www.rfc-editor.org/rfc/rfc2616#section-1.2

An implementation that satisfies all the MUST or REQUIRED
   level and all the SHOULD level requirements for its protocols is said
   to be "unconditionally compliant"; one that satisfies all the MUST
   level requirements but not all the SHOULD level requirements for its
   protocols is said to be "conditionally compliant."

So, currently, iammeter is "conditionally compliant". It would be nice if iammeter could be "unconditionally compliant" :-)

Hi:
I have reviewed the code and found it only includes such headers in the HTTP post
Host,connection, content-length

Could you mind telling me which HTTP server you run? we will let my colleagues install it and have a try. Do you develop the HTTP server by yourself or use some existing HTTP server?
Because there are a lot of customers that use the HTTP post (in fact, IAMMETER cloud also uses it as the upload mode), we had never reported this "conditionally compliant" problem.
So I want to confirm more. Install it on my side and test it.
We still do not think it is a strict limitation in the HTTP server.
But if it indeed what you have claimed, lose such a header will cause a "conditionally compliant" problem, we will plan to add such headers in HTTP post .

Hello

It is an apache web server, but I have no access to the configuration of the server since it is a shared hosting system managed by the hosting provider, with multiple users on the same configuration. Once we have hundreds of meters, we can move to a self managed solution, but for now this is the system we use.

I tried it with two different shared web hosting providers (combell.com and ovh.com) with the same result.

"I tried it with two different shared web hosting providers (combell.com and ovh.com) with the same result."

Yes, this has nothing to do with the hosting provider, just the web service configuration ("apache ")

I will let my colleague to install a apache and do some testing, then reply to you here.

Hi: 

One more question.

As you posted in this pic, 

please let me know why there are some options that work( Because the post is always without the  header of "Content-type and User-Agent")