ESP8266 Library, call from a device not registered or wrong account

21

Yes, already wrote you!

22

did you tried tuning the timeouts I pointed out in the libraries?

The disruption is not between the device and the router for which you have implemented your timeout strategies.
The disruption occurs between the ISP and your servers anywhere in the meanders of the internet.
The TCP message is not successful, it will be resent by the ESP over and over.
IMHO, the messages to and from Thinger are not that critical to require the transmission integrity of TCP, UDP would have been largely enough and even more savvy to the device consumption, isn’t it?

23

You did. Using that email : noreply@community.thinger.io
A PM reply with this address will probably never reach you, right?

24

Those emails are automatically sent on on post responses. Wrote you again.

25

I still get only the “noreply” mail address
I can’t PM you that way.

26

The issue with the thing.handle() call taking 12 seconds to respond when the device is unknown or the credential wrong is really harmful upon using remote ESP8266 devices programmed over the air.

You just upload once the wrong device or the wrong Thinger credentials and then your device will not be remote accessible any more, being busy with 100% useless calls, having got no left time for OTA, and hence absolutely no chance to correct it, unless you go physically to the device and upload by USB.

That is really weird!

I have now found a workaround to overcome that problem:

byte GracePause;
long MillisMem;

// In loop, every second
  yield();
  if (GracePause) GracePause--;
  MillisMem = millis();
  if (not GracePause) thing.handle();               // do not call permanently Thinger if it takes too long to respond.
  if (millis() - MillisMem > 100) GracePause = 60;  // if the Thinger call took longer than 100mS, make 60s pause before retrying

That means, if the thing.handle(); takes longer than 100mS to execute, the sketch will pause the next thing.handle() calls for a minute, leaving enough “airtime” time to upload another sketch.

That prevents insane sketches to “hammer” your site as well.
Maybe you could include this kind of prevention in the thing.handle() call as well?

Regards,
Laszlo.

27

Hi @rin67630, the grace pause is a good idea for your use case, but still not convinced about establishing a threshold of 100ms just for that. As we have discussed before, there are plenty of possibilities this would happen, even in normal operation (and can drop your connection with the server or make it unresponsive during the pause). I suggest to improve your approach by setting the GracePause depending on the current device state. From this post: Check Cloud Connection on Arduino, you can currently monitor what is happening, i.e., if the credential is bad, or cannot connect to network. So, establish then the GracePause then. You can even improve the logic by stopping calling thing.handle() if the device cannot authenticate for more than x times, or your cannot connect to network more than y times, so, the device is completely available for OTA.

switch(state){
    case NETWORK_CONNECTING:
        break;
    case NETWORK_CONNECTED:
        break;
    case NETWORK_CONNECT_ERROR:
        // connect error. grace pause here?
        break;
    case SOCKET_CONNECTING:
        break;
    case SOCKET_CONNECTED:
        break;
    case SOCKET_CONNECTION_ERROR:
        break;
    case SOCKET_DISCONNECTED:
        break;
    case SOCKET_TIMEOUT:
        break;
    case THINGER_AUTHENTICATING:
        break;
    case THINGER_AUTHENTICATED:
        break;
    case THINGER_AUTH_FAILED:
        // bad credentials. grace pause here?
        break;
    case THINGER_STOP_REQUEST:
        break;
}
28

Could you give me a hint how to sense the connection state, without creating a new class?

ThingerESP8266::thinger_state_listener(THINGER_STATE byte t_state);
if (t_state == THINGER_AUTHENTICATED) thing.handle();

does not compile.
On the other side, does it make sense to call thing.handle(); if the state is not THINGER_AUTHENTICATED?
surely not, isn’t it?
Can’t you catch that directly at the call thing.handle(); function and return the call immediately with an error code?

29

Current version of the library does not support listening to events without creating a subclass. Next release will support it.

Yes, it is required to call handle, specially when the state is not THINGER_AUTHENTICATED, as it will handle starting the network connection, socket connection, authentication, and so on.

It would be possible to return a code in the thing.handle call, but one call may generate more than one “internal evet”, so, I prefer setting the state listener approach coming in the next release.