Implement a function to get the state of state_listener_
Implement a get_state_listener() function
The state_listener_ variable can store several different states, it would be interesting to have a function to get the current corresponding state on the Device.
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_AUTH_FAILED,
THINGER_STOP_REQUEST
};
This function can help to implement some functionality like:
If state_listener is equal to NETWORK_CONNECT_ERROR, then blink YELLOW LED;
If state_listener is equal to SOCKET_ERROR or THINGER_AUTH_FAILED, then blink RED LED;
If state_listener is equal to THINGER_AUTHENTICATEDor THINGER_AUTH_FAILED, then blink GREEN LED;
Hi @alvarolb
Is it feasible to implement this feature? If not, we will try another alternative.
Why don’t you use the state listener? That way, you don’t need to poll the value in every loop — it just gets called once the state changes.
https://docs.thinger.io/coding-guide#listen-for-connection-state
void setup(){
// your setup code here..
thing.set_state_listener([&](ThingerClient::THINGER_STATE state){
switch(state){
case ThingerClient::NETWORK_CONNECTING:
break;
case ThingerClient::NETWORK_CONNECTED:
break;
case ThingerClient::NETWORK_CONNECT_ERROR:
break;
case ThingerClient::SOCKET_CONNECTING:
break;
case ThingerClient::SOCKET_CONNECTED:
break;
case ThingerClient::SOCKET_CONNECTION_ERROR:
break;
case ThingerClient::SOCKET_DISCONNECTED:
break;
case ThingerClient::SOCKET_ERROR:
break;
case ThingerClient::SOCKET_TIMEOUT:
break;
case ThingerClient::THINGER_AUTHENTICATING:
break;
case ThingerClient::THINGER_AUTHENTICATED:
break;
case ThingerClient::THINGER_AUTH_FAILED:
break;
case ThingerClient::THINGER_STOP_REQUEST:
break;
}
});
}
This was the alternative solution we developed. We created a variable to capture this state.
But we believe that a get function would be more appropriate, especially because it could already contain code to avoid conflicts between threads when using FreeRTOS.
In other words, the function, in addition to returning the current state, could implement an approach that prevents conflicts between threads when using FreeRTOS.
What do you think?