Closed ortegafernando closed 4 years ago
256dpi
commented
4 years ago The lastError: -6 (LWMQTT_NETWORK_FAILED_WRITE) indicates that there was an issue while writing something. Since you're printing the error after client->connected() we do not know which call caused the error. Most methods return a boolean to indicate the calls success. If it failed you should check lastError immediately and print it. Then we know which call was not successful.
Teddyz
commented
4 years ago It might be obvious, but it would be great if you could add in the documentation or in an example if 1 means sent OK or if 0 means "No Error".
Is it possible to get the error-texts from the library? (Or would that consume a lot of ram?)
256dpi
commented
4 years ago In all cases true means success. I updated the docs accordingly.
I'm playing with the idea of adding a client.debug() function that prints information about whats going on under the hood. But this will consume a lot of bytes for the strings, so I'm not sure what's the best strategy here. Any ideas?
Teddyz
commented
4 years ago I saw this that might be a good approach:
The code, in WiFiClientSecureBearSSL.cpp, seems simple (I omitted most of the cases):
// Returns an error ID and possibly a string (if dest != null) of the last
// BearSSL reported error.
int WiFiClientSecure::getLastSSLError(char *dest, size_t len) {
int err = 0;
const char *t = PSTR("OK");
if (_sc || _sc_svr) {
err = br_ssl_engine_last_error(_eng);
}
if (_oom_err) {
err = -1000;
}
switch (err) {
case -1000: t = PSTR("Unable to allocate memory for SSL structures and buffers."); break;
case BR_ERR_BAD_PARAM: t = PSTR("Caller-provided parameter is incorrect."); break;
case BR_ERR_BAD_STATE: t = PSTR("Operation requested by the caller cannot be applied with the current context state (e.g. reading data while outgoing data is waiting to be sent)."); break;
case BR_ERR_OVERSIZED_ID: t = PSTR("ServerHello contains a session ID which is larger than 32 bytes."); break;
case BR_ERR_BAD_CIPHER_SUITE: t = PSTR("Server wants to use a cipher suite that we did not claim to support. This is also reported if we tried to advertise a cipher suite that we do not support."); break;
case BR_ERR_X509_DN_MISMATCH: t = PSTR("Issuer/Subject DN mismatch in the chain."); break;
case BR_ERR_X509_WEAK_PUBLIC_KEY: t = PSTR("Public key found in certificate is too small."); break;
case BR_ERR_X509_NOT_TRUSTED: t = PSTR("Chain could not be linked to a trust anchor."); break;
default: t = PSTR("Unknown error code."); break;
}
if (dest) {
strncpy_P(dest, t, len);
dest[len - 1] = 0;
}
return err;
}`
ortegafernando
commented
4 years ago Hi, I have been doing some test.
With these options: mqtt.setOptions(10, true, 15000);
(I was used to 2400 in my old GSM SIM800 library, with TinyGSM it seems that it is better 4800)
So I will close this issue, but first: what about this?:
May be in future I will try AltSoftSerial or NeoICserial or NeoSWserial. Does anybody try them? Worth it over software serial?
Thanks.
HI, I go on checking this great library. Now I have checked to publish a msg every 60 seconds (Vcc), and compare with pubsubclient (just in case).
I get an strange behaviour with arduino-mqtt and I don't know where I have to start or continue with the debuging process.
My configuration is an Arduino Pro Mini + SIM800L + TinyGSM library. Suscribe and publish are QOS 0. And node red is also conifgured with QOS 0 Node red sends timestamp to swtich on/off led. Ardunio Pro Mini sends Vcc to nodered every minute.
This is my sketch (it is almost the usual example). As you could see I have already increased buffer to 256 (just in case, because with 128 has to be enough). Also I am using F("") in string to increase free ram in arduino (just in case)
Summary: 3 test and 3 logs
pubsubclient: In this case I left the arduino to do its job. Send Vcc every minute. As you can see I get more than 4 msg with Vcc data. So everything is Ok See these seconds: 59: Vcc 122: Vcc 185: Vcc
pubsubclient: In this case, I also send msg (timestamp) from Node red to arduino to switch on/off the led. Meanwhile, arduino is sending Vcc data. Everything is Ok. See these seconds. 59: Vcc 69: switch on/off led 86: switch on/off led 92: switch on/off led 120: switch on/off led 122: Vcc
arduino-mqtt library: here we have a big log to test everything. It is a very long log but I will split it in three parts 3.1 first part is to see how MQTT disconnect after the second Vcc message. See these seconds: 59: Vcc 122: Vcc 125: MQTT DISCONNECT 185: Vcc 248: Vcc 251: MQTT DISCONNECT
3.2 second part is to see what happens when we send from Node Red a message to switch on/off the led. If we stop sending msg from node red, after the second Vcc data in a row, MQTT IS DISCONNECTED again. (see part 3.3) See these seconds: ----- end of part 3.1 and start of part 3.2 ------ 259: switch on/off led 265: switch on/off led 311: Vcc 373: Vcc 377: MQTT DISCONNECT 437: Vcc 445: switch on/off led 456: switch on/off led 468: switch on/off led 474: switch on/off led 500: Vcc 562: Vcc 566: MQTT DISCONNECT
3.3 I f we send a node red msg every time I get Vcc data, MQTT DON'T disconnect. But if we dont send anything from Nodered, after two Vcc msg in a row --> MQTT DISCONNECTs. See these seconds: ----- end of part 3.2 and start of part 3.3 ------ 625: Vcc 634: switch on/off led 688: Vcc 696: switch on/off led 751: Vcc 757: switch on/off led 814: Vcc 867: Vcc 879: MQTT DISCONNECT
I am getting crazy.
NOTE: I have add a serial.println in TinyGSM library to see the buffer. You can see it in "vertical" lines. First line is "BUFFER:". Long ones is timestamp sent from node red. But buffer is only 27 chars at most.
And now I will publish 3 logs (both serial log and node red log):
pubsubclient: In this case I left the arduino to do its job. Send Vcc every minute. As you can see I get more than 4 msg with Vcc data. So everything is Ok
pubsubclient: In this case, I also send msg (timestamp) from Node red to arduino to switch on/off the led. Meanwhile, arduino is sending Vcc data. Everything is Ok.
arduino-mqtt library: here we have a big log to test everything. It is a very long log but I will split it in three parts 3.1 first part is to see how MQTT disconnect after the second Vcc message. 3.2 second part is to see what happens when we send from Node Red a message to switch on/off the led. If we stop sending msg from node red, after the second Vcc data in a row, MQTT IS DISCONNECTED again. (see part 3.3) 3.3 I f we send a node red msg every time I get Vcc data, MQTT DON'T disconnect. But if we dont send anything from Nodered, after two Vcc msg in a row --> MQTT DISCONNECTs.
I am getting crazy. it is a very strange behaviour. May be I have done something wrong in my sketch? Where or how could I go on debuging?
Thanks
NOTE: In order not to waste a lot of time reading logs, you can find in the begging of each part the "timings" in where are interested things as Vcc data, nodered msg recieved, MQTT disconnects .... (I wil write seeconds, remember that logs are in "[millis()]")
See these seconds: 59: Vcc 122: Vcc 185: Vcc
See these seconds. 59: Vcc 69: switch on/off led 86: switch on/off led 92: switch on/off led 120: switch on/off led 122: Vcc
See these seconds: 59: Vcc 122: Vcc 125: MQTT DISCONNECT 185: Vcc 248: Vcc 251: MQTT DISCONNECT
3.2 second part is to see what happens when we send from Node Red a message to switch on/off the led. If we stop sending msg from node red, after the second Vcc data in a row, MQTT IS DISCONNECTED again. (see part 3.3)
See these seconds: 59: Vcc 122: Vcc 125: MQTT DISCONNECT 185: Vcc 248: Vcc 251: MQTT DISCONNECT ----- end of part 3.1 and start of part 3.2 ------ 259: switch on/off led 265: switch on/off led 311: Vcc 373: Vcc 377: MQTT DISCONNECT 437: Vcc 445: switch on/off led 456: switch on/off led 468: switch on/off led 474: switch on/off led 500: Vcc 562: Vcc 566: MQTT DISCONNECT
3.3 I f we send a node red msg every time I get Vcc data, MQTT DON'T disconnect. But if we dont send anything from Nodered, after two Vcc msg in a row --> MQTT DISCONNECTs.
It is VERY VERY STRANGE, isn't it ? ;)
See these seconds: 59: Vcc 122: Vcc 125: MQTT DISCONNECT 185: Vcc 248: Vcc 251: MQTT DISCONNECT ----- end of part 3.1 and start of part 3.2 ------ 259: switch on/off led 265: switch on/off led 311: Vcc 373: Vcc 377: MQTT DISCONNECT 437: Vcc 445: switch on/off led 456: switch on/off led 468: switch on/off led 474: switch on/off led 500: Vcc 562: Vcc 566: MQTT DISCONNECT ----- end of part 3.2 and start of part 3.3 ------ 625: Vcc 634: switch on/off led 688: Vcc 696: switch on/off led 751: Vcc 757: switch on/off led 814: Vcc 867: Vcc 879: MQTT DISCONNECT