Source: https://mokxi.com/docs/editor/wifi
Updated: 2026-09-28

Getting started The editor Placing parts Wiring Sticky notes Drawing on the canvas Tidying up Pinned comments Frames Reusable blocks Making chips The code editor and compiling Run and the serial monitor The serial plotter The operating point, sweeps and frequency response The debugger Ask: questions about your circuit WiFi, simulated The properties panel Undo, copy and paste Keyboard shortcuts Saving and autosave Sharing a project Exporting PNG and SVG SPICE netlists Working on a phone Install it as an app Boards Parts Accounts and plans Live collaboration Classrooms Lessons and the learning game Troubleshooting Reference

Docs / The editor / WiFi, simulated

# WiFi, simulated

The board can join a network, fetch a page and serve one. The radio is
simulated: there is no 802.11, no real internet, and the WiFi runtime is ours.

The radio is simulated. There is no 802.11 anywhere in Mokxi and nothing a
sketch does can reach the network your browser is on. What is faithful is the
Arduino code you write, which is the whole point, because it is the code you
would write for a real board.

Five boards have it, and they are the five that have a radio on the real
hardware: the ESP32-C3, the ESP32-C6, the classic ESP32 DevKit, the
ESP8266 NodeMCU and the Raspberry Pi Pico W. On every other board here,
including a plain Raspberry Pi Pico, which has no wireless part on it,
#include <WiFi.h> stops with a sentence saying so rather than writing to an
address its chip does not have. That is on purpose: a stub that answered "not
connected" would be a lie with a plausible shape, and a compile error is not.

## What is real and what is not

Real, in the sense that it behaves the way your board will:

- the calls (WiFi.begin(), WiFi.status(), WiFi.localIP(), HTTPClient,
WebServer) with the signatures a tutorial gives you;

- the status codes, which are Arduino's own enum, value for value;

- the timing: joining takes between one and three seconds, and a wrong password
fails after five, which is where a real board on a quiet network lands;

- the cost: a fetch really takes 60 ms of the sketch's time, and a sketch that
forgets server.handleClient() really never answers.

Not real, and never pretended to be:

- no radio. No channel, no scan, no scanNetworks(), no beacon, no WPA2, no
encryption of any kind. The password is compared as a string.

- no real internet. No TCP, no DNS, no sockets, nothing that leaves the
browser tab. Four made-up names exist and no others.

- no TLS. WiFiClientSecure compiles and then fails, saying so. An
https:// URL fails the same way. A TLS that trusted everything would teach
you that https is free.

- no second machine. One board, one network, one address. Nothing outside
this browser tab can reach the server your sketch runs.

- RSSI() is a setting, not a measurement. Moving the board on the canvas
changes nothing.

- no Bluetooth. The ESP32, the C6 and the Pico W all do Bluetooth on real
hardware. None of it is here, and there is no header to fail on.

## Setting up the network

Click the board and look at the properties panel: wifiSsid, wifiPassword
and wifiRssi. Those three are the one access point this board can see. With
no radio there is nothing to scan, so the network is a property of the board
rather than a part you place beside it.

Match them in your sketch and it joins. Get either one wrong on purpose and
watch what happens. That is the more useful lesson of the two.

The Cloud panel edits the same three while the sketch is running, so you can
pull the network out from under a running board and see the connect loop start
again.

## Joining

WiFi.status() walks WL_IDLE_STATUS, then WL_DISCONNECTED while it
associates, then WL_CONNECTED. There is no WL_CONNECTING in Arduino, which
is why the loop above is written the way every tutorial writes it.

A wrong password becomes WL_CONNECT_FAILED after five seconds. A name that is
not the one on the board becomes WL_NO_SSID_AVAIL. The address is always
192.168.4.2, and it is the same address after a disconnect() and a second
begin().

## Fetching

Three addresses exist on this simulated internet:

- http://time.mokxi/: the simulation's clock, as an ISO string. It is the
kernel's clock counted from a fixed midnight, not the time of day, because the
simulation does not know what day it is.

- http://weather.mokxi/: JSON with a temperature and a humidity you set in
the Cloud panel. Change one and the next fetch brings the new number back.

- http://echo.mokxi/: whatever you POST, straight back.

Anything else does not resolve. http://example.com/ comes back as
HTTPC_ERROR_CONNECTION_REFUSED, and HTTPClient::errorToString() tells you
why in one line: no real internet: names under .mokxi only. That refusal is
readable from the sketch on purpose. It is a thing worth teaching, not a thing
to hide.

## Serving

on(path, handler), onNotFound(), send(code, type, body), arg(name),
hasArg(), uri() and method(). Your handlers are your code, running on the
board's core at the board's clock.

The Web panel (a tab beside Serial along the bottom) is the browser for
them. It has an address bar starting at http://192.168.4.2/, a Refresh, and
the page itself in a frame with scripts switched off. Links and buttons in
that page come back round into your sketch, which is what makes "switch the LED
from a web page" work end to end.

If the page never arrives, the panel says so, and after ten seconds the network
answers 504 itself: the usual reason is a loop() that has stopped calling
handleClient().

## The Cloud panel

Every request, both ways: what the board asked the simulated internet for, and
what the Web panel asked the board for, with the method, the address, the
status, the bodies and, when something failed, a line saying why. It is the
network tab for a board.

It also holds the two weather.mokxi dials and the three access-point settings,
so a lesson can turn one and watch the sketch notice.

## Try these

- WiFi: join the network: the connect loop, the address and the signal.

- WiFi: fetch the weather: HTTPClient against weather.mokxi, and a
deliberate request to example.com so you read the refusal yourself.

- WiFi: a lamp on a web page: two buttons and a form that switch the LED on
GPIO 8.

On every WiFi board (the ESP32-C3, ESP32-C6, Pico W, ESP32 DevKit, ESP32-S3
and ESP8266) all three compile in the browser, exactly like every other
example.

The whole contract, register by register and limit by limit, is in
Simulated WiFi.

### On this page

What is real and what is not Setting up the network Joining Fetching Serving The Cloud panel Try these