Network Discovery and Device Verification

This page explains how to verify FastBee devices on the same LAN without changing the computer's network connection. For the full build, flash, and test matrix, see Flashing and Testing.

Verification Boundaries

• Automated tests use only the device STA address; the test computer must not connect to the device AP.
• When STA is not connected, record the serial and router DHCP information and skip the HTTP tests; do not switch the computer's network.
• IP addresses may change with DHCP renewals; for long-term deployments, reserve addresses by device MAC in the router.
• /api/health and /api/system/capabilities can be probed directly; other device APIs usually require logging in first and reusing the session cookie issued by the device.
• 401 means the device is reachable but the request is unauthenticated; do not judge it as a web or network failure.

Multi-Device Test Checklist

The repository does not keep lab DHCP addresses. First get each device's current STA address from the serial boot log or the router DHCP client table, then replace <device-ip> with the actual value in your local config. Config sources live in the FastBee-Arduino source repository and are not interchangeable.

Serial	PlatformIO environment	STA address	Config source
COM4	esp32c3-F4R0	<device-ip>	docs/device-test-configs/com4-esp32c3-f4r0/
COM11	esp32c6-F4R0	<device-ip>	docs/c6-rgb-led-f4r0/
COM15	esp32s3-F16R8	<device-ip>	docs/ecm50a-s3-f16r8/
COM16	esp32-F4R0	<device-ip>	docs/device-test-configs/com16-esp32-f4r0/
COM7	esp32s3-F8R0	<device-ip>	docs/waveshare-esp32s3-relay6ch/

Public configs must use placeholder credentials. Real WiFi, MQTT passwords, and device identities are injected only during controlled deployment and must not be written into documentation or committed to Git.

Confirm the Address First

Confirm the STA address from, in priority order:

1. The Access URL or STA IP in the device serial boot log.
2. The router DHCP client list.
3. A maintained local fleet config file.

The scripts/net-discovery.ps1 script in the source repository only scans the network segments and address ranges defined inside the script; it is an auxiliary diagnostic and cannot replace the serial or DHCP records, nor prove the config was flashed correctly.

Single-Device Verification

Run in the FastBee-Arduino source repository:

cd D:\project\gitee\FastBee-Arduino

# Public health endpoint; does not modify device state
curl.exe --noproxy "*" --max-time 10 http://<device-ip>/api/health

# API smoke for login, capabilities, network, MQTT, peripherals, PeriphExec, etc.
powershell -ExecutionPolicy Bypass -File scripts\smoke-test-device.ps1 `
  -BaseUrl http://<device-ip> -Profile unified -RequireNetworkConnected

# 16 web pages, two rounds; keep a 1s interval on 4MB devices
powershell -ExecutionPolicy Bypass -File scripts\device-web-smoke.ps1 `
  -BaseUrl http://<device-ip> -Rounds 2 -DelayMs 1000 `
  -TimeoutSec 15 -MaxElapsedMs 5000 `
  -ReportPath test\reports\c3-web-smoke.csv

Replace the example address with the target device's current STA address. Never pass 192.168.4.1 to a real-device test entry.

Five-Device Verification

scripts/device-fleet.example.json only demonstrates the field structure. Copy it to a local config before use and modify it with the current serial ports and DHCP addresses; do not commit field information to the public repository.

cd D:\project\gitee\FastBee-Arduino

# STA, login, and device APIs first; browser cases not started yet
powershell -ExecutionPolicy Bypass -File scripts\run-device-fleet-tests.ps1 `
  -DeviceConfig scripts\device-fleet.example.json `
  -Ssid <expected-ssid> -BrowserTests:$false

# Enable browser tests when page-interaction regression is needed
powershell -ExecutionPolicy Bypass -File scripts\run-device-fleet-tests.ps1 `
  -DeviceConfig scripts\device-fleet.example.json `
  -Ssid <expected-ssid> -BrowserTests:$true

Script output is saved under .pio/test-results/fleet/. When the exit code is non-zero, use the report to locate the specific device and stage; do not cover a failure with passes from other devices.

Judging Results

Check	Pass condition	Common failure meaning
/api/health	HTTP 200 with JSON returned	Device offline, address changed, or web service not ready
Login	Success returned and a session Cookie established	Wrong credentials, busy memory, or firmware/web version mismatch
STA	Network state is STA and connected to the target SSID	Credentials, signal, DHCP, or router access restrictions
API smoke	Endpoints for the target capabilities pass	Config, feature flags, auth, or a specific module failing
Page patrol	All 16 resources return HTTP 200 within the time budget	Incomplete LittleFS, low-memory gating, or network jitter
Observation window	Uptime does not regress when no restart is scheduled; internal DRAM/contiguous blocks and business stay valid	Abnormal reset, resource decline, or degradation; scheduled restarts start a new session

When a 4MB no-PSRAM device returns 503, stop concurrent requests and check /api/system/metrics or the serial log. When pages keep returning 401, log in again first — do not misread auth expiry as insufficient memory.

Failure Handling

1. STA address unreachable: check the serial log and DHCP list to confirm whether the address changed; keep the computer's current network.
2. Home page reachable but API returns 401: log in with the project scripts, or log in again in the browser.
3. Page resources time out or 503: lower concurrency, keep request intervals, and record available Heap, the largest contiguous memory block, and WebGuard metrics.
4. Device falls back to AP: record the STA failure reason and skip that device's HTTP acceptance; fix the network config, then retest from STA.
5. A feature page is missing: check "Feature Config" and /api/features/status first to distinguish not-compiled, not-enabled, budget-rejected, and runtime-disabled.

Long-Term Stability

A short smoke pass does not equal long-term stability. For formal acceptance, run the required monitoring duration per the Stability and Release Checklist and keep the reports. A startup command alone or a few samples cannot be recorded as a long-term stability pass.

Related Documentation

• Network Verification Quick Start
• Flashing and Testing
• Network Configuration
• Troubleshooting
• API Reference