I'll ask the questions first: Is it possible to host a tiny browse-able website on a wi-fi equipped MCU such as the 8266? And if so, being that I am a generalist with only a few years of C++ and a few projects in assembly (but decades of embedded product manufacturing) is the development of a webpage-serving extension to my firmware something that only an advanced software engineer should attempt? I'd also like to know about the tools I would need. Are there tools and beginner examples, say, on github? I just don't know what I am up against or where to start.
More Detail:
I am designing a product that will be better for the end-user if they can easily set a number of parameters using their smartphone. What I think would be great is to embed an extremely bare-bones, tiny, textual website inside a wifi equipped MCU, such as the 8266 or ESP32 . The end-user would log on to the device's site, and use their browser to change my product's settings. My illustration below is how I imagine it. No glamour, whatsoever. No playstore app, no bluetooth, just plain-text html that is easily handled by any browser. This product will never generate the revenue needed to fund the development of a dazzling GUI (nor the burdensome tech support when dazzlery goes wrong!)
I appreciate any comments, philosophy and references to further learning or tools. I also appreciate blunt (really funny or constructive) criticism.
You simply use the web server which comes with the Arduino ESP8266 core software. The web pages are best stored in a file system (spiffs/tinyFS). The configuration parameters which the user can alter are stored in flash memory (via emulated eeprom or other methods).
There are techniques to keep a clean separation between data and HTML like sending the static html to the browser which then makes a return trip to the server (ESP8266) to collect the variable data and populate the relevant fields.
For a less clunky user experience, and to minimize submitting data to the server on each page change, you can define a large page and selectively hide all except that which fits on the current viewed page. That is, a large page is divided into a number os separately navigable “virtual” pages.
This project uses some of these ideas for setting up and storing the configuration parameters: Arduino ESP8266 Speaking Clock. However, you should probably start with a simpler tutorial maybe creating a web page with some fixed Text and one variable field. The user enters something in the variable field which is stored a presented to the user the next time. Progress from there.
Thanks for the reply. 6v6.. Your speaking clock project is simply awesome! Since posting I did a little more digging and found a good number of resources, as Cedarlake and Icebuster suggested. As is often the case with in multivariate projects, one must cherry pick among the tutorials and arrive at their own conclusions, which I am in the process of doing.
For the benefit of future searchers on this topic - I will leave with my current understanding of a few points that were recently slowing me down:
Websockets (allows the ESP to push data to the browser - I do not need this. My user will see static information on their browser until they refresh/reload the webpage. Access Point Mode vs. Station Mode: Access Point Mode does not require an intermediary router - you log in (id/password) into the ESP (my preferred solution). Station Mode requires an intermediary router. The ESP logs into the local router and becomes visible on that router's network to other devices on the network, such as your phone.
It looks like you already have a good overview of the main issues.
The Access Point mode is usually always used initially anyway even if the device has to connect to a router afterwards. It [access point mode] is used to feed the device the credentials for accessing the router prior to the device then changing to station mode. There is one refinement possible for access point mode to improve the user experience when connecting to it. That is the “captive portal” so it is not necessary to then explicitly enter the Address of the web server. This library, for example, supports it: GitHub - tzapu/WiFiManager: ESP8266 WiFi Connection manager with web captive portal
As an embedded systems engineer who's been doing more web-related work over the last few years there are a couple of things that I've found quite useful.
ESP8266 libraries support mDNS so you can name your devices. Instead of having to remember 192.168.1.56, you can refer to it in the browser as "Pump1.local" All modern OSes will support this.
AJAX can be simpler than websockets for basic interaction and removes the need for the user to refresh the page to get dynamic updates.
Spend some time learning Javascript. On limited CPUs like the ESP8266, being able to do complex work in the browser instead of on the controller can save a lot of time.
Thanks 6V6 (I'm a 6L6 guy - but I think the L stands for Loss(hearing)). tzapu says "ESP will try to connect. If successful, it relinquishes control back to your app. " I am not sure I have a complete grasp of this. It sounds like, (i) the ESP is "advertising" - (ii) the Phone replies and temporarily becomes a slave during the negotiation and portal deployment, after which (iii) the ESP becomes a slave via input from the phone. --- Still reading tzapu's repository, but it sounds like a fit.
That's cool! Thanks CLI for sharing the mDNS concept and the advice to learn Javascript. Per your post I am on a knowledge quest. I am super limited coder (old PIC assembly, and limited C++), it wouldn't kill me to take a month and learn some introductory JS.
I think you have more or less have understood it. Without looking directly at what he has written, I think this is expressing the idea that the ESP is first acting as an access point and running a web server which the user connects to with a smartphone etc. The user enters the credentials needed for accessing the local WLAN. Once that happens, the ESP can then enter station mode and connect, as a client and using the supplied credentials , to the local WLAN. The ESP of course stores these credentials for future use.
