Grow Light Control Is Splitting Into Cloud-First and Edge-Resilient Camps

Sollum Technologies walked onto the floor of the Leamington Greenhouse Grower Expo on February 25, 2026, and announced a fixture built around a specific failure: what happens to your lighting schedule when the internet drops. The SF-INFINITE runs on Sollum’s cloud platform day to day, but the company built edge computing and telemetry directly into the fixture so it keeps executing its last valid lighting plan if that connection disappears. CTO and co-founder François R.-Moisan called it “a platform designed to evolve with crops, energy constraints, and market demands,” built to remove the burden of predicting every future lighting need from a central server.

That single design choice points at a question most grow light buyers never asked five years ago. Fixtures used to be dumb hardware with a dimmer knob. Now they’re network endpoints, and network endpoints fail in ways a dimmer knob never did. A commercial controller platform can be brilliant at optimizing spectrum against real-time electricity prices and still leave you exposed the moment your ISP has a bad afternoon.

What Edge Computing Means in a Fixture

Edge computing means the processing that decides what your lights do happens on hardware physically near the lights, not on a server somewhere else. In a cloud-first system, the fixture is mostly a receiver: it takes instructions from a remote platform and executes them. In an edge-capable system, the fixture (or a local gateway sitting between the fixtures and the internet) can make and hold decisions on its own.

Sollum’s SUNaaS platform still does the heavy lifting under normal conditions: real-time control of spectrum, intensity, timing, and daily light integral targets, plus tariff-aware dimming that adjusts output against electricity pricing. The edge computing layer only takes over as a fallback. That distinction matters. A fixture that’s edge-capable isn’t necessarily running disconnected from the cloud all the time; it’s built so a lost connection degrades gracefully instead of failing outright.

Why Most Controllers Went Cloud-First

Cloud architecture won the first round of grow light automation for good reasons. GrowDirector’s DimmerDirector, which can manage up to 16,000 individually addressable or daisy-chained LEDs system-wide (200 per module, chained across multiple modules to reach that ceiling), markets itself on exactly this convenience: you can “use the greenhouse lighting controller from anywhere in the world as long as your on-site equipment device, or sensor is connected to the Internet.” Centralizing control in the cloud makes remote monitoring easy, spreads compute cost across a subscription instead of expensive onboard silicon, and lets a manufacturer push algorithm improvements to every customer overnight instead of shipping new hardware.

For a hobbyist tent or a single grow room, that tradeoff rarely matters. Worst case, you lose a dashboard for an afternoon. For a commercial facility running thousands of fixtures against a tight DLI target and a real electricity contract, the calculus changes.

What a Connectivity Gap Costs

Here’s the math a facility manager has to run. Say a leafy greens operation targets a daily light integral of 16.2 mol/m²/day, delivered as 250 µmol/m²/s PPFD over an 18-hour photoperiod. DLI is PPFD multiplied by photoperiod in seconds, divided by one million:

250 × (18 × 3,600) ÷ 1,000,000 = 16.2 mol/m²/day.

A cloud-dependent controller adjusting intensity every fifteen minutes against a live electricity-price feed is, in effect, rebuilding that photoperiod-by-intensity curve continuously through the day. Lose the connection for four hours during a midday adjustment window and one of two things happens: the fixtures hold their last commanded value (safe, but likely wrong for current conditions), or they fail to a default state the grower configured in advance, if the platform supports one. Either way, the DLI target for that day is now uncertain, and nobody finds out until yield or timing drifts a week or two later. GrowDirector’s published DimmerDirector materials don’t describe which of those two things happens, which is itself worth noting: it’s a gap a buyer should ask about directly rather than assume.

None of this requires an exotic outage. Rural fiber cuts, a router firmware update gone wrong, a facility’s own IT team locking down a firewall rule. The scenario isn’t hypothetical so much as inevitable at a long enough time horizon, and it scales with fixture count and crop value.

Grow Lights Are Late to a Problem Industrial Control Already Solved

Horticultural lighting isn’t the first industry to run into this. Factory floors, oil pipelines, and livestock operations hit the same wall years earlier. A 2026 review of edge computing in smart agriculture, published through PMC, frames the pattern plainly: agricultural IoT systems face unreliable network connectivity, latency-sensitive processing requirements, and the need for graceful degradation when cloud connectivity disappears. Livestock monitoring systems adopted local data collection specifically because remote farms couldn’t guarantee a stable connection in the first place. Nobody built those systems assuming perfect uptime, because perfect uptime was never on the table.

Grow light manufacturers had a different starting assumption. Most commercial greenhouses sit near cities, on business fiber, behind a facility’s existing IT infrastructure. Reliable connectivity looked like a safe bet, so a decade of controller design treated the cloud link as a given rather than a variable. Industrial IoT guides now describe that assumption as the real risk: in a cloud-only model, an outage doesn’t interrupt a dashboard alone, it stops the process the dashboard was managing. Edge architecture answers that by caching telemetry locally and synchronizing with the cloud only once the link comes back, rather than depending on the link to function at all. Grow light controllers are only now catching up to a design pattern that server rooms and factory floors settled a decade ago.

The Academic Fix: Control Leases and Edge Takeover

A team publishing in Applied Sciences in May 2026 put a name to the mechanism Sollum and others are building toward. Their paper, “Resilient End–Edge–Cloud Collaboration for Control Continuity and Closed-Loop Alarm Management in Solar Greenhouse IoT Systems Under Degraded Network Conditions,” proposes a framework that continuously scores connection health using round-trip time, packet loss rate, and how long the system has gone without a response. An edge gateway takes over using the last valid configuration it received once that score crosses a threshold, a mechanism the authors call a control lease. The system doesn’t dump every cached update back to the cloud at once as the connection recovers; it prioritizes high-value alarm and state data first through what they describe as a differential backfill, avoiding the burst of traffic that would otherwise follow a long outage.

The paper focuses on solar greenhouse climate and alarm systems broadly, not grow lights specifically, but the architecture transfers directly. A lighting platform facing the same round-trip-time and packet-loss signals could apply the identical fallback logic: hold the edge gateway’s last known-good lighting plan, keep executing it locally, and reconcile with the cloud once the link stabilizes. It’s a useful reference point for evaluating any manufacturer’s marketing claim that a system is “resilient.” Ask what the fallback state is, not only whether one exists.

Where Three Real Systems Land

Compare the three systems above and you get a genuine spread rather than marketing variations on the same architecture.

Three different bets. Sollum bets that most growers want cloud-grade optimization and are willing to pay for edge hardware as insurance against the moments that optimization goes dark. Heliospectra bets that some growers would rather not depend on any external platform for core function at all, treating the cloud as an optional add-on instead of the substrate everything runs on. GrowDirector’s public materials suggest the company hasn’t prioritized this question yet, at least not in anything it publishes for buyers to read.

Expect the gap between these approaches to narrow rather than widen. Edge silicon keeps getting cheaper, and the control-lease pattern described above is straightforward enough that any controller manufacturer could adopt something like it without a ground-up redesign. The harder problem isn’t the engineering. It’s that resilience is invisible until the day it isn’t, which makes it easy for a manufacturer to deprioritize and easy for a buyer to forget to ask about.

Questions to Ask Before You Buy

You don’t need a networking degree to vet this. Ask the sales rep directly: if the facility loses internet for six hours in the middle of the day, what do the fixtures do? A vague answer, or one that leads with “that almost never happens,” tells you the vendor hasn’t engineered for it. A specific answer, naming a fallback state and how long it holds before the fixture needs a fresh cloud instruction, tells you they have.

The DLI target matters more than whether the lights “stay on.” Staying on and staying correct are different guarantees, and only one of them protects your crop. Push for a specific answer on what happens to that target, and check whether the fallback behavior is configurable. A propagation room and a flowering room have different tolerances for a stale lighting plan, and a system that lets you set that per zone is doing more engineering work than one that applies a single global default.

Reconnection behavior deserves the same scrutiny. A platform that floods your network with every cached data point the moment the link returns can create a second outage right behind the first one, especially across a large facility with thousands of fixtures reporting at once. The control-lease research above solves this with staged, priority-ordered recovery. A vendor who has thought about the outage has usually thought about the recovery as well; one who hasn’t usually hasn’t.

Cost is the last piece. Edge hardware, local processing capacity, and battery or capacitor backup for a gateway all add bill-of-materials expense that a purely cloud-dependent fixture doesn’t carry. None of the manufacturers referenced here publish a price premium specifically attributable to edge resilience, so treat any vendor’s answer on this point as a number to verify against your own quote, not a published industry figure.

None of this makes cloud-first architecture wrong. For a lot of operations, the convenience and update cadence of a fully cloud-managed platform outweighs a few hours of theoretical exposure a handful of times a year. But it’s now a real line item in a purchasing decision instead of an assumption nobody checked, the same way PPFD and DLI became standard vocabulary once growers stopped trusting wattage as a proxy for light output.

Check the grow light directory for verified specs on manufacturers building both cloud-first and edge-resilient control into their fixtures before your next purchase.