ATI Straton Flex Firmware Rewrite

Following on from the ATI Straton Flex Reliability Notes -- this tank's two Straton Flex 153 fixtures (see the Acropora page) are now also running a from-scratch Node.js rewrite of the fixture's own web application, in place of ATI's original closed-source app, on one unit as a live trial. Same hardware, same OpenWrt/Onion Omega2+ board, same LED driver underneath -- only the application layer on top has been replaced. SSH, networking, and the rest of OpenWrt are untouched.

The reliability investigation above started as a memory-watchdog crash and ended with a one-line config fix, a smarter scheduler, and automatic recovery -- all patches on top of ATI's own app. Reading through that app's own source to diagnose the crash meant reading all of it, and that turned up several further structural issues in how the application itself is built -- old, long-unpatched bundled dependencies and some genuinely concerning gaps in how a few features handle input. Same disclosure policy as the reliability page: no exploit detail here, and ATI is welcome to get in touch via the contact page for specifics. What those findings did change is the plan -- rather than patching a codebase with structural problems one hole at a time, building a clean replacement for the parts that matter (scheduling, the web UI, the device's own settings) felt like the more honest long-term fix for hardware I already own and run unattended, next to a few hundred liters of livestock.

A plain Node.js application, deployed as a drop-in replacement for the original app's own process on the exact same device -- same restart mechanism, same init script, same node --expose_gc invocation the hardware already runs. It talks to the fixture's real LED driver over the same serial protocol as the original (reverse-engineered directly from the original app's own behavior, not guessed), and stays compatible with this tank's existing automation: the same bearer-token API the reliability fixes above already added keeps working unchanged, so the Python scheduler that drives this tank's actual lighting curve never noticed the swap.

Built with an actual automated test suite -- several hundred tests, run on both a current Node release and, specifically, the exact old Node 8.10.0 this hardware itself runs, since a test passing on a modern Node proves nothing about a nine-year-old JavaScript engine on a 124MB-RAM board with no swap. More than one real compatibility gap (a method that simply doesn't exist yet on that old a Node version) was caught this way before it ever reached the real device.

• A live temperature-based safety clamp -- the fixture's own LED-driver temperature sensors are polled in real time, smoothed, and wired into both a gradual power derating curve and a hard shutoff, rather than treating temperature as a display-only number.
• A "Showcase" mode -- a time-boxed override for showing the tank off to visitors without touching or losing the real automated schedule underneath; it expires and reverts on its own.
• A diagnostics bundle download, built the same way the original app's own "Download Support File" works (full logs, process state, memory info, config) but with real secrets (the device's own API token) redacted before the file is ever written, not left sitting in plain text in a file meant to be shared for troubleshooting.
• Settings pages for things that previously meant SSHing into the device directly: picking the fixture's own timezone from a short list of real locations (Europe/Brussels, Europe/London, UTC, or a raw POSIX timezone string for anything else), and switching real-time log shipping to an off-device receiver on or off.
• A proper two-tier password recovery path (an SSH-based reset, and a physical-button fallback) instead of a single shared recovery mechanism.

Writing an independent implementation against the same real hardware surfaced a couple of its own bugs, caught and fixed before they mattered:

• The schedule was running two hours behind real local time. The time-of-day calculation driving the lighting schedule was computed in UTC rather than the fixture's own local time -- invisible for most of the testing (the development environment itself happened to run in UTC too, masking the bug), until it showed up live as a visibly wrong schedule and a dark "Royal Blue" channel during what should have been moonlight. Fixed to compute against real local time instead.
• A self-defeating hourly NTP restart, already covered on the reliability page -- found while chasing a small but real clock discrepancy during this rewrite's own testing, this one turned out to be a pre-existing issue in the stock firmware itself, not something the rewrite introduced, and the same fix now runs on both fixtures regardless of which application they're running.

This runs a live reef tank, so the rollout has been deliberately cautious rather than a one-shot swap. Every deploy backs up the currently-running version on the device first and can restore it automatically if the new version doesn't come back up healthy. Early live tests ran under an overnight automated monitor that watches both fixtures and reverts the trial fixture back to the original, genuine ATI application on its own if it detects a real, sustained problem -- a single transient blip is logged, not acted on, but a confirmed issue triggers an automatic rollback with no one needing to notice and intervene by hand. A memory watchdog matching the original app's own safety margin was added on the same reasoning once a direct side-by-side comparison showed the rewrite had no equivalent of its own.

Current status: the secondary fixture is running the rewrite as a live trial; the master fixture remains on ATI's own firmware for now, intentionally, until the rewrite has accumulated more real-world runtime. Not published as an open-source project at this point -- built specifically against this owner's own two units, not as a general-purpose release.

Same ownership stance as everything else on this page and the reliability writeup above: this hardware is out of warranty, and I consider inspecting, patching, and rewriting something I've paid for and run myself to be entirely my own call and my own risk to carry. If any of this is useful background for your own out-of-warranty unit, the same applies to you.