Designing a 24/7 Solar Network for Remote UK Sites

A reliable 24/7 solar-powered network for remote locations must be designed as a complete energy, communications and maintenance system. Continuous operation depends on knowing every load, sizing generation and usable storage for the least favourable operating period, prioritising essential services, and planning how the site will detect faults and recover.

No solar kit, battery or network device can guarantee uninterrupted service by itself. The practical objective is to define acceptable availability, engineer for credible adverse conditions, and prove the design through a worst-month acceptance test before relying on it at an unattended site.

Define network services and an availability objective

Begin by defining what the remote network must continue doing when energy is limited. A site that carries one essential telemetry link has different requirements from a surveillance location with several cameras, wireless backhaul, recording equipment, lighting and environmental controls.

List the required services in priority order. A typical hierarchy might be:

Site controller, energy monitor and management connection
Primary backhaul or WAN connection
Critical security cameras or sensors
Secondary cameras and wireless access
Local recording, analytics or auxiliary equipment
Lighting, heating or other deferrable loads

Then define the availability objective in operational terms. “Runs 24/7” is not specific enough. Instead, answer questions such as:

Which services must remain active continuously?
Which loads may be switched off during low-battery conditions?
How many low-generation days should the site tolerate?
What maintenance response time is realistic?
Must the network recover without a site visit?
Is temporary loss of video acceptable if telemetry remains online?
What happens if solar input, a battery, a PoE port or the backhaul fails?

The resulting objective may be continuous operation of critical services, with staged shutdown of non-critical equipment when stored energy reaches defined thresholds. This is usually more achievable than treating every connected device as equally important.

Availability also includes communications resilience. A fully charged battery does not help if the radio path is obstructed, a switch locks up, or the remote endpoint cannot be restarted. Power and networking must therefore be designed together.

Inventory continuous, intermittent and startup loads

Create a load schedule using measured or manufacturer-specified consumption for every device. Do not size the system from PoE class, power-supply rating or maximum switch budget alone: those values may not represent normal energy use.

Separate the loads into three categories.

Load type	Examples	Design significance
Continuous	Switch, router, radio, essential camera, controller	Determines the core daily energy demand
Intermittent	Infrared illumination, pan-and-tilt movement, heaters, fans, lighting	Can increase consumption according to time, weather or events
Startup or peak	Radio boot, camera restart, motor movement, equipment power-up	May exceed normal demand and trigger protection or voltage drop

For each device, record:

Input voltage and acceptable voltage range
Average operating power
Credible maximum power
Hours of operation per day
Startup current or peak power
PoE standard and requested power, where applicable
Whether it is essential, deferrable or expendable
Whether it can be remotely restarted
Cable length and conductor size
Conversion stages between the battery and the load

Daily load energy can be estimated as:

Daily energy in watt-hours = device power in watts × operating hours

Add the daily energy for every device, then include losses from cabling, voltage conversion, PoE delivery, battery charge and discharge, and the controller. Use documented efficiencies where available rather than assuming that all energy leaving the solar panel reaches the network equipment.

Measure dynamic loads where possible

Outdoor network loads often change after installation. A camera may consume more when its infrared illuminators activate. A radio may draw differently under traffic. Cabinet fans or heaters can create seasonal demand precisely when solar generation is weakest.

Where practical, measure a representative assembled system across daytime, darkness, startup and high-activity conditions. If measurement is not possible, use defensible maximum values and state the uncertainty in the design record.

A useful companion is the guide to solar PoE switches for remote IP camera networks, which covers the relationship between solar power and PoE distribution in more detail.

Size worst-month storage, solar and recharge capacity

A remote system should be sized around the least favourable credible operating period, not the annual average. In the UK, shorter winter days, low sun angles, persistent cloud and changing weather can make average-year figures unsuitable for critical design.

Obtain project-specific solar resource data for the exact region, orientation and mounting conditions. Account for shading, panel angle, dirt, snow where relevant, controller limits, temperature and cable losses. Do not transfer a result from another site without checking these variables.

Distinguish nominal energy from usable delivered energy

Battery labels state nominal stored energy. The network receives less than that nominal figure because of:

Permitted depth of discharge
Battery management system cut-off limits
Temperature effects
Battery ageing allowance
Cable losses
DC conversion losses
PoE conversion and transmission losses
Energy reserved for recovery and control equipment

A simplified design relationship is:

Usable delivered battery energy = nominal battery energy × allowable discharge fraction × delivery efficiency

The allowable discharge fraction and efficiency must come from the selected battery, controller, converters and operating conditions. Avoid presenting nominal watt-hours as guaranteed network runtime.

The Maxsol 400W, 150Ah, 1920Wh solar system example documents two 200W modules, a 12.8V 150Ah LiFePO4 battery, MPPT control and four DC12V outputs. These are architecture inputs, not an uptime calculation. Actual delivered energy and recovery performance still depend on the site load, losses, solar conditions, controller settings and environmental factors.

Calculate autonomy and recovery separately

Storage autonomy asks how long critical loads can operate without useful solar input. Recharge capacity asks whether the array can both run the loads and restore the battery after a poor-generation period.

These are different tests. A large battery may provide long autonomy but recover too slowly from the available array. Conversely, a large array with insufficient storage may produce ample daytime power but fail overnight.

For each worst-month design case, calculate:

Critical daily load energy
Total daily load before shedding
Required usable storage for the chosen autonomy period
Expected daily solar energy under the selected design conditions
Energy consumed while charging
Surplus energy available for battery recovery
Estimated recovery time after the design discharge event

Recovery should not assume that all loads can be turned off while charging unless that is genuinely how the site will operate. The array must normally support active network loads at the same time as battery recharge.

Common errors include using panel wattage as daily energy, ignoring winter conditions, omitting conversion losses and selecting components only by nominal voltage. The guide to common off-grid solar design mistakes provides a further design checklist.

Design PoE switching, backhaul and load priority

The network topology should preserve critical communications while making controlled energy reduction possible. A managed PoE switch can help by separating loads, reporting faults and allowing selected ports to be disabled or restarted.

Specify the switch against:

Number and speed of copper ports
SFP or other uplink requirements
Total PoE budget
Maximum power required by any single powered device
Supported PoE modes and output voltage
Switch input-voltage range
Management and monitoring functions
Port restart and scheduling controls
Environmental enclosure and thermal design
Surge, earthing and lightning-protection strategy

The Maxsol 8GE and 2SFP managed solar industrial PoE switch documents eight Gigabit PoE ports, two SFP ports, a 120W PoE budget, 90W BT support, photovoltaic and battery monitoring, and configurable 24V or 48V PoE on ports 3–4. Its documented photovoltaic and battery input range is DC22–29.2V.

That voltage range creates an important compatibility boundary: a 12.8V solar kit is not a direct compatible input for a device requiring DC22–29.2V. The linked solar system and switch should therefore be treated as alternative architecture examples, not as a validated bundle. Any proposed design must verify battery voltage, controller output, converter behaviour, polarity, connectors and protection before components are combined.

Assign loads to energy-priority groups

A practical port plan might use four levels:

Priority 1 — control: energy monitor, management controller and essential communications
Priority 2 — core service: primary radio and critical camera or sensor
Priority 3 — normal service: secondary cameras and access points
Priority 4 — discretionary: lighting, non-essential coverage or maintenance equipment

Load shedding should remove Priority 4 first, followed by Priority 3 if the battery continues to fall. Priority 1 equipment should retain enough reserve to report the condition and control recovery.

Set separate thresholds for warning, shedding and shutdown. Avoid rapid cycling around a single threshold by using hysteresis and minimum off-times.

Engineer the wireless path, not just the radio

Wireless backhaul requires a site survey and link budget. Check line of sight, Fresnel-zone clearance, interference, channel planning, mounting rigidity, cable exposure and alignment tolerances. Seasonal foliage and future construction can change a path that appears clear during installation.

The Maxsol CPE295 5.8GHz wireless CPE example documents 5.8GHz operation, a 2×2 14dBi directional MIMO antenna, one Gigabit LAN port and 6.5W full-load consumption. Suitability for a particular link cannot be concluded from those details alone. Confirm the complete radio path, local spectrum requirements, required throughput, interference conditions, interfaces and power arrangement.

For important sites, also consider how technicians will reach the equipment if the primary backhaul is unavailable. Options may include a separate management route or a local service interface, but each additional communications device adds energy demand and complexity.

Monitor energy, faults and controlled recovery

Remote monitoring should show whether the site is healthy, deteriorating or already operating from reserve. At minimum, consider recording:

Panel or controller input
Battery voltage and, where available, current and state information
Load current or power
PoE port status and power use
Device reachability
Backhaul quality
Cabinet temperature
Door or tamper state where required
Restart, low-voltage and load-shedding events

A low-voltage alarm alone may arrive too late to be useful. Trend data can reveal gradual deterioration, such as reduced charging, increased night load, repeated port faults or a battery that no longer recovers as expected.

Define a controlled restart sequence

When energy returns after a shutdown, do not necessarily energise every device at once. Simultaneous startup can create an avoidable current peak and may leave insufficient power for stable recovery.

A staged sequence could be:

Start the controller and energy monitoring
Confirm that the battery has reached the recovery threshold
Start the core switch and management path
Restore the primary backhaul
Start critical cameras or sensors
Wait for stable operation
Restore secondary and discretionary loads only if the energy margin permits

Use separate cut-off and restart thresholds so the network does not repeatedly switch on and off during marginal charging. Record the reason for each automatic shutdown or restart.

Remote power cycling should also be rate-limited. Rebooting a faulty device continuously can consume energy without restoring service and may conceal the underlying fault.

Test handover and maintain the remote site

Commissioning must test the actual system rather than confirming only that each component powers up. Handover should include documented settings, cable schedules, port assignments, thresholds, access methods, firmware versions and recovery procedures.

Run a hypothetical worst-month acceptance test

A useful acceptance test can simulate the selected worst-month design case without claiming that the result predicts every future weather event. The test conditions and pass criteria should be agreed before installation.

A hypothetical test could include:

Establish the load baseline. Operate all intended devices and record daytime, night-time and peak demand.
Restrict charging to the design assumption. Use a controlled method appropriate to the test environment rather than waiting for conveniently poor weather.
Simulate low-generation days. Confirm that usable storage supports the specified critical services for the chosen design period.
Verify staged shedding. Check that non-critical ports disconnect in the correct order and that alarms are transmitted.
Test deep-discharge protection. Confirm that the system shuts down before exceeding approved battery or controller limits.
Restore charging. Verify that control and backhaul services recover before discretionary loads.
Measure recharge performance. Confirm that the array and controller can support active loads while returning the battery to the agreed recovery state.
Introduce network faults. Disconnect a radio, block an uplink or force a PoE fault to test alerting and remote restart behaviour.
Repeat after configuration changes. A revised camera, radio or threshold can invalidate an earlier result.

The acceptance report should state the simulated energy input, actual load profile, starting battery condition, ambient conditions, shedding events and recovery time. It should not turn one successful test into a universal uptime claim.

Plan maintenance access and spares

Even an automated remote site needs physical maintenance. Design the installation so that service work is safe, repeatable and possible in poor conditions.

The maintenance plan should cover:

Panel inspection and cleaning criteria
Vegetation and shading checks
Connector, cable-gland and enclosure inspection
Earthing and surge-protection inspection
Battery condition and terminal checks
Radio alignment and mounting checks
Alarm and shutdown testing
Configuration backups
Firmware change control
Review of load and charging trends

Hold spares according to the consequence of failure and the difficulty of reaching the site. Candidates include correctly configured switches or radios, controllers, converters, surge-protection devices, fuses, connectors and cable assemblies. Confirm storage-life requirements and configuration procedures rather than assuming a boxed spare will be ready to install years later.

Access time should influence the energy design. A location that can be reached within hours may justify a different reserve and spares strategy from one that becomes inaccessible during winter weather.

Final design checklist

Before approving a remote solar network, confirm that:

Every continuous, intermittent and startup load is documented
Critical and deferrable services are separated
Nominal battery energy is not being treated as usable delivered energy
The design uses project-specific worst-month solar assumptions
Storage autonomy and recharge time have both been calculated
All battery, controller, switch and converter voltage ranges match
PoE budget and per-port demand have been checked
Wireless suitability is supported by a site survey and link budget
Load-shedding thresholds and restart sequencing are documented
Remote monitoring remains operational during energy conservation
The complete system has passed an agreed acceptance test
Maintenance access, configuration backups and suitable spares are planned

The next step is to compare the linked Maxsol architecture examples against the project’s actual port count, load profile, link distance, power architecture, environmental conditions and management requirements. Verify every interface, controller limit and radio condition before treating any products as a complete system.