Apparently, their attention is focused on the big customers with high volume of devices. And small customers, who don’t have the resources or technical knowledge to work around these bugs, may not be the priority right now.
Do you have 1500 devices to register on the Thinger.io platform? If yes, maybe they will answer your question.
You know what’s interesting, how can you implement 1500 products in several customers’ homes without a resource like ThingerWebConfig.h that uses WiFiManager to get the SSIDs and passwords of the router/modems? You won’t. WiFiManager is the only implementation that helps you with this.
Soon, you can even register the 1500 products on the Thinger.io platform, but you can’t make it possible to install them in the customer’s home. Isn’t it great!?
That’s why we’ve been here for months asking for bugs in ThingerWebConfig.h to be fixed and for ESP-32 compatibility to be implemented.
I consider ThingerWebConfig.h the main functionality of the Arduino-Thinger library, because only it has flexibility and allows the subsequent registration of SSIDs and router/modem passwords on the devices.
Only Make users know the SSIDs and passwords of router/modems in advance and can register them in the code.
Companies do not know their customers’ SSIDs and passwords in advance, so they need to use ThingerWebConfig.h/WiFiManager.
Curious, how easy it is to understand, no?
It seems that only Thinger.io platform users identify this “problem”.