v3.2 is the first firmware that, on the bench, recovers by itself from every failure we could reproduce — including the one that matches the field dropout exactly. It is v3.1 (already a large, tested step up over v2.2) plus a wider self-check, at a cost of 118 bytes and no change to anything a customer or control system sees. This page lays out the tested, unbiased evidence and links to where each decision is justified.
Superseded (2026-10-12): a code analysis found four gaps in v3.2; v3.3 closes them and is now the recommended firmware. See why v3.3 should be official and all versions compared. This page is kept as it was.
Adopt v3.2 as the official EPS firmware, in place of v2.2 (field) and v3.1 (current final).
v2.2 drops off the network — no ping, no web page, no control until a power cycle — and we reproduced several defects that each produce that state. v3.1 already recovers from all of them by itself, usually within seconds, and passes 46 of 56 network-standard requirements against v2.2's 26. v3.2 closes the last gap we found on the bench: four single-register chip faults that fell outside v3.1's self-check and left it dead — among them a PHY power-down that reproduces the field symptom exactly. In the re-run, v3.2 recovered from all 14 faults, with no "dead" outcome anywhere, no change to the outputs, and no instability in normal running, for +118 bytes of flash and three extra chip reads every five seconds.
This is a bench result. It does not, on its own, prove the field dropouts are over — the trigger for static-mode units is still open and the hardware-side checks are pending. It does mean v3.2 strictly dominates both older firmwares on every measurement we have, with no regression and nothing a rollback couldn't undo. The recommended path is: make v3.2 official, then confirm it in the pilot.
Each version kept everything the control systems and installers rely on and changed only the network layer. Every step was driven by a tested finding.
v2.2 shares four connections across everything, never notices if the network chip loses its settings, and blocks for up to a minute on DHCP. v3.0 gives each service its own hardware socket, checks the chip every 5 s and re-initialises it, never blocks, and keeps a flight-recorder log.
Why: socket starvation & chip-settings loss (findings) · v2.2 vs v3.0 under load (findings) · full report §5.1–5.11
RFC 2131 DHCP timing and address decline, RFC 5227 address-conflict detection, RFC 1122 TCP timers, correct HTTP method handling, optional syslog — plus review fixes. This is what lets it share a managed network without restarting itself or taking an address in use.
Why: the DHCP strand (findings) · standards per requirement (findings) · standards: v3.1 vs v2.2 (summary) · full report §5.22–5.23
v3.1 checks five registers every 5 s (chip version, IP, MAC, mask, gateway). A pre-registered fault matrix showed four faults fall outside that check and leave v3.1 dead: a ping block, the retry count at zero, a forced slow link, and a PHY power-down — the last one the exact field symptom. v3.2 adds the mode, retransmission and PHY registers to the same 5 s check and re-initialises on a mismatch, exactly as it already does for a bad address.
Why: the 14-fault matrix (findings) · corrections to earlier conclusions (findings) · full report §5.24
Pre-registered tests, every trial reported. The network-layer results were measured on v3.0/v3.1, which v3.2 contains unchanged; the chip-health and fault-matrix rows are v3.2's own measurements. Each row links to where it is described in full.
| What was tested | v2.2 | v3.2 | Detail |
|---|---|---|---|
| Availability under normal controller load (6 runs, 2 boards) | 84.2–86.6 % | 99.9–100 % | findings |
| Control reply, 99th percentile | 1,031–1,532 ms | 31–47 ms | findings |
| Longest control-port outage per 5-min run | 79–121 s | 0 s | findings |
| Idle / half-open connections (up to 5 per port) | control port dead from 1–2 | 800 of 800 answered | findings |
| Network chip loses its settings | dead until reset (4/4) | back in seconds, outputs kept | findings |
| DHCP: one unanswered renewal, server away at restart | stranded until power cycle | recovers by itself | findings |
| 14 single-register chip faults (3 trials each, real box) | dead or stuck on 12 of 14 | recovers from all 14, no dead outcome | findings |
| — of which: PHY power-down (matches the field symptom) | dead | back 11–12 s, no reset | findings |
| Start-up after a reset (real box, ×200) | 200/200, 0 deaf | 200/200, 0 deaf | findings |
| Network-standard requirements passed, of 56 | 26 | 46 | findings |
| 5 h side by side, ping + control every second | no failures; worst reply 625 ms | no failures; worst reply 16 ms | report |
A real SPI glitch or an ESD event is more likely to flip a single chip register than to reset the whole chip. The pre-registered fault matrix wrote one fault at a time into the real box's own chip — the firmware pokes its own register, the PC sends only ping, a control command and a web request, no crafted traffic — and watched every service for 120 s, three trials per fault, on each firmware. This is the test that separates v3.2 from v3.1.
The reading is simple: v3.1 was already far ahead of v2.2, but it still died on the one fault that looks like the field failure. v3.2 turns that fault — and the three others v3.1 missed — into a self-recovery, without breaking anything v3.1 already handled and without ever leaving the box in a state that needs a power cycle.
POWER_ON/OFF/STATUS, OUTx): Companion, eXcontrol, Crestron and Q-SYS work as before.