Engineering a 24/7 Solar Network for Remote Sites

A 24/7 solar powered network for remote locations must be designed as a complete energy and communications system, not assembled from products that look adequate on paper. Start with the services that must remain available, calculate energy at the actual loads, size storage and solar recovery for the worst design period, then define monitoring, load shedding and controlled restart behaviour.

The result is not a universal uptime promise. It is an engineering plan with stated assumptions, operating limits and acceptance tests. For remote New Zealand sites, the plan should also account for seasonal solar variation, difficult maintenance access, radio-path conditions, temperature, wind exposure and the time required to reach the site after a fault.

Define network services and an availability objective

Before choosing a panel, battery, switch or wireless bridge, define what the remote site is expected to do. “Keep the network online” is too vague because different services can have very different operational importance.

A remote surveillance and telemetry site might contain:

IP cameras and associated infrared illumination
A managed PoE switch
A point-to-point wireless bridge
Environmental or security sensors
A cellular router or secondary backhaul
Local storage or an edge recorder
Cabinet heating, ventilation or cooling
Lighting used only during maintenance
Remote reset and monitoring equipment

Classify these services by priority:

Service class	Typical purpose	Behaviour during low energy
Essential	Backhaul, one critical camera, alarm or telemetry path	Remains powered for as long as technically possible
Important	Additional cameras, secondary radio or local recording	Shed only after non-essential loads
Deferrable	Uploads, analytics, auxiliary sensors or scheduled tasks	Paused or limited during an energy deficit
Maintenance-only	Cabinet light, service socket or temporary equipment	Normally off and excluded from the continuous load

The availability objective should then state:

Which services must remain operational.
How long the site must operate without meaningful solar input.
What battery reserve must remain for protection and recovery.
Which loads may be shed, and in what order.
How quickly the system should recover after solar generation returns.
Which conditions are outside the design envelope, such as panel burial, structural damage, prolonged radio obstruction or failed batteries.

This objective becomes the basis for design acceptance. It also prevents an installer, network engineer and customer from applying different meanings to “24/7”.

Choose the service boundary carefully

Decide whether availability ends at the wireless radio, the remote switch, the network operations platform or an application server elsewhere. A solar site can remain fully powered while its service is unavailable because of a blocked radio path, upstream outage, damaged cable or configuration error.

The availability plan should therefore separate:

energy-system availability;
local Ethernet and PoE availability;
wireless or cellular backhaul availability;
application-level service availability.

Each boundary needs its own alarms and recovery procedure.

Inventory continuous, intermittent and startup loads

Build a load schedule from verified input power, measured consumption or conservative project values supplied by the equipment manufacturer. Do not size a solar system from PoE port count alone.

For each device, record:

normal operating power;
maximum expected power;
operating hours per day;
seasonal changes;
startup or inrush behaviour;
PoE class and required standard;
input voltage range;
whether consumption changes at night;
whether it can be switched or restarted remotely.

A camera, for example, may draw more power when infrared illumination, a heater, a wiper or pan-tilt motors operate. Wireless equipment may have relatively stable consumption, while cabinet fans or heaters can create temperature-dependent loads. An edge computer can also have a substantial startup peak even if its average consumption appears manageable.

Use separate calculations for continuous and intermittent energy:

Daily load energy (Wh/day) = sum of device power (W) × operating time (hours/day)

Add distribution and conversion losses separately. This includes losses in voltage conversion, PoE delivery, controllers, cabling and any inverter used by the architecture. Avoid applying one unexplained “safety factor” to everything; document each allowance so it can be reviewed later.

Measure at the correct point

Clarify whether a quoted figure is:

power consumed by the endpoint;
PoE output from the switch;
DC input to the switch;
battery-side consumption; or
energy drawn from the solar controller.

These are not interchangeable. The battery must supply the endpoint load plus all upstream losses.

Field measurement is preferable where practical. Test equipment in representative operating modes, including night operation, radio traffic, camera movement and cold starts. If final devices are unavailable, retain a clearly identified design margin and repeat the calculation once the bill of materials is fixed.

Do not overlook the site’s own energy overhead

Monitoring relays, DC converters, cabinet controllers and communication devices may seem minor individually, but they run continuously. At a remote site, a small permanent load can consume more daily energy than a larger device that operates briefly.

A detailed load table is one of the best protections against the common mistakes in off-grid solar design, particularly hidden loads, optimistic loss assumptions and insufficient winter recovery capacity.

Size worst-month storage, solar and recharge capacity

Solar sizing should use project-specific irradiation and environmental inputs for the site’s worst design month. Annual averages are unsuitable for a network expected to run through winter or extended poor weather.

For a New Zealand installation, site assessment may need to consider low winter sun angles, terrain shading, fast-changing weather, vegetation growth and coastal or alpine exposure. Use data appropriate to the actual coordinates and panel orientation rather than substituting figures from another region.

Distinguish nominal energy from usable delivered energy

A battery’s nominal watt-hour rating is not the energy guaranteed to reach network equipment.

A simplified design relationship is:

Usable delivered energy = nominal battery energy × permitted discharge fraction × temperature factor × conversion efficiency × ageing allowance

The values for these factors must come from the selected equipment, battery operating policy and site conditions. Do not assume all stated battery capacity is available, particularly if the design requires a protected reserve or operation at low temperature.

Likewise, calculate required storage from load-side demand:

Required nominal storage = daily delivered load × autonomy period ÷ combined usable-energy factors

Keep the two figures visible in the design report:

Nominal stored energy: the battery’s stated capacity.
Usable delivered energy: the estimated energy that can reach the loads within operating limits.

This distinction makes competing designs easier to compare and helps avoid unrealistic runtime claims.

The Maxsol CS400150 solar system is one architecture example. Its documented configuration uses two 200W modules for a 400W panel arrangement, a 12.8V 150Ah 1920Wh LiFePO4 battery, MPPT control and four DC12V outputs. Those figures describe nominal configuration, not site-specific autonomy or guaranteed daily energy. Loads, losses, winter conditions and reserve policy still have to be calculated.

Size for both daily replacement and deficit recovery

An array may replace the average daily load yet still be unable to recharge the battery promptly after several poor-solar days. Calculate two requirements:

Normal energy balance: enough delivered solar energy to support the daily load.
Recovery capacity: enough surplus energy to restore the battery within the required recovery period while the network continues operating.

A useful energy model is:

Daily battery recovery = delivered solar energy − operating load energy

If the result is only slightly positive during the design month, recovery from a deep energy deficit may take too long. If it is negative, the system will progressively discharge even though it produces some solar power each day.

Document panel tilt, orientation, shading horizon, controller limits, cable losses and permissible array configuration. Confirm that panel voltage and current remain inside the controller’s operating envelope across expected temperatures.

Design PoE switching, backhaul and load priority

The network architecture should support both communications and energy control. Managed PoE is especially useful where the system must shed individual devices, restart endpoints or retain critical services during a battery deficit.

A practical priority plan could be:

Keep the management controller and primary backhaul powered.
Retain the most important camera or sensor.
Disable secondary cameras or high-consumption functions.
Pause local processing or non-essential uploads.
Enter a minimum-service state before reaching the battery protection threshold.

A solar PoE switch design guide for remote camera networks can help with port budgeting, DC architecture and endpoint planning. For every proposed switch, verify:

total PoE budget under the intended input conditions;
per-port PoE capability;
endpoint PoE standard and power requirement;
DC input voltage and connector arrangement;
switch self-consumption;
management and remote restart functions;
surge and earthing design;
fibre, copper and SFP requirements;
behaviour after low-voltage shutdown.

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

That input requirement is an important compatibility check: a 12.8V solar kit such as the CS400150 is not a direct compatible input for a DC22–29.2V device. These linked products are alternative architecture examples, not a validated bundle. A system designer would need to select a compatible voltage architecture or properly engineered conversion stage while checking current capacity, efficiency, protection and controller limits.

Treat the wireless path as part of availability

Radio selection requires more than a distance figure. Confirm:

clear line of sight and Fresnel-zone clearance;
frequency suitability for the project;
antenna alignment and mounting rigidity;
expected interference;
channel planning;
Ethernet interface requirements;
power consumption;
surge protection and earthing;
configuration access after installation.

The Maxsol CPE295 5.8GHz wireless CPE documents 5.8GHz operation, a 2×2 14dBi directional MIMO antenna, one Gigabit LAN port and 6.5W full-load consumption. Its suitability still depends on the surveyed path, local interference, mounting conditions and the configuration of the opposite endpoint.

Avoid using a marketed distance alone as the basis for a link design. Terrain, foliage, antenna height, alignment and the radio environment can determine whether the backhaul remains stable.

Monitor energy, faults and controlled recovery

A remote solar network should report enough information to distinguish an energy shortage from a network fault. At minimum, consider monitoring:

PV voltage and charging state;
battery voltage and, where supported, state of charge;
load current or power;
controller warnings;
switch and port state;
endpoint reachability;
radio signal and link status;
cabinet temperature;
door or tamper state.

Set alert thresholds early enough for an operator to respond before a protection shutdown. A low-battery alarm that arrives only moments before the controller disconnects the load provides little operational value.

Use staged load shedding

Load shedding should be based on defined thresholds, delays and recovery conditions. It should not repeatedly switch equipment on and off around a single voltage point.

A typical control sequence is:

Issue an early energy warning.
Disable deferrable loads after a sustained low-energy condition.
Disable important but non-critical loads if the deficit continues.
Preserve the management path and essential service.
Shut down safely before the battery reaches its protection limit.

Use time delays and separate recovery thresholds to provide hysteresis. Where battery state information is uncertain, combine voltage, current, charge state and elapsed time rather than relying on a momentary reading.

Restart in a controlled order

When energy returns, do not reconnect every load simultaneously. A mass restart can produce a startup surge, pull the battery voltage down and trigger another shutdown.

A controlled recovery could:

stabilise charging and confirm battery recovery;
start the management controller and network switch;
restore the primary backhaul;
confirm remote connectivity;
enable essential endpoints;
reconnect lower-priority loads one at a time;
check that energy remains above the recovery threshold.

Record what happens if a device fails to restart. Remote PoE cycling, watchdog functions and individually controlled outputs can reduce the need for a site visit, but their behaviour must be tested with the actual equipment.

Test, hand over and maintain the remote site

Acceptance testing should prove the design logic rather than simply confirm that equipment powers on in sunshine. Use the final device configuration, production cabling and intended monitoring platform.

A practical handover test should include:

verification of every continuous and intermittent load;
measurement of battery-side consumption;
PoE operation at the required port loads;
radio throughput and stability checks;
alarm delivery;
staged load shedding;
low-voltage protection;
recovery and restart order;
loss and restoration of the backhaul;
remote reboot of selected endpoints;
inspection of earthing, cable entries and weather sealing.

Run a hypothetical worst-month acceptance test

Because waiting for naturally occurring worst-month conditions may be impractical, create a controlled test based on the approved energy model. This does not prove future uptime, but it can validate the design assumptions and control sequence.

For example:

Apply the expected worst-month load profile.
Begin at the project’s defined normal battery state.
Limit or simulate solar input according to the approved poor-weather scenario.
Confirm the system reaches each warning and load-shedding threshold in the correct order.
Verify that essential services remain available for the specified design interval.
Restore the modelled solar input.
Confirm that the system powers loads in the specified restart sequence.
Measure whether the battery recovers within the project’s required period while supporting the live load.

Record measured watts, watt-hours, threshold timings, environmental conditions and any differences from the model. If the test uses laboratory power supplies or simulated input, state that clearly in the handover documentation.

Plan maintenance before installation

Remote equipment still requires access. Design the site so technicians can safely inspect panels, batteries, connectors, cabinets, antennas and protective devices.

The maintenance plan should define:

inspection intervals based on site conditions;
panel cleaning and vegetation control;
battery health checks;
connector and cable inspection;
cabinet seal and condensation checks;
antenna alignment checks;
firmware and configuration control;
alarm testing;
spare holdings and replacement procedures.

Useful spares may include the controller, DC protection devices, configured network equipment, radio units, SFP modules, patch leads and approved connectors. The correct list depends on failure impact, travel time and how quickly each component can be replaced.

Maintain an as-built pack with wiring diagrams, IP addresses, port assignments, radio settings, load priorities, threshold values, credentials procedure, firmware versions and measured commissioning results. Store a copy somewhere accessible even when the remote site itself is offline.

Final design checklist

Before approving a 24/7 remote solar network, confirm that:

the essential service is explicitly defined;
all normal, intermittent and startup loads are included;
calculations use delivered energy rather than nominal ratings alone;
storage is sized for the required autonomy and reserve;
the solar array supports both daily operation and timely recharge;
winter shading and site-specific solar inputs have been assessed;
battery, controller, switch and load voltages are compatible;
PoE standards, port limits and total budget match the endpoints;
the radio path has been surveyed rather than assumed;
low-energy alarms and load priorities are documented;
shutdown and restart sequences have been tested;
maintenance access, spares and as-built records are available.

As a practical next step, compare the linked Maxsol architecture examples against your required port count, measured load, radio distance, DC power architecture, environmental exposure and management functions. Confirm every interface, controller limit and site radio condition before treating any products as a complete system.