Configuring a device to match Thinger is a hurdle.
Upon loading a given program to several devices you need a procedure to adjust the device name/credentials and that takes resources on the device and is a diverting step from the regular workflow.
What do you think about an Thinger-triggered autoconfiguration based on the MAC address?
Unconfigured devices would globally advertise their MAC address on thinger.io. (This would not yet activate any registration)
When the user creates the device at thinger.io, he could enter the MAC address and this would proceed to a one-time initial upload of the credentials onto the device, without needing to fiddle on the device side.
Hi @rin67630, device auto provisioning is a next-step for Thinger.io to scale large deployments. We started thinking on it some years ago, but we haven’t a clear path yet for WiFi/Ethernet devices (LPWAN devices is another history and it is currently solved). We have some on-progress designs but highly relies on a certain microcontroller, like ESP32. Maybe you can remember the ESP32 Core repository we created some years ago…
To not enter in too much detail here, I can make you some questions to help understand the complexity to make it useful and secure:
How can we trust that the MAC id is unique and legitime? Specially when many IoT devices allows programing the MAC address.
When the user claims a certain MAC, how can be sure that the device belongs to this user and it is not a bot trying to register random MACs?
To answer your questions:
One should have a combination of compilation-set password (that can be common to all devices of an account) or could be last byte of the IP address) and the MAC address.
Normally you get this info from the router once the WiFi is configured
That combination should be unique.
It should only be active and relevant to the server as long as the device is not paired.
Once paired the credentials are the usual ones and the MAC is irrelevant.
Of course if your server gets dozens of unsuccessful pairing attempts, it should blacklist that account for a while.
But that is just my 2 cents… I am happy with the current stage a well.
I think having a common password for a bunch of devices is a step back, I guess that with a combination of a developer field (a kind of “type” device), and the mac address could be generated the “device” field, and an algorithm that generates a “password” (based on the type and mac address) could work, so the cloud may validate if the device and password correspond to a valid combination when there is a auth fail, and set it up or ignore it.
The IP idea could work too, and the probability that two devices gets the same number from the IP are pretty lower, but it tangles a little bit the things, as it is a dynamic value, it is needed to store into the device the first IP value acquired to generate the device ID.
The common password or the lower IP byte would just be for the initial pairing phase.
Just to reduce the hijacking risk. The MAC and the IP are shown by most of the routers.
The lower IP byte is already in the device once paired with WiFi.
So the procedure is
a) pair with WiFi e.g. over any usual method. (The device begins to advertise its readiness to Thinger sending its MAC+lower IP (or Password)
b) User reads the MAC + lower byte from the router
c) User goes to thinger, prepares a new device, enters the device name/credentials as usual
d) activates autoconf; enter MAC + lower byte.
e) if matching the advertised data, the usual Thinger credentials are pushed by the thinger server then only these are ruling, the above data won’t be used any more.
Then it becomes a regular Thinger.io client, So if the IP change afterwards, that will not impact the connection.
If the user should get the device name/credentials, to set up a new one at the cloud… Why don’t set it up with finals values? I see it as the current webconfig with extra steps, and it’s needed to store the values in the device’s non volatile memory, those values can’t be generated automatically by the device, nor hard coded.
As the way that you are suggesting, I see that every single end user that needs to deploy a new device must have the permission to create new devices at the cloud, even when the self configuring will create all the other resources, I think not all users should have this permission granted by default, nor the admin should manage it eventually or from time to time.
I’m thinking the idea where the devices can get the connection without interaction from the end user fill some fields (SSID, WiFiPassword, project?) just to connect the device, and everything else is done by “magic” in node-red, the buckets setup, dashboards setup and projects setup.
The wifi manager is a standard for ESP devices, but it cannot setup thinger credentials.
Also a device that has got a first connection will keep the Wifi credentials even without a wifi manager.
Sure, the credentials must be stored in EEPROM but that is the very reason of an EEPROM on practically every device.
Please don’t assume users have node-red nor even a linux system in the client domain.
There are many versions of the WiFiManager, one of them (I dont remember which one specifically) allows you to setup custom fields for any purpose, and of course it works with thinger.
I’m sorry for assuming that you will use node-red, but certainly I was thinking it, as we are talking about autoconfiguration, I assumed you want to deploy a bunch of devices, and as even the small plan allows you to use a plugin, I thougth it as worst case was covered, for the free cloud with the limited number of devices is nonsense develop selfprovisioning, unless you just want to deploy a bunch of devices by 3rd users of thinger, I am sorry again, if you are so kind to establish your conditions or limitations maybe I can see from your perspective and try to find solutions for your particular case.
How do you think to generate and send to the device the thinger new credentials without the node-red plugin? I’m curious…
Of course, if we have a wifi manager that can include the Thinger credentials, it solves everything.
Personally I am using a custom Telnet dialog that has a smaller footprint compared to a HTML server to enter the wifi and Thinger credentials.
I was just thinking about users that do not have the resources to compile a specific version of program containing the credentials, not necessarily to deploy a bench of many devices.
In later situation it could probably be easier to just let the device determine its own device name and credentials, the Thinger user being the same for every device involved.
Thank you.
IMHO a nice and versatile manager.
however, compiled alone for a Wemos LOLIN32:
Sketch uses 1020062 bytes (77%) of program storage space.
That’s quite a lot!
compiled for an esp8266 it issued that error:
…libraries/thinger.io/src/ThingerESP32OTA.h:5:10: fatal error: Update.h: No such file or directory
What library is missing to provide Update.h?
regards.
Laszlo
P.S. I am currently trying an alternative approach, using telnet.
It is somewhat “old school” but it requires far less resources and libraries and Telnet is then available for reporting and menu during operation at no additional cost.
Yes I see, but note that it has already included all the thinger’s needed library, even for OTA by VSCode, the thinger OTA example uses 67% of the memory, I agree that the WiFiManager has a HUGE code, didn’t check all the options, just made it work and left it as it is in case that somebody else wants to play around with all the options it provides.
This is required for the OTA, changing “32” by “8266” at all thinger’s commands (#include <ThingerESP32.h> → #include <ThingerESP8266.h>) it should compile.
