When a remote site's battery starts to sag through a long cloudy stretch, an all-or-nothing response is wasteful: either everything keeps running until the battery collapses, or a crude cutoff kills the whole site at once. Firmware load shedding is the smarter middle path, where the controller sheds non-essential loads one at a time as the voltage falls, dropping the least important things first so the most important thing, the telemetry, survives longest. This page distinguishes firmware-level shedding from the grid-scale electrical load shedding that shares the name, and lays out the priority ladder that lets a site ride through a bad stretch by giving up its luxuries before it gives up its heartbeat.
Firmware Load Shedding in one line: Firmware load shedding is a controller behavior that drops non-critical loads in priority order as the battery voltage falls, so the site sacrifices its least important functions first and keeps its core telemetry running as long as possible. Heaters, cameras, and other heavy discretionary loads are shed early, reporting frequency is reduced next, and the essential measure-and-report function is protected to the last. It is a firmware decision made at the site, distinct from the grid-scale electrical load shedding that sheds whole feeders to protect a power network.
The phrase load shedding is used in two very different worlds, and it helps to separate them at the outset. In the electrical grid, load shedding means a utility deliberately disconnecting whole feeders or regions to shed demand when generation cannot meet it, protecting the network from collapse by sacrificing some customers to save the rest. It is a large-scale, network-level action about matching supply and demand across a grid, and the loads being shed are entire slices of the served population.
Firmware load shedding at a remote site is a completely different scale and purpose. Here the controller on a single node watches its own battery voltage and, as that voltage sags toward trouble, switches off its own non-essential loads one by one to stretch the remaining charge. The goal is not to protect a grid but to keep one site alive, and specifically to keep its telemetry alive, through a period when the solar input cannot keep up with consumption. The decisions are made in the node's firmware, based on the node's own measured state, without any command from a central authority.
The two share a core idea, that shedding less important load preserves the ability to serve the more important load, but the mechanisms and stakes are otherwise unrelated. Grid shedding is about supply and demand balance measured in megawatts across a network; firmware shedding is about eking out amp-hours on a battery at one remote asset. Conflating them causes confusion, so when the topic is a solar-powered RTU riding through a cloudy week, the relevant concept is the firmware kind, where the controller manages its own dwindling energy by giving up functions in a deliberate order.
The heart of firmware load shedding is a priority ladder: an ordered list of loads from least to most essential, with a battery voltage threshold at which each is dropped. As the voltage falls through successive thresholds, the firmware sheds loads in order, starting with the ones the site can most afford to lose. The heavy discretionary loads go first because they consume the most and matter the least in a crisis. A trace heater keeping an enclosure warm, a camera, an auxiliary radio, or a local display are the kind of loads shed early, since none of them is the reason the site exists and each one buys back meaningful runtime when it is cut.
As the voltage continues to sag, the firmware moves up the ladder to loads it would rather keep but can still compromise. Reporting frequency is a favorite lever here, because stretching the interval between transmissions cuts the radio's averaged draw without going silent, so the site still reports, just less often. Non-essential sensing can be reduced too, sampling a low-priority point less frequently or powering it down entirely. The intent through this middle band is to shrink consumption progressively, matching the shrinking energy available, while preserving the site's ability to still measure and still tell the operator what is happening.
At the top of the ladder sits the core function that is protected to the last: taking the essential measurement and getting at least a minimal report out. Everything below it has been sacrificed to keep this alive, because a site that has gone dark tells the operator nothing, whereas a site that has shed everything but a slow heartbeat still confirms it is there and still reports the one value that matters most. Only when even this cannot be sustained does the final protective cutoff act to save the battery from destructive over-discharge. The ladder is what turns a dwindling battery from a cliff into a controlled descent, giving up capability gracefully rather than collapsing all at once.
For the ladder to work well it needs hysteresis, meaning the voltage at which a load is restored is set higher than the voltage at which it was shed. Without that gap the site would chatter, shedding a load, seeing the voltage recover slightly because the load is gone, restoring it, sagging again, and repeating, which stresses the equipment and wastes energy in the switching. By separating the shed and restore thresholds, the firmware sheds a load and keeps it shed until the battery has genuinely recovered a comfortable margin, then brings it back, so recovery from a bad stretch is smooth rather than a series of on-off bounces.
The order and thresholds of the ladder are a design decision that reflects what each site actually needs. A camera might be near the bottom at one site and higher at another where security is critical; a heater might be discretionary in a mild climate but closer to essential where freezing threatens the equipment itself. Getting the ladder right means understanding which functions the site can lose without defeating its purpose and which it must keep, and setting the thresholds so the important functions survive well into a bad stretch while the luxuries are surrendered early. A badly ordered ladder either sheds something important too soon or clings to a luxury until it drags the whole site down.
A cloud SCADA layer turns firmware shedding from a silent local behavior into an observable, tunable one. When a platform such as Merobix records which loads a node has shed, at what voltage, and how its reporting interval has stretched during a cloudy spell, an operator can see the site descending its ladder in real time and understand that a slower report rate is deliberate power management rather than a fault. That visibility also feeds the design: seeing which sites repeatedly reach deep into their ladders reveals where the solar and battery are undersized, and comparing shed events against the weather shows whether the thresholds are tuned to ride through the stretches the site really faces. The shedding becomes a managed strategy across the fleet instead of a mystery that only surfaces when a site unexpectedly goes quiet.
Grid load shedding is a utility disconnecting whole feeders or regions to balance demand against generation and protect the power network. Firmware load shedding is a controller at a single remote site switching off its own non-critical loads as its battery voltage sags, to stretch the remaining charge and keep its telemetry alive. They share the idea of dropping less important load to preserve more important service, but one operates at grid scale and the other at a single node's battery.
The heavy discretionary loads go first, because they consume the most and matter least in a crisis: things like trace heaters, cameras, auxiliary radios, and local displays. As the voltage keeps falling, the firmware stretches the reporting interval and reduces non-essential sensing. The core measure-and-report function is protected to the last, so the site keeps its heartbeat even after everything else has been sacrificed, and only a final protective cutoff acts to save the battery from destructive over-discharge.
Without a gap between the voltage that sheds a load and the voltage that restores it, the site would chatter: shedding a load, seeing the voltage recover a little because the load is gone, restoring it, sagging again, and repeating endlessly. That bouncing stresses equipment and wastes energy in the switching. Setting the restore voltage comfortably higher than the shed voltage keeps a load shed until the battery has genuinely recovered a real margin, so recovery is smooth rather than an on-off cycle.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.