How to handle different responses?

[tomy983]

@prampec

Hello, I have an issue.. I've added a command ad handlers to shut gprs. The AT response is "SHUT OK", on the same line.

void handleSHUT(char* result);
GsmHandler SHUTHandler = {"SHUT ", handleSHUT};  // gprs shut
gsmAsync.registerHandler(&SHUTHandler);
gsmAsync.addCommand("AT+CIPSHUT");  // CIPSHUT will close *all* open connections

my handle function is as follows:

void handleSHUT(char* result) {
    if (strcmp(result, "OK") == 0) {
        Serial.println("GPRS IS : SHUT");
    } else {
        Serial.println("GPRS IS : NOT SHUT");
    }
}

and it gets called as expected. Here is the debug output:

132.66 GSM CMD: AT+CIPSHUT

SHUT 
132.67 Calling handler for 'SHUT ' with argument 'OK'.
GPRS IS : SHUT

134.66 Timeout for 'AT+CIPSHUT' (2000 ms).
134.67 GSM CMD: AT+CIPSHUT

which shows that even if the response is handled, triggers the timeout and eventually the

Retries exceeded.
GSM not responding

I suspect it is because it treats the OK in the "SHUT OK" response as an argument and expects another OK, but I am not able to correct this in the code. Can I please have some help?

[prampec]

No, I don't think this is the problem. First of all, if any OK is confirmed, why should we expect another OK? And confirmation OK strings is only accepted after new line.

You might want to turn on more debugging e.g. level 3 to the details.

[tomy983]

Thank you for your answer.
I turned on level 3 debugging, and in this particular case the OK does not come after a new line, but on the same one.

[prampec]

What can I say? Confirmation OK is per-definition arrives in separate line. Your device might not follow the standards.
You might want to call the gsmAsync.clearCommandQueue() in case you are certain there is no messages you are expecting response for.

[tomy983]

These are from the sim800 datasheet, as you can see there are also non standard responses. I would not want to clear the queue, is one of the best part of this library (great job, by the way!).
Is there another method to define ok or as error a response once is checked in the handler function?

Also, for example, the command AT+CIFSR is returning the ip address as a string and nothing more...

[prampec]

Okay. Sorry, understood.
Maybe we should add another helper method to release the _waitingForResponse flag.
Another solution can be an option for addCommand() whether we are expecting OK response or not for the command.

[tomy983]

Yes! an option to the addCommand() would be the best I think. Possibly, when this option is set, the whole response would still be handled by the library on the serial side, but it would be returned to the handler function. This would possibly cover all the particular cases... I don't know how it is possible (sorry, my programming skills are very bad), since the method to set the GsmHandler is to define a fixed response "header" but, for instance, requesting the ip address does not returns a fixed "header" at the beginning...

[prampec]

Please check latest commits in the main line. If everything is okay, I will create a new release.

[tomy983]

I think something went wrong..
after it calls this command: gsmAsync.addCommand("AT+CIPSHUT", 2000UL, false); (by the way... could it be possible to avoid to repeat for all the timeout time by putting it at the end?)

it looks like something went wrong..
Here the calls list in my function to connect to gprs:

        gsmAsync.addCommand("AT+CIPSHUT", 2000UL, false);                    // CIPSHUT will close *all* open connections
        gsmAsync.addCommand("AT+CGATT=0");                                   // Detach from GPRS
        gsmAsync.addCommand("AT+SAPBR=3,1,\"Contype\",\"GPRS\"");            // Set the connection type to GPRS
        gsmAsync.addCommand("AT+SAPBR=3,1,\"APN\",\"wap.postemobile.it\"");  // Set the APN
        gsmAsync.addCommand("AT+CGDCONT=1,\"IP\",\"apn\"");   // Define the PDP context
        gsmAsync.addCommand("AT+CGACT=1,1");                                 // Activate the PDP context
        gsmAsync.addCommand("AT+SAPBR=1,1");                                 // Open the definied GPRS bearer context
        gsmAsync.addCommand("AT+SAPBR=2,1");                                 // Query the GPRS bearer context status
        gsmAsync.addCommand("AT+CGATT=1");                                   // Attach to GPRS
        gsmAsync.addCommand("AT+CIPMUX=1");                                  // Set to multi-IP
        gsmAsync.addCommand("AT+CIPQSEND=1");                                // Put in "quick send" mode (thus no extra "Send OK")
        gsmAsync.addCommand("AT+CIPRXGET=1");                                // Set to get data manually
        gsmAsync.addCommand("AT+CSTT=\"apn\",\"\",\"\"");     // Start Task and Set APN, USER NAME, PWD
        gsmAsync.addCommand("AT+CIICR");                                     // Bring Up Wireless Connection with GPRS or CSD
        gsmAsync.addCommand("AT+CIFSR;E0");                                  // Get Local IP Address, only assigned after connection
        gsmAsync.addCommand("AT+CDNSCFG=\"8.8.8.8\",\"8.8.4.4\"");           // Configure Domain Name Server (DNS)
        gsmAsync.addCommand("AT+CGATT?");                                    // Check if gprs is connected

and this is the output with debug 3 active...

OK40.68 GSM OK
40.68 GSM CMD: AT+CIPSHUT

SHUT 
40.69 Calling handler for 'SHUT ' with argument 'OK'.
GPRS IS : SHUT

Requesting module status...
70.64 GSM Command[17] added: AT+CSQ
70.64 GSM Command[18] added: AT+CREG?
70.64 GSM Command[19] added: AT+CIPRXGET?
Requesting module status...
Requesting module status...
Requesting module status...
Requesting module status...

it looks like it is jumping... or skipping or not reporting to debug. either way, gprs does not connect.

I think it is still missing a way to retrieve the module answer of an answer with undefined response... Could those "ID" numbers be usable for that?

[prampec]

Yes. This will not work after all, as we don't know when to send the next command.
What about this? The next command will be executed after timeout ms was passed.

[tomy983]

I think that being asyncronous communication and also you have the possibility to set the timeout it could work.. not perfect but it could work.. Il Ven 29 Apr 2022, 23:51 Balázs Kelemen ***@***.***> ha scritto:

…

Yes. This will not work after all, as we don't know when to send the next command. What about this? The next command will be executed after timeout ms was passed. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2ZJ6S3BJRT4WUDVWCARNTVHRKVHANCNFSM5URQD52A> . You are receiving this because you authored the thread.Message ID: ***@***.***>