Disable webserver after initial wifi config ?

[zamolxe]

Long story short:
Trying to get USE_MQTT_TLS and USE_SCRIPT working together on wemos d1 mini... That works fine until I have USE_WEBSERVER, that is required only for setting up the wifi 1st time.
So wondering if anyone has any idea how to disable the webserver after the initial configuration so I don't get out of mem when the mqtt tls starts ?

Extra notes:

• The firmware is already stripped down to only this pieces...
• I know that TLS and webserver are not officially supported

[barbudor]

I know that TLS and webserver are not officially supported

I don't know where you get this idea
What is not supported is https whether as a webserver or as a webclient (the later only on esp8266 as ESP32 can be https client with WebQuery or Berry)

Neverthe less the command to disable the webserver is.... Webserver

[sfromis]

Using the WebServer command you can indeed disable web server, but that does not free any memory, as much RAM usage is tied to features being present. You may be able to trim setting for scripting to take less RAM.

It is possible to use a build without web server if you config at least minimal Wifi/MQTT details at build time, and do all admin via MQTT. Or if you do initial admin via serial, you do not need as much baked into the binary, but if the device gets reset (expected or not), it is still pretty nice to have the basic setup baked in, when you have no web server to fall back on.

[zamolxe]

I am planning to send the devices remote, it's kind of tough to ask some non technical person to configure wifi over serial, that's why I wanted to have the webserver active during the initial setup.
I was not aware that doing something like StopWebserver(); will not free any ram.
I consider as well to get the admin stuff over MQTT, but that's bails out as soon as I build the fw with USE_SCRIPT and USE_SML_M.

So far I have a lot of #undef + the the below ones...
USE_MQTT_TLS
USE_MQTT_AZURE_IOT
USE_MQTT_AZURE_DPS_SCOPEID
MAX_METERS 1 // only 1 needed
SML_MAX_VARS 20 // only 17 needed, but left some space for future
MAXVARS 20 // only 17 needed, but left some space for future
USE_SML_M
USE_SCRIPT

Any ideas on how to lower the ram usage are more than welcome.

PS: my C development skills are over two decades outdated and embedded devices are something I'm experimenting with, hence please bare with me and my limited knowledge...

[sfromis]

If the devices are based on D1 Mini, you could tell users to plug in USB to a computer, and then run the script you created to do the details of the config setup via serial. Does not take much skill on their end.

[barbudor]

1. lower the RAM usage : may be start from the tasmota-lite configuration : copy all the #undef from the tasmota-lite configuration to your user_config_overide.h

2. sfromis initial suggestion was not to configure through serial but hardcode the wifi and mqtt details into the user_config_override.h which is totally plug and play for the user

[sfromis]

Sounds like the expectation is for the shipment receiver to be able to do basic wifi config locally without having a nerd nearby to go deeper than simple browser-based onboarding for the local wifi network of the user. Hence my follow-up suggestion of letting the non-techie user run a supplied script to do the simple config commands via USB, when leaving out web server from Tasmota.

[stefanbode]

You can do the wifi config into the user_config_override and build your own device. In this case you can compile it without webserver at all. I do not think this is a good idea, anyhow. Maybe you should do the same what all the professionals here do too. Change to ESP32. Specially the Mini version is PIN compatible with the D1 mini and you have so much more fun with it.

[zamolxe]

That's also an option... was still hoping not to trow away the 20+ esp8266 devices already on the shelf while keeping the cost down

[miky2k]

A console like telnet tcp service should be less memory intensive than webserver?

[sfromis]

You have similar to that via serial. And it would be a more memory intensive as an added feature, as it would be unrealistic to skip the web UI for admin stuff. As a protocol, telnet is not more lightweight than http. And since the context of this thread is SSL, that would mean SSH which does add some complication (memory usage).

Still, until having a real use case to handle, it is a waste of time to focus on different numbers after a major change, as you'd need real good arguments for such a lot of work.