Ubidots causing SOS+1 (hard_fault) on v1.1.0

Firmware Libraries
1

Hi there,

I am having an issue when sending variables to Ubidots via HTTP and/or TCP, this is with the latest release of v1.1.0 .

Similar as mentioned here by ScruffRPreformatted text

The system which consist of 5 Xenons and 1 Boron (2G/3G) is working fine with the Particle Console, publishing the information requested.

My problem is that as soon as I get the information from the Xenons, and try to add the variables to Ubidots, then it crashes with a hard_fault Panic (SOS+1).

I have spent the last 3 days trying to figure out a way to solve the problem, but I can’t find a way to solve this issue. Does anyone else have the same problem ?

I mean, if everything is working fine with the Particle Console, I don’t see why it can’t be passed to the Ubidots variables.

Please find below the code that is failing.

void SendUbidots() {
    
    Particle.publish("Ubidots", "Sending Info Ubidots",  PRIVATE);
    
    if(mensaje == 0){
            
            const char * device_type = "device"; // Edit here your device type label 
            char * device_setup = (char *) malloc(sizeof(char) * 30);
            sprintf(device_setup, "%s/?type=%s", (const char*)device, device_type);


            ubidots1.add("x", x_axis);  
            ubidots1.add("y", y_axis);  
            ubidots1.add("z", z_axis);  
            ubidots1.add("volts", voltage);
            ubidots1.add("temp", temp);
            ubidots1.add("msg", mensaje);
            
            ubidots1.send(device_setup);

        }
        else if(mensaje == 1){

            ubidots.add("volts", voltage);
            ubidots.add("temp", temp);
            ubidots.add("msg", mensaje);
            
            ubidots.send((const char*)device);  
            
        }
        
    
}

@jotathebest @mariahernandez

2

Hello @mr_3r, thansk for your message. I need some additional information to debug the issue, what library version are actually you using? Also, can you share both constructors for the instances of ubidots and ubidots1? Also, I see that the char array device_type is not free, so I advise you to free that piece of memory. Is there any problem if you share your entire code? maybe in a private link to my inbox, in that way you make easier for me to debug any possible issue with the library.

I will be attentive to your answer

3

I have tried the library example
https://build.particle.io/libs/Ubidots/3.1.1/tab/example/SendValuesParticleWebhook.cpp

as is on Argon 1.1.0 and the first call to any ubidots function causes the hard fault.

BTW, it would be good when the functions (including the constructor) that take strings (char*) would rather take const char* unless they actually need to modify the string.

4

@jotathebest

I have sent you the information requested. In addition, I would like to mention that I have the next libraries loaded, JsonParserGeneratorRK Version 0.0.6 and Ubidots 3.1.1

As for the constructor please find it below.

Ubidots ubidots1(UBIDOTS_TOKEN, UBI_HTTP); // only for the first connection to setup the device type
Ubidots ubidots(UBIDOTS_TOKEN, UBI_TCP);

@ScruffR as you mentioned in your previous post, I will not modify this string since it’s part of the device setup on Ubidots. and it doesn’t change over time.

Thanks!

5

@mr_3r, that statement about const char* was directed at @jotathebest rather.
The constructor should expect a const char* since it is not supposed to modify that string.
With the current implementation (char*) the compiler will barf with a call like this

const char* ubiToken = "someToken";
Ubidots ubidots1(ubiToken, UBI_HTTP);

To make that code build, one would have to cast away the const modifier like this

Ubidots ubidots1((char*)ubiToken, UBI_HTTP); // don't force a const into mutable!!!

and this can be considered poor style on the caller and on the library side.

If indeed a mutable string was required, then a #define UBIDOTS_TOKEN or for that a string literal would have to be forbidden too.

6

Hi @jotathebest,
Anything yet on this matter?
Please confirm at your earliest convenience, since I need to know if Ubidots can support the project I am trying to roll out with the boron & mesh devices.

7

@jotathebest, I ran into this same crashing issue yesterday when using example code. As soon as I call the Ubidots “add” function, my Boron crashes.

8

Greetings @mr_3r, @nathan43082, today I released a patch related with a panic coming from Argon devices once you try to use them not as gateway but as a normal node. This patch seems to be related with some compile flags that I was using in the library that throws a panic SOS with Mesh devices using the firmware version 1.1.0.

@mr_3r I think that this may solve the issue reported by you, but I have not tested the patch with your code yet, I will test it with tomorrow but if you have any available time now please try it let me know if you still experience the issue at your side.

All the best

9

Thank you for looking into this. I am finished for the day, but will take a look at it sometime tomorrow.

10

I just reloaded the latest version 3.1.2 and it is working like a charm !

Thank you Jota! :call_me_hand:

11

@jotathebest, thanks for looking into this. It seems to be working well now, but I have a question about the number of attempts at the beginning. Is it normal for it to take a few attempts at first before it gets into a groove of sorts? If I let it run for a while after this, it almost never takes more than one attempt every five seconds using the example code. But that first one seems to hiccup quite a bit. Btw, I switched to using a Particle webhook to send the data, and it still works fine.

----------
payload:
{"Variable_Name_One":{"value":376},"Variable_Name_Two":{"value":355},"Variable_Name_Three":{"value":425}}
----------
Sending data...
Trying to connect to industrial.api.ubidots.com , attempt number: 0
Attempt finished
Trying to connect to industrial.api.ubidots.com , attempt number: 1
Attempt finished
Trying to connect to industrial.api.ubidots.com , attempt number: 2
Attempt finished
Trying to connect to industrial.api.ubidots.com , attempt number: 3
Attempt finished
Trying to connect to industrial.api.ubidots.com , attempt number: 4
Attempt finished
Could not send data to ubidots using HTTP
----------
payload:
{"Variable_Name_One":{"value":264},"Variable_Name_Two":{"value":237},"Variable_Name_Three":{"value":273}}
----------
Sending data...
Trying to connect to industrial.api.ubidots.com , attempt number: 0
Attempt finished
Trying to connect to industrial.api.ubidots.com , attempt number: 1
Attempt finished
Making request to Ubidots:
POST /api/v1.6/devices/************************ HTTP/1.1
Host: industrial.api.ubidots.com
User-Agent: UbidotsParticle/3.1
X-Auth-Token: ************************************************
Connection: close
Content-Type: application/json
Content-Length: 105
{"Variable_Name_One":{"value":264},"Variable_Name_Two":{"value":237},"Variable_Name_Three":{"value":273}}
waiting for server answer ...
Ubidots Server response:
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 05 Jun 2019 12:36:34 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: close
Allow: GET, POST, HEAD, OPTIONS
Vary: Origin, Cookie
12

Hi @nathan43082, I am not sure if it is ‘normal’ or not, at my side I can connect without problems at the first attempt. The routine for sending data basically uses the Particle TCP connect method, and up to five attempts to create a socket with the server are implemented spaced with a delay of one second:

void UbiHTTP::reconnect(const char* host, const int port) {
  uint8_t attempts = 0;
  while (!_client_http_ubi.connected() && attempts < _maxReconnectAttempts) {
    if (_debug) {
      Serial.print("Trying to connect to ");
      Serial.print(host);
      Serial.print(" , attempt number: ");
      Serial.println(attempts);
    }
    _client_http_ubi.connect(host, port);
    if (_debug) {
      Serial.println("Attempt finished");
    }
    attempts += 1;
    delay(1000);
  }
}

My advise is to give a try in another location to discard any issue related with WiFi or GPRS signal strength.

All the best

13

@jotathebest, I switched it over to using the webhook calling method via Particle, so the timeouts became a moot point. Thanks for responding, though.