Thanks for your comments @rin67630, glad to know you find it useful!
We will add a plugin for private instances where devices can be reach directly over SSH terminal
I’m still having TLS/SSL problem when using Arduino Library Thinger version 2.21.1 (As reported in this post). I tested it with “iot.thinger.io” and on my private Thinger Cloud instance. If #define _DISABLE_TLS_ , the device connects successfully. ClientListener + ThingerWebConfig + framework-arduinoespressif8266 3.30002.0 (3.0.2 ) + <thinger.io> 2.21.1 + WifiManager 2.0.3-alpha+sha.9af7253 :
Ping Public Thinger:
Ping Private Thinger (Location: Virginia, USA):
Everything works fine with Arduino Library Thinger 2.16.0: The error does not occur if you use ClientListener + ThingerWebConfig + espressif8266@2.6.2(Arduino-Framework 2.7.4 ) + thinge
r.io@2.16.0 + WifiManager 2.0.3-alpha+sha.9af7253
A question: Was there an evolution in the IOTMP protocol between versions 2.17 to 2.21.1? I read about it in some posts (link) and saw some commits on github (link1, link2).
Has the way of declaring ClientListener changed too?
Hi Alvarolb,
I think it is a very useful feature especially for remote diagnostics.
I have set it up on an ESP32 and connected to it using the Terminal, but as soon as the ESP32 prints anything to the console the processor disconnects. Had to disable the line of code that contained console.println and processor was then able to stay connected.
I also have OTA installed on the same ESP32 and that works perfectly, but obviously not when the processor is disconnected.
Hi, the IOTMP Protocol has not been released yet. It is being tested internally with some of our clients. We expect to fully release it before the year ending.
But yes, we have included a new method for getting updates from Thinger.io client in the Arduino libraries, so, it is not required to create a subclass anymore. For example:
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;
}
});
I will run tests and send feedbacks. Thank you very much for constantly updating the Thinger ecosystem. And thanks for your attention here in the community.
Hello @alvarolb
I keep having problems with TLS encryption in version 2.21.1 of the library… Updated code for thing.set_state_listener([&]ThingerClient::THINGER_STATE state)
The device can only connect if #define _DISABLE_TLS_
I tested it on Thinger Public and at my private instance.
The problem with TSL (ThingerWebConfig + ClientListener + framework-arduinoespressif8266 3.30002.0 (3.0.2 ) + <thinger.io> 2.21.1 + WifiManager 2.0.3-alpha+sha.9af7253 ) can be solved with some code change , or is it a bug in Arduino Library 2.21.1 or Thinger.io Server version 3.3.3?
We are about to release some products and we are unsure whether to use it with Arduino Library 2.16.0 or wait for the next version of Arduino Library.
A report follows:
NOTE: My Time Zone is UTC -03:00 (I ran the test at 17h (UTC -03:00), but the UTC considered by the Arduino-Thinger run was at 20h (UTC 00:00))
Apparently the error with TLS occurs with the Thinger.io public server and the private server when using <ThingerWebConfig.h>.
I have found that using the latest WiFiManager from github (2.0.4-beta+sha.9d061ab) it can connect with TLS, but it gets unstable (see screenshot below).
Public Thinger.io + Arduino Library 2.21.1 ( <ThingerESP8266.h> and <ThingerESP8266OTA.h> )
I think I’ve identified the problem. But I think you already know.
I’m not a Computer Technician. I’m just a Maker.
I’m sorry if I say something stupid.
While reviewing the ThingerESP8266.h and ThingerWebConfig.h files, I identified that ThingerWebConfig was not suitable for the SSL/TSL changes made after version 2.16 of the Arduino-Thinger library.
NOTE: My timezone is -03:00.
NOTE2: I was able to connect to my private instance (which has the timezone -04:00 - Virginia, USA). But I couldn’t connect to the Public Thinger: iot.thinger.io
I made some impromptu changes to the ThingerWebConfig.h file and was able to connect. Basically:
Added the <time.h> library;
Added the setClock() function;
Updated the code of the connect_socket() function
**(See that I removed / commented the code from line 152 to 154)
I added the setClock() function inside the connect_network() function (it’s not correct, but it worked.)
I removed the “virtual” from the network_connected() and connect_network() functions
However, as I’m not an expert, I don’t know if it’s the correct way to update the ThingerWebConfig.h code.
I think this update is easy to do. Are there any plans to update the Arduino-Thinger library? We would love to use OTA functionality on our devices that use the ThingerWebConfig.h library.
Any predictions for an Arduino-Thinger library update, in particular the adaptation of ThingerWebConfig.h to the new Thinger Server encryption standard?
We even pointed out that code change, but we don’t know if it’s the right change to make. We are afraid to apply our solution and generate some incompatibility with future updates of ServerThinger.
Also, is there any prediction of compatibility of ThingerWebConfig.h with ESP32? From what I checked in the WiFiManager library repository, compatibility with ESP32 has already been implemented.
We are looking forward to these updates as we chose the Thinger.io service especially because of the availability of the Arduino-Thinger library. For us, the Arduino-Thinger library sets Thinger.io apart from its competitors.
With the modifications indicated in the post above, I was able to connect to the Private Thinger Server.
As for the update process via OTA, I performed initial tests. With a basic example, I managed to perform the update via OTA after about 20 attempts. Many attempts occurred error in the middle of the update process, as in the image below:
I don’t know if it’s something related to the Arduino-Library library, the Thinger extension for VS Code, to my computer, to the size of the firmware… it’s still a mystery, I don’t know why I can’t update via OTA with my device code. I’ve only had success with the simple test code.
AboutThingerTinyGSM.h (GSM):
In a period of 20 hours, I identified that the device was restarted about 8 times. I don’t know for a bug in the code of ThingerTinyGSM.h, or if it was a command defined in the library.
Reset occurs when “[THINGER] Writing bytes: 2 [FAIL]”. See screen below:
Hi @George_Santiago, right now we are releasing a new BETA server which includes some features requested by some clientes (hopefully these features are interesting for you also). Will provide information about this new version soon, probably this week
This let us take some time to review the community and the different features and changes you are detailing. Can you please write me a PM or a document, summarizing all the problems/needs you have (in order of importance), i.e., with the links to the community, or just copy/paste the details? Sure we can fix some of them!
Hello, I have identified a bug in the 2.21.1 library. In library 2.16.0 everything worked correctly.
ESP8266 is unable to reconnect to the Thinger Server after the modem/router is without internet for a moment.
The same occurs if the modem/router turns off for a moment.
Test with <ThingerESP8266.h> and <ThingerWebConfig.h>:
Connect the device to the WiFi router/modem;
Wait for the device to connect to the Thinger Server successfully.
Remove the internet cable from the WiFi router/modem until the device reports the loss of connection;
Connect the internet cable to the WiFi router/modem;
The device is unable to connect to the Thinger Server again.
The same happens if you turn off the WiFi router/modem for a few minutes, and then turn it on again. The device is unable to connect to the Thinger Server.
This did not happen with the 2.16.0 library. With it, the device reconnected with the Thinger Server when simulating the internet drop or the WiFi router/modem shutdown.
See the image below:
Red Arrow: 1 minute after removing the internet cable from the WiFi router/modem, the device reports “Timeout”.
Blue Arrow: I re-plug the internet cable from the WiFi router/modem, but the device cannot connect to the Thinger Server.
Test by turning off and on the WiFi router/modem:
Green Arrow: Moment when the WiFi router/modem is turned off.
Pink Arrow: Device connects to WiFi router/modem, but fails to reconnect to Thinger Server.