BGS5T HTTP Post Problem | Thales IoT Developer Community
June 24, 2020 - 8:44pm, 6657 views
We are making the transision from a BGS2T to BGS5T in one of our products and are experiencing problems when trying to POST data to one of our clients' URLs.
The issue is that when configuring for a GET, we are designated an IP address when starting the session
AT^SISO? .......
^SISO: 1,"Http",4,1,0,0,"10.234.15.70:0","---:443"
When configuring for a POST, we are NOT designated an IP address when starting the session
AT^SISO? .......
^SISO: 1,"Http",4,1,0,0,"0.0.0.1:8008","--:443"
There is a full trace of commands and replies from the BGS5T when attempting the GETs and POSTs below (url and token have been modified for the purpose of this forum)
When running these command sequences on a BGS2T (same SIM card - not that it should make a difference), both the GET and POST result in an IP address being designated.
Any ideas regarding whatis going on here?
Looking at the BGS5T command manual the only relavent difference between BGS5T and BGS2T is the use of AT^SISS=1,hcMethod,1 and AT^SISS=1,cmd,"post" to setup the REST call type.
We are really stuck here - help!
*************************GET****************************************
AT^SICS=0,conType,"GPRS0"
OK
AT^SICS=0,"inactTO", "240"
OK
AT^SICS=0,user,"USER"
OK
AT^SICS=0,passwd,---
OK
AT^SICS=0,apn,"ESEYE.COM"
OK
AT^SISS=1,"srvType","HTTP"
OK
AT^SISS=1,conId,0
OK
AT^SISS=1,cmd,"get"
OK
at^siss=1,hcRedir,0
OK
at^siss=1,"address","https://---"
OK
at^SISS=1,"hcProp","x-token: ---"
OK
AT^SISS?
^SISS: 0,"srvType",""
^SISS: 1,"srvType","Http"
^SISS: 1,"conId","0"
^SISS: 1,"address","https://---"
^SISS: 1,"tcpMR","10"
^SISS: 1,"tcpOT","6000"
^SISS: 1,"cmd","get"
^SISS: 1,"hcProp","---"
^SISS: 1,"hcContLen",""
^SISS: 1,"hcMethod",""
^SISS: 1,"hcRedir","0"
^SISS: 2,"srvType",""
^SISS: 3,"srvType",""
^SISS: 4,"srvType",""
^SISS: 5,"srvType",""
^SISS: 6,"srvType",""
^SISS: 7,"srvType",""
^SISS: 8,"srvType",""
^SISS: 9,"
srvType",""
OK
AT^SISO=1
OK
^SIS: 1,0,2200,"Http ---:443"
^SISR: 1,1
AT^SISO?
^SISO: 0,""
^SISO: 1,"Http",4,1,0,0,"10.234.15.70:0","---:443"
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO: 5,""
^SISO: 6,""
^SISO: 7,""
^SISO: 8,""
^SISO: 9,""
OK
************************POST************************************
AT^SISC=1
OK
AT^SICS=0,conType,"GPRS0"
OK
AT^SICS=0,"inactTO", "240"
OK
AT^SICS=0,user,"USER"
OK
AT^SICS=0,passwd,---
OK
AT^SICS=0,apn,"ESEYE.COM"
OK
AT^SISS=1,"srvType","HTTP"
OK
AT^SISS=1,conId,0
OK
AT^SISS=1,cmd,"post"
OK
at^siss=1,hcRedir,0
OK
at^siss=1,"address","https://---"
OK
at^SISS=1,"hcProp","x-token: ---"
OK
AT^SISS?
^SISS: 0,"srvType",""
^SISS: 1,"srvType","Http"
^SISS: 1,"conId","0"
^SISS: 1,"address","https://---"
^SISS: 1,"tcpMR","10"
^SISS: 1,"tcpOT","6000"
^SISS: 1,"cmd","post"
^SISS: 1,"hcProp","x-token: ---"
^SISS: 1,"hcContLen",""
^SISS: 1,"hcMethod",""
^SISS: 1,"hcRedir","0"
^SISS: 2,"srvType",""
^SISS: 3,"srvType",""
^SISS: 4,"srvType",""
^SISS: 5,"srvType",""
^SISS: 6,"srvType",""
^SISS: 7,"srvType",""
^SISS: 8,"srvType",""
^SISS: 9,"
srvType",""
OK
AT^SISO=1
OK
^SIS: 1,0,2200,"Http ---:443"
^SISW: 1,1
AT^SISO?
^SISO: 0,""
^SISO: 1,"Http",4,1,0,0,"0.0.0.1:8008","--:443"
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO: 5,""
^SISO: 6,""
^SISO: 7,""
^SISO: 8,""
^SISO: 9,""
Further to my previous post, the firmware version in the BGS5T is REVISION 01.100 A-REVISION 00.001.36.
There certainly seems somthing strange with the BGS5T as running the same commands on a BGS2T (same location, same SIM card, same URL etc.) allows me to POST OK.
Again, further to my previous message, the BG5T will obtain an IP address and POST data if I place the data I want to POST din the hcContent, i.e. set AT^SISS=2,"hcContLen","0".
This does not help me though because the data to be posted contains " and this acts as an escape when setting up the hcContent command.
As soon as set hcContent >0 for a POST the module fails to open a data session - this is a show stopper at the moment...
Hello,
The module replies with OK and ^SISW URC which indicates that it is ready to send data. Have you tried to send data with SISW command and then set end of data flag as you can see in the example in AT commands specification document? The actual connection to the server should be started after inserting all the data which you confirm by sending end of data flag.
Best regards,
Bartłomiej
Hi,
Thanks for the reply.
Below is the full trace, including the subsequent posted data on the data session
As you can see, the AT^SISW=2,54 results in an error.
When we run the same command sequence on a BGS2T (to different URl / not HTTPS) it works correctly.
I have also tried following the post example provided in the command guide and this also results in an error on AT^SISW=
What I do not understand in the significance of ^SISO: 1,"Http",4,1,0,0,"0.0.0.1:8008 after the AT^SISO? command?
I believe we should see the allocated session IP address here (and not the 8008 for the <rejCounter>).
When I follow the same process with cmd="get" or cmd = "head" on the BGS5T I see an IP address here and the <rejCounter> = 0. On the BGS2T, I also see an IP address here and <rejCounter> = 0 for a post.
The problem seems to affect only the BGS5T POST. We have been running the BGS5T with GETs for a few weeks and there was never a problem.
I am currently lost in terms what might be missing in the HTTP configuration setup or its order that prevents only the POST from working...
***********************************
AT^SICS=0,conType,"GPRS0"
OK
AT^SICS=0,"inactTO", "240"
OK
AT^SICS=0,user,"USER"
OK
AT^SICS=0,passwd,PASS
OK
AT^SICS=0,apn,"ESEYE.COM"
OK
AT^SISS=1,"srvType","HTTP"
OK
AT^SISS=1,conId,0
OK
AT^SISS=1,cmd,"post"
OK
at^siss=1,hcRedir,0
OK
at^siss=1,"address","https://---"
OK
at^SISS=1,"hcProp","x-token: ---"
OK
at^SISS=1,"hcContLen","54"
OK
AT^SISS?
^SISS: 0,"srvType",""
^SISS: 1,"srvType","Http"
^SISS: 1,"conId","0"
^SISS: 1,"address","https://---"
^SISS: 1,"tcpMR","10"
^SISS: 1,"tcpOT","6000"
^SISS: 1,"cmd","post"
^SISS: 1,"hcProp","x-token: ---"
^SISS: 1,"hcContLen","54"
^SISS: 1,"hcRedir","0"
^SISS: 2,"srvType",""
^SISS: 3,"srvType",""
^SISS: 4,"srvType",""
^SISS: 5,"srvType",""
^SISS: 6,"srvType",""
^SISS: 7,"srvType",""
^SISS: 8,"srvType",""
^SISS: 9,"
srvType",""
OK
AT^SISO=1
OK
^SIS: 1,0,2200,"Http ---"
^SISW: 1,1
AT^SISO?
^SISO: 0,""
^SISO: 1,"Http",4,1,0,0,"0.0.0.1:8008","---"
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO: 5,""
^SISO: 6,""
^SISO: 7,""
^SISO: 8,""
^SISO: 9,""
OK
AT^SISW=2,54
ERROR
54 bytes here...
ERROR
AT^SISW=2,0,1
ERROR
AT^SISC=1
OK
Hello,
The output you see from AT^SISO? after opening the connection with AT^SISO=1 is not actually a problem. It's becasue at this stage there is no connection yet. It should be open after you send end of data flag. So then you should be able to see IP address. In case of GET request the connection is started after SISO command.
The real problem is that you get ERROR on AT^SISW command. Please set AT+CMEE=2 before the connection and also check AT^SISE=<srvProfileId> after the error.
Regards,
Bartłomiej
Hi,
I set AT+CMEE=2 and AT^SISW=2,54 returned invalid index.
Then I realised the service profile is wrong, it is 2 in the command and should be1.
I changed this and now the POST is working!
Thanks for your help - it is much appreciated...
Hi,
It's good to hear that. I didn't notice the wrong index either.
AT+CMEE=2 enables extended error information (if available), so it is always good to activate it in case of any problems.
Best regards,
Bartłomiej
Hi,
I have one more question regarding the HTTP POST on my BGS5T.
After passing 54 bytes of data to the module with a AT^SISW=1,54 command I then issue a AT^SISW=1,0,1 command to end the data.
At this point I expect to see the server response - a 200 acknowledgement or similar.
Sometimes the response is almost immediate, sometimes slower and sometimes there is no response at all.
In the later case, the module then appears to be locked and unresponsive to commands.
I guess the slow / lask of response is due to network problems or the server I am posting too - is that correct?
Also, is there method to regain communications with the module when it is locked in this way?
Currently, powering the module down to reset it seems the only option and I am not sure that this is such a good idea.
Hello,
I think that the longer response time may indeed be related to the network delays. After it comes you should be able to read the response from the server. If there is no URC you should also be able to try to read the reply and get information that no data is available. In any case you should be able to close the connection after that.
Does it mean that you can't send any AT command after sending end of data flag? Or you can at least close the connection. is it the same on other interfaces?
According to my knowledge any network issues should caulse slowing down the module permanently or causing that it does not reply at all forever.
Regards,
Bartłomiej
Hi,
Here is the command trace when I get a response, i.e. things are functioning as expected (URL replaced with ---):
AT^SISO=1
OK
^SIS: 1,0,2200,"Http ---:443"
^SISW: 1,1
AT^SISW=1,56
^SISW: 1,56,0
<--------send 56 bytes to module over RS232 interface here
OK
^SISW: 1,1
AT^SISW=1,0,1
^SISW: 1,0,0
OK
^SISW: 1,2
^SIS: 1,0,2200,"HTTP POST: https://---"
^SIS: 1,0,2200,"HTTP POST Response: 200"
^SISR: 1,1
AT^SISC=1
OK
Sometimes the response after the AT^SISW=1,0,1 command (by that I mean beginning at ^SISW: 1,0,0 and what follows) is immediate, sometimes slow (up-to 10 seconds) and sometimes there is no respose.
During the time after the AT^SISW=1,0,1 command and before the response (^SISW: 1,0,0 and beyond) the module does not seem to accept any commands over RS232 (not sure about the other interfaces).
In the case that no response is received the only option in order to regain control of the module appears to be to power it down to reset it.
Pages