How to configure WiFi in DeviceScript

WiFi connection allows communicating a DeviceScript board with other network devices and services. The runtime manages the interface, while the program uses higher-level APIs such as HTTP, MQTT, or sockets.

In a classic ESP32 program, it is common to find credentials alongside the code:

const char* ssid = "MI_CASA";
const char* password = "1234_password_super_secreta";
WiFi.begin(ssid, password);

This has a huge problem: Your passwords are written in the code. If you upload the project to GitHub, you give your WiFi away to everyone. Additionally, if you change the router password, you have to recompile and reflash the chip.

In DeviceScript, WiFi management is handled as an operating system service, separate from your program logic. Today we’ll see how to do it properly.

Configuring credentials

Forget about writing the password in the .ts file (although possible, it is not recommended). The recommended way in DeviceScript is to inject the configuration into the device’s non-volatile memory (Settings).

Using a .env.local file

The DeviceScript extension has a built-in assistant for adding settings to the device:

The content of the .env files is transferred to flash memory when deploying the bytecode.

Advantage: Your main.ts code stays clean. You can share the code with a friend, and they will set their own credentials on their board without touching your script.

The file should look like this:

WIFI_SSID=MyWiFiNetwork
WIFI_PWD=MyPassword

Checking connectivity

The documented API does not require creating a Wifi object to query an IP address. The practical way to know if the network is available is to perform the operation your application needs and handle its error.

import { fetch } from "@devicescript/net"

async function checkConnection() {
    try {
        const response = await fetch("https://example.com/")
        console.log(`Network available: HTTP ${response.status}`)
    } catch (error) {
        console.warn("Could not access the network", error)
    }
}

checkConnection()

Network operations are asynchronous. While a request awaits a response, other tasks can proceed, but it is advisable to apply limited retries and progressive backoff to avoid saturating the network when the access point is unavailable.