PE1-4.4 NodeMCU & IoT Concepts

What this is and why it exists

The board so far does something. It does not tell anyone about it, and it needs a cable to reach you.

Adding a network changes that, and that single addition is what makes a project one of the connected kind. The measurements can now be read from anywhere, and the board can be told what to do from anywhere.

The vocabulary

• NodeMCU — a small development board with a wireless radio built in.
• Board manager — the part of the development environment that adds support for a new chip.
• HTTP — the request and response protocol a browser uses.
• HTML — the markup that describes a page.
• Web server — a program that answers requests with pages.
• Web client — a program that makes requests to somebody else's server.
• Endpoint — the address a request is sent to.
• ThingSpeak — a service that stores measurements sent to it and plots them.

The mental model

The second board exists for one reason. It has a radio. Everything else about it is a variation on what you already know.

Two practical things catch everyone. The pin numbering printed on the board differs from the numbering the code uses. A pin that works on the first board may be somewhere else here. And the environment needs to be told about this chip before it can compile for it, which is what the board manager does. Neither is difficult and both cost an hour if you do not expect them.

The web protocols appear here in their smallest useful form. Read them as vocabulary rather than as a web course. A client opens a connection and sends a request naming what it wants. A server replies with a status, some headers, and a body. If the body is markup, a browser renders it as a page. That is enough to do everything in this topic.

Serving a page is the first milestone, and it is a real one. The board listens for connections, and when a browser asks, it builds a small page of text and sends it back. At that moment the project stops needing a cable. Somebody on the same network can read your sensor from their phone.

Adding controls closes the loop. The page carries a form or a link, and when the browser sends that back, the board reads what was requested and acts on it. Handling a form on a device with kilobytes of memory is a good lesson in constraints. You cannot hold the whole request in memory and parse it comfortably, so you read what you need as it arrives and discard the rest.

Then the direction reverses. Instead of waiting to be asked, the board becomes the client and sends its measurements somewhere. This is the more useful arrangement, because a board on a home network usually cannot be reached from outside it, while it can reach out.

ThingSpeak is worth using precisely because it removes the server problem. You do not have to own a machine, keep it running or secure it. The board sends a request carrying its reading, and the service stores it and plots it. Within one session you are looking at a graph of your own sensor's data.

That is the complete chain this course has been building. Something physical, measured by a sensor, read by a program, sent over a network, stored, and shown to a person far from the board.

What you should now be able to explain or do

Say why the second board is used and configure the environment for it. Explain the difference between the printed pin numbers and the numbers the code uses. Describe an HTTP request and response in enough detail to serve a page. Serve a page from the board and accept a control input from it. Send a measurement to a storage service and say why that direction is more practical than serving.

Check yourself