Web-enabled Devices
Why am I - as an embedded developer - so concerned with web-technology?
In my book Embedded Software for the IoT, I spend many pages on internet-technologies, and not so many on Web. I do mention HTTP and REST API's etc. but I don't go into details about web-enabled devices. Ever since the invention of the web-browser, companies have wanted to web-enable their devices. This basically means that the embedded device can be controlled from a browser. We have seen this unfold since the nineties - probably one of the most stable trends in the industry.
What few people realize is how different the implementations have actually been. We will get to this in a while, but first - let's look at the advantages of controlling your device with a browser:
- All PCs have a browser. Thus, in the cleanest solutions, any PC with zero installed extra software will do the job.
- When a browser is used, the semantics of the user interface is guided (not given) by HTML - no need to reinvent the wheel over and over.
- All PCs had a DB9 RS-232 connector, then USB, then Ethernet and now Wi-Fi.
- Most software developers have some experience with web-technologies - thus the barriers are not so high.
- Similarly, users know webbrowsers and how they generally work. This means less problems for users.
- On the embedded side standard technology is also possible. Any decent ARM CPU or MCU today can host a webserver. This was not always the case, but we had other standards helping us.
I wanted to show the story and asked ChatGPT to make it visible. I have only made a few changes to it's output in the following.
ChatGPT - prompt and a (slightly edited) answer
Prompt: Over many years we have seen embedded devices being controlled via browsers on PCs. From early small resource-limited devices with RS-232 in point to point for service, then something more advanced with USB until fully networking devices with WiFi or Ethernet. Browser always on the PC, but not necessarily the webserver on the device. Please show the development in block diagrams- with protocols on both sides.
Answer: Love this question—this evolution tells the real story of embedded systems growing up alongside PCs and networking.
Below is a timeline of block diagrams, each showing:
- where the browser lives
- where the server / control logic lives
- the protocols on both sides
I’ll keep the diagrams consistent so the progression is easy to see.
1. Serial-only devices (service & diagnostics era)
Typical timeframe: 1980s–1990s
Browser: ❌ none
UI: terminal emulator (HyperTerminal, minicom, PuTTY)
+------------------+ RS-232 +----------------------+
| PC | <-----------------> | Embedded Device |
| | | |
| Terminal program | | MCU |
| (CLI / text UI) | | Firmware |
+------------------+ +----------------------+
Protocols
PC side
- RS-232 electrical signaling
- ASCII / vendor-specific text commands
Device side
- UART
- Custom command parser
🔹 No browser yet — interaction is purely textual and manual.
2. Serial device + PC-hosted “browser-like” UI
Typical timeframe: late 1990s
Browser: still ❌
UI: Windows/Linux app pretending to be a GUI “front end”
+-----------------------+ RS-232 +----------------------+
| PC | <------------> | Embedded Device |
| | | |
| Native GUI app | | MCU |
| (C++, VB, Java) | | Firmware |
+-----------------------+ +----------------------+
Protocols
PC side
- RS-232
- Binary or ASCII protocol
Device side
- UART
- Proprietary framing
🔹 Logic and UI live entirely on the PC.
3. USB devices + browser via helper application
Typical timeframe: early 2000s
Browser: ✅ (but indirect)
Server: ❌ (still on PC)
+---------------------+
| Web Browser |
| (HTML/JS UI) |
+----------^----------+
|
| localhost HTTP
|
+----------+----------+ USB +----------------------+
| PC Helper Service | <----------> | Embedded Device |
| (driver / daemon) | | |
| | | MCU |
+---------------------+ +----------------------+
Protocols
Browser → PC
PC → Device
- USB CDC / HID / vendor class
- Custom protocol
🔹 Browser enter the picture, but the embedded device is still dumb.
4. Networked device, web server still on PC
Typical timeframe: early–mid 2000s
Browser: ✅
Network: Ethernet
Server: PC
+------------------+ TCP/IP +----------------------+
| Web Browser | <----------------> | PC Web Server |
| | | |
+------------------+ | Device proxy logic |
+----------^-----------+
|
| TCP/IP
|
+----------+-----------+
| Embedded Device |
| |
| MCU + Ethernet |
| Custom protocol |
+----------------------+
Protocols
Browser → PC
- HTTP - see HTTP
PC → Device
- TCP/UDP - see IoT book-page
- Vendor-specific protocol
🔹 Useful when the device is too weak to host a web server.
5. Embedded device hosts its own web server (classic embedded web)
Typical timeframe: mid-2000s onward
Browser: ✅
Server: ✅ (on device)
+------------------+ HTTP +----------------------+
| Web Browser | <--------------> | Embedded Device |
| | | |
| HTML forms | | MCU |
| Basic JS | | TCP/IP stack |
+------------------+ | HTTP server |
+----------------------+
Protocols
Browser side
Device side
- TCP/IP - see IoT book-page
- HTTP - see HTTP
- CGI-like handlers
🔹 This is where embedded + browser really clicked.
6. Embedded device with rich browser UI (AJAX era)
Typical timeframe: ~2010s
Browser: rich client
Server: embedded
+-------------------------+
| Web Browser |
| |
| HTML / CSS |
| JavaScript (AJAX) |
+------------^------------+
|
| HTTP / REST / JSON
|
+------------+------------+
| Embedded Device |
| |
| MCU / MPU |
| TCP/IP stack |
| REST API |
+-------------------------+
Protocols
Browser
- HTTP - see HTTP
- REST - see IoT book-page
- JSON
- AJAX / fetch - see HTTP
Device
- TCP/IP - see IoT book-page
- HTTP - see HTTP
- REST - see IoT book-page
🔹 Separation of UI and control logic starts to look modern.
7. Wi-Fi / IoT devices + browser + cloud
Typical timeframe: 2015–present
Browser: anywhere
Server: cloud + device
+------------------+ HTTPS +----------------------+
| Web Browser | <--------------> | Cloud Server |
| (PC / mobile) | | |
+------------------+ | Auth / API |
+----------^-----------+
|
| MQTT / HTTPS
|
+----------+-----------+
| Embedded Device |
| |
| MCU + WiFi |
| MQTT / REST client |
+----------------------+
Protocols
Browser → Cloud
- HTTPS - see HTTP
- REST / WebSockets - see IoT book-page
Cloud → Device
- MQTT - see IoT book-page
- HTTPS - see HTTP
- CoAP (sometimes)
🔹 The browser no longer talks directly to the device.
8. Hybrid: local UI + cloud backend (very common today)
+------------------+ HTTP +----------------------+
| Web Browser | <---------------> | Embedded Device |
| (local access) | | (local web UI) |
+------------------+ +----------^-----------+
|
| MQTT / HTTPS
|
+----------+-----------+
| Cloud Platform |
+----------------------+
🔹 Local control when nearby, cloud when remote.
More Web
On top of the above "embedded-angle" I also have an interest in writing web-content - probably related to book authoring. This is why I used to have my own WordPress website - see WordPress Log and WordPress Tools.
In August 2025 I switched to this classic HTML-based site - see Website Log. Lately I have been fond of writing first version of pages in MarkDown before converting to HTML - see Sphinx. I have not switched this place to run on Sphinx - but I do like MarkDown as a start.