ESP32 disconnected

[ega]

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.

[ega]

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

[JAVIER_MARIN]

Yes
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

[ega]

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.

[rin67630]

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.

[JAVIER_MARIN]

Hi … @ega @rin67630 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

[rin67630]

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

[ega]

Hi,

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

Local exception handling of Wi-Fi connection issues

I’m trying to have my device (ESP32) become aware of when its Wi-Fi connection drops, and take some action when it’s the case: e.g. light a LED to indicate temporary disfunction. Basic exception handling basically. What is the best approach to doing this? The handle method returns void. I suppose I could create a dummy Endpoint and ping it from the loop block at periodic intervals, but that seems like overkill.

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.

[ega]

Hi @JAVIER_MARIN, check this:

Multitasking... REAL multitasking with esp32

Hi fellows, I was digging on internet and fortunately found the way how to use both cores of esp32. Why? because when the device doesn’t get connected… It keeps trying to, and doesn’t do anything else, of course it can be sorted modifying the library, but always it will loss control time when tries to communicate, due it have to wait network answers or timeouts. So as this little asskicker has two cores, is perfect for this, because one can be dedicated to communicate (or try to from here to e…

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

Hope this helps.

[rin67630]

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…

[ega]

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.

[rin67630]

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.

[ega]

@rin67630

So one need to run a
thing.handle();
to get the THINGER_STATE?

Yes.

@rin67630

Anyhow, it is necessary to catch the exception since else the ESP gets practically unresponsive.

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.

[rin67630]

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?

[ega]

Of course, check carefully the link that I’ve made reference.

[rin67630]

Nothing was there to find.
In the source code I found:
enum THINGER_STATE{
NETWORK_CONNECTING,
NETWORK_CONNECTED,
NETWORK_CONNECT_ERROR,
SOCKET_CONNECTING,
SOCKET_CONNECTED,
SOCKET_CONNECTION_ERROR,
SOCKET_DISCONNECTED,
SOCKET_TIMEOUT,
SOCKET_ERROR,
THINGER_AUTHENTICATING,
THINGER_AUTHENTICATED,
THINGER_AUTH_FAILED,
THINGER_STOP_REQUEST
};
Which could be the answer, so
THINGER_AUTH_FAILED, could be the status for wrong credentials and

SOCKET_CONNECTION_ERROR, the status for Thinger server not reachable
or is
SOCKET_TIMEOUT the better status for it?

NETWORK_CONNECT_ERROR, the status for Internet not available?

Is there a way to detect “device not recognized”?

[ega]

@rin67630

Nothing was there to find.

Yes, there is a link into the post that I’ve made reference, that link has a post with all the states, didn’t you see it?

I honestly dont know if I understand what specific you want to do, I have the idea that you want your device to know if the thinger service is reachable to avoid keep it stuck trying to connect, and try again in 5 mins (ie), said that, any error state will give the proof that it is not and should set the flag to avoid calling the thinger process in the next 5 mins.

If you are so kind to explain what specific want to do would be helpful to understand and evaluate if it is feasible right now with the available features.

Hope this helps.

[rin67630]

• Internet hot available is one possibilty.
• Server Not reachable is another possibilty.
• Bad credentials is another one and
• No corresponding device known at server side a fourth reason

It would have been good to know what has caused the malfunctionning of the Thinger.io connection to guide the user in order to fix it.

[ega]

Yes I understand that could be by many reasons why the device does not connect, but my point is that the device does not care where is the issue, what it will do is, by any error, stop trying to connect and try again later, to avoid keep stuck and work on other processes.

What could be helpful is that the device has the capability to inform locally to the end user what’s going on, by a LCD or a led blinking pattern (by somehow without the serial port need), so the end user may know and solve (or try to) the situation.

[rin67630]

What could be helpful is that the device has the capability to inform locally to the end user what’s going on

Exactly!
LCD is present.