ESP32 disconnected

Hellow
Does anyone know if the ESP32s disconnect when putting a device_resource on a dashboard??
With buckets I have no problems

What do you mean with ā€œdisconnect when putting a device_resource on a dashboard?ā€
Of course, if you are plotting polled values, this happens only when your dashboard is active.
Buckets are the solution for permanent logging.

The problem is that the ESP32 appears in the console as disconnected but it really continues to send data to the Buckets ā€¦ but when it appears as disconnected the Device Resource is no longer shown in the dashboard

@ega Do you know what this error code is?

THINGER] Writing bytes: 919[E][ssl_client.cpp:36] _handle_error(): [send_ssl_data():301]: (-80) 
UNKNOWN ERROR CODE (0050)
 [FAIL]
[THINGER] Expected:919
[THINGER] Wrote:0

[_SOCKET] Connecting to xxxx.aws.thinger.io:25202...
[_SOCKET] Using secure TLS/SSL connection: yes
[_SOCKET] Connected!
[THINGER] Authenticating. User: XXXX Device: XXXXX
[THINGER] Writing bytes: 60 [OK]
[THINGER] Authenticated
[THINGER] Available bytes: 30

I can imagine that your code is writing to the buckets, but you are not invoking thing.handle(); fast enough.

Are you using the 2.17 thinger.io library?

Connection issues have been reported with ESP8266, with the same 25202 code you indicated. See the post Arduino Library 2.17.0

Hi,

Specifically I dont know that error

Can you share with us your sketch? because it is so weird, maybe what @rin67630 is happening, when the thing.handle function is not called so often it has weird behaviour.

Hi

The 25202 is the port which the connection is made, is the designated port into the cloud server to listen the incoming connections from devices, it is not an error code :wink:

Yes :frowning:
I think that may be the problem.
I call the function on every loop.
But the sketch also uses emelianovā€™s Modbus library and I think that when it loses the modbus connection it stays on standby

You can use both cores on esp32, one core dedicated to thinger and the other to the process that involves modbus, just need to be careful that avoid accessing memory on both cores simultaneously, you need to be sure that one will read/write at a time.

Hi @ega,
iā€™m affraid programming for both cores is bringing a LOT of problems for just sensing if thinger.io is available.
It is pretty risky to fiddle into the core where Espressif provides the basic communication stuff and you have to find ways to pass the all the variables needed.
One should surely have an easier solution.

Hi ā€¦ @ega @rin67630 :frowning: I have tried to get it to execute the task on Nucleo 0 and it is indeed very unstable
I have not succeeded, I think my knowledge is not that great

@rin67630 Do you have any effective way to control whether ESP32 is actually connected to Thinger.io? It would be worth it for me to have a way in case it disconnects to be able to do an ESp32.restart ().
This way I would avoid the problem of a crash

thanks

when it disconnects, it is very unlikely that the ESP is the cause.
One should be able to restart the router or -better- the crappy resources of our national champ internet provider :roll_eyes:

Hi,

If you want to detect the actual connection state, you may use the clientListener, check this:

As both cores on esp32 shares the memory, to use both cores on esp32 you need to apply semaphores, to control the access to the same resource (or many resources) by multiple process.

Hope this helps.

Hi @JAVIER_MARIN, check this:

And you can get rid of the header files just calling disableCore0WDT(); into setup.

To access the variables on both cores without issues i would use a semaphore with a boolean variable, and would use another set of variables, something like this:

Modbus core:

if (semaphore ==0){
//Dump the modbus variable into the extra variable set
semaphore = 1;
}

Thinger ā€œthingā€:

if (semaphore ==1){
// you can define the resources here, aiming to the extra var set
semaphore = 0;
}

In this way the modbus wont update the variables if the thinger process havenā€™t read the resources, and thinger wont read the resources if the modbus havenā€™t updated it, itā€™s a basic way to warantee that just one process will access the extra var set.

Try it and donā€™t stop improving your knowledge :wink:

Hope this helps.

1 Like

I have tried to use this method and have derived this one:

class RefreshThinger : public ThingerESP32 {
  public:
    RefreshThinger(const char* user, const char* device, const char* device_credential) :
      ThingerESP32(user, device, device_credential) {}
  protected:
    virtual void thinger_state_listener(THINGER_STATE state) {
      // call current implementation (debug)
      ThingerESP32::thinger_state_listener(state);
      if (state) thing.handle();
    }
};

and replace in loop()

thing.handle();
by
RefreshThinger thing(THINGER_USERNAME, THINGER_DEVICE, THINGER_DEVICE_CREDENTIALS);
Which should run
thing.handle();
if the connection is acknowledged.
But then my device does not show up in thinger.io any moreā€¦

I canā€™t interpretate what specific does your code, but if you are waiting the connection acknowledged to call the ā€˜thing.handle();ā€™ instruction, it wont work because that command is the one that tries the connection.

Regarding the clientListener what I would suggest is to try the connection just once, if it doesnā€™t get it (by any reason), stop the thinger process and call it again in (ie) one minute, be careful to call the stop thinger routine in the right places, as the connection handles many states and not all of them means a connection fail.

Hope this helps.

So one need to run a
thing.handle();
to get the THINGER_STATE?
Then I can just ask millis().
If the
thing.handle();
takes more than 20mS, then something is wrong and i can stop running it a a one second pace.
maybe wait 5 minutes and try againā€¦
Anyhow, it is necessary to catch the exception since else the ESP gets practically unresponsive.

Yes.

I think you can try with the states of the clientListener, as basically the ESP gets in the thinger process until it gets connected, but detecting the connection issue and getting out of that process could be a solution for your situation.

Hope this helps.

Is there a list of the states from the STATE_LISTENER?
Can one differentiate between

  • Device not recognized
  • User not known
  • Wrong credentials
  • No response from the server?

Of course, check carefully the link that Iā€™ve made reference.