Version 2.0.2 validation

Validation date: 2026-10-20. Dependencies remain pinned in platformio.ini. Earlier results: 2.0.1, 2.0.0.

Builds and packaged firmware

All six images fit their factory partitions. tests/release_test.py verifies chip families, bootloader offsets, partition/application bytes and SHA-256 hashes. C3, C6, C5, wired ESP32 and S2 remain build-verified rather than physically tested.

Rendering and browser checks

Native tests exercise all 18 modes, six palettes, speed extremes, reverse, clock wrap and fractional-boundary color lookup. Every animated mode changes across sampled times; the two static modes remain static. Rendering uses bounded storage with no allocation or blocking delays.

Chromium and WebKit tests pass on desktop and phone widths: animated preview, preset loading, new settings submission, temporarily empty numeric input, legacy settings import, export, system settings, buzzer controls, alert testing and escaping of radio names. Newer structuredClone and AbortSignal.timeout APIs are deliberately unavailable in these tests.

The real S3 UI also passes in Chromium and WebKit at phone width, including 18 mode choices, moving Aurora preview, saving, and the enabled BLE spam rule. Wildcard DNS and Android/Apple HTTP discovery responses still pass.

Connected hardware

Both connected XIAO ESP32-S3 boards received verified writes. Their old lighting preferences survived the upgrade; conservative Bluetooth spam alerts were enabled alongside deauth alerts. On the first board, Aurora, speed, palette and a temporary alert opt-out survived a deliberate reset, confirming that the upgrade policy runs only once. Bluetooth spam alerts were then enabled again.

tests/device_http.py checks all 18 modes with speed/palette/reverse variations, six alert patterns, deauth and Bluetooth-spam alert output routing, expiry, invalid-write rejection, 120 status requests, settings restoration and persistence. Manual alert tests verify output routing, not RF detection sensitivity.

The first board is left on Aurora at its existing brightness. The second keeps its selected Rainbow wave, now with independent motion speed.

Attack-pattern tests and limits

Deauth fixtures still reject ordinary departures, retries, short bursts, many one-off clients and traffic split across APs; sustained broadcast and repeated single-target floods confirm after three full seconds. BLE tests recognize the real Apple/Fast Pair/Swift Pair structures, reject stable crowds and brief bursts, and confirm sustained churn under the configured 35/120 ms receive duty.

The former four-second scan followed by a two-second pause could interrupt the three complete BLE confirmation windows. The scanner now runs continuously, passively, with its receive duty and bounded queue unchanged.

No over-the-air attack was generated, and no known Axon camera or buzzer was available for controlled testing. These are conservative pattern detectors, not proof of malicious intent or a guarantee that every attack will be heard. S2 has no BLE and C5 monitoring remains 2.4 GHz only.

Runtime capture

Both boards completed a five-minute serial capture with ten health records each, no unexpected reset, panic or brownout. Heap stayed bounded while continuous passive BLE reception and the animated lights ran.

The second board had already recorded 81 drops by the first capture sample; its counter did not increase during this capture, including the HTTP tests. Queue limits preserve responsiveness but do not provide lossless reception. The exact cause of those earlier drops was not isolated. Sanitized measurements are in validation-results-2.0.2.json; raw radio data stays private. A finite capture does not guarantee indefinite uptime or field detection accuracy.