Off-Grid Solar PoE Design for CCTV and Wireless Networks

An off-grid PoE system for CCTV and wireless networks must be designed as one complete power-and-data chain. Cameras, radios, switches, converters, controllers and monitoring equipment all draw energy, while the wireless backhaul may require a separately powered station at the far end.

Continuous operation should be treated as a design objective—not an automatic result of combining a solar panel, battery and PoE switch. Start by defining essential services, calculate simultaneous loads, match every voltage interface, and test how the network behaves through darkness, low-battery shutdown and automatic restart.

Define network services and availability targets

Before selecting equipment, identify what the remote site must continue doing when available energy falls below the normal operating level. Not every connected device needs the same priority.

A practical service definition should cover:

Number and type of fixed cameras
PTZ cameras, illuminators, speakers or other higher-load devices
Local recording, if any
Wireless backhaul equipment
Network management and monitoring
Environmental or enclosure equipment
Required operation during extended poor charging conditions
Acceptable interruption and recovery behaviour

Continuous availability does not necessarily mean that every device must run without interruption. It can mean preserving the most important camera and communications path while temporarily disconnecting secondary loads.

Service class	Example equipment	Typical design objective
Critical	Main entrance camera, backhaul radio, network switch	Keep operating for as long as practical
Important	Perimeter cameras, local recording device	Retain unless battery reserve reaches a defined threshold
Deferrable	Auxiliary views, lighting, non-critical sensors	Disconnect first during low-energy conditions
Recovery-dependent	PTZ camera, radio or recorder requiring a clean restart	Restore in a controlled sequence after power returns

For each critical service, define an acceptance target. For example, a hypothetical project might permit secondary cameras to shut down at a low-battery threshold but require one overview camera and the wireless uplink to remain online. These are project assumptions, not guaranteed operating results.

Also define how much interruption is acceptable. A site that can tolerate a five-minute restart window has different control requirements from one expected to recover within seconds. Confirm whether recording gaps, temporary loss of remote access or manual intervention are acceptable.

Draw the camera, radio and backhaul topology

A topology drawing should show both data flow and power flow. This prevents the common mistake of sizing only the camera station while overlooking the remote end of the wireless bridge.

A typical remote CCTV topology may follow this path:

Solar array → charge controller → battery → protected DC distribution → PoE switch → cameras and local wireless radio

The backhaul continues through:

Local wireless radio ⇄ wireless link ⇄ far-end wireless radio → upstream switch, recorder or internet connection

The far-end radio also needs a reliable power source. If that location is off-grid, it requires its own solar, battery, controller and protection design. If it is connected to mains power, consider what happens when the mains supply or its local network fails. A working solar camera station is still unreachable if the opposite backhaul endpoint is offline.

The Maxsol CPE295 5.8GHz wireless CPE is one possible backhaul component. Its documented context includes 5.8GHz operation, a 2×2 14dBi directional MIMO antenna, one Gigabit LAN port, IEEE 802.3af/at or 9–48V DC power support, and 6.5W full-load consumption. These details help with interface planning, but product range or wireless-rate labels do not guarantee field distance or usable application throughput. Line of sight, mounting alignment, interference, obstructions and applicable local radio rules still need to be checked.

Map simultaneous port loads

Do not total device nameplate figures without also identifying which loads can operate at the same time. Night-time infrared activation, PTZ movement, heaters or auxiliary outputs may raise consumption above daytime levels.

The following is a hypothetical planning example, not measured system performance:

PoE connection	Planning assumption	Simultaneous load
Four fixed cameras	8W each	32W
One PTZ camera	25W	25W
One backhaul radio	6.5W	6.5W
Total powered-device load	—	63.5W

This 63.5W figure is only the PoE device load. Battery-side calculations must also consider the switch’s own consumption, conversion losses, controller consumption, monitoring hardware and any other DC loads. Allowance may also be needed for device start-up demand and future expansion.

Use the detailed process in the guide to calculating a PoE power budget for security cameras rather than treating the switch’s headline PoE budget as the complete solar load.

Plan bandwidth separately from power

A system can have enough electrical power but still deliver poor video because the backhaul is undersized or unstable.

For a hypothetical bandwidth example, five cameras averaging 4Mbps each would generate 20Mbps before allowing for protocol overhead, bitrate peaks, management traffic, retransmissions or additional services. Actual camera traffic depends on resolution, frame rate, codec, scene activity and recording configuration.

Check:

Aggregate average and peak camera bitrate
Throughput required for live viewing and recording
Whether video is transmitted continuously or only on events
Wireless signal quality in both directions
Interference and channel availability
Recorder traffic, firmware updates and remote administration
Failover behaviour if the wireless link drops
Capacity at the far-end switch, recorder and internet connection

Do not design around the radio’s labelled wireless rate alone. Validate actual application throughput during commissioning using the intended channel, mounting locations and video configuration.

Match switch, battery voltage and per-port interfaces

Voltage compatibility is a pass-or-fail design requirement. Matching watt-hours or total wattage does not make two devices electrically compatible.

The Maxsol CS12060 120W, 60Ah, 768Wh solar system documents a 120W monocrystalline panel, a 12.8V 60Ah 768Wh LiFePO4 battery, an MPPT controller and three DC12V outputs. RS485 is optional.

By comparison, the Maxsol IOT2802SFG-S managed solar industrial PoE switch documents PV and battery input at DC22–29.2V. It also 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.

These products are alternative architecture examples, not a validated bundle. A 12.8V battery or DC12V output must not be connected directly to a switch requiring DC22–29.2V.

Possible architecture paths include:

Architecture	Main selection issue	What to verify
12.8V battery with 12V-native network equipment	Whether all active devices accept the available voltage	Input ranges, current limits and PoE conversion method
Higher-voltage battery matched to a solar PoE switch	Battery and charging compatibility	Nominal voltage, full-charge voltage, charging profile and protection
12.8V battery with a DC-DC conversion stage	Conversion losses and failure points	Input/output range, continuous capacity, start-up demand and protection
Separate solar power and standard PoE subsystem	More components and wiring	Controller output, inverter or converter losses, grounding and restart behaviour

Do not choose a DC-DC converter only by its advertised maximum wattage. Confirm its continuous operating limit, thermal derating, efficiency across the expected load range, surge response and low-voltage shutdown behaviour.

Verify every PoE port and powered device

“PoE” is not enough information by itself. Record the required standard, voltage, polarity and maximum load for each device and port.

For ports 3–4 of the IOT2802SFG-S, verify the supplied configuration and actual port allocation before connecting equipment because these ports are documented as configurable for 24V or 48V PoE. Never assume that a camera or radio accepts both.

For each connection, confirm:

IEEE PoE standard or passive power method
Required voltage and polarity
Maximum normal and start-up consumption
Port-level power capacity
Total switch PoE budget
Cable length and conductor quality
Voltage drop under peak load
Outdoor connector and surge-protection arrangement
Whether power negotiation is required

The switch’s 120W PoE budget is not the same as the site’s complete DC input requirement. Likewise, the battery’s nominal 768Wh rating is not usable delivered energy. Conversion losses, controller behaviour, battery protection, temperature and permitted depth of discharge all affect available energy.

Verify the current datasheets and supplied configuration for controller PV voltage, current and power limits, battery charging temperatures, and protection settings. Where documentation differs, obtain clarification rather than selecting a value by assumption.

Plan monitoring, load priority and recovery

A remote site should report enough information to distinguish a power problem from a camera, switch or wireless problem.

Useful monitoring points include:

PV voltage and charging status
Battery voltage and low-voltage events
Switch input voltage
Per-port link state
Per-port PoE state and load, where supported
Wireless signal and link status
Camera reachability
Recorder connection
Enclosure temperature, when relevant
Time since the last restart
Repeated port or system reboot events

Managed switching is particularly useful where technicians cannot quickly visit the site. VLANs, port control, status information and remote troubleshooting can help isolate failures, although the exact functions available must be confirmed for the selected model. The comparison of managed and unmanaged PoE switches explains when those controls justify the additional configuration work.

Establish a load-shedding order

Low-battery protection should not disconnect equipment randomly. A deliberate priority sequence keeps the communications path available long enough to report the fault and maintain the most valuable camera view.

A hypothetical order could be:

Disconnect decorative or auxiliary lighting.
Disconnect non-critical cameras.
Limit or disconnect high-load PTZ functions.
Preserve the primary camera and backhaul radio.
Shut down remaining loads before the battery protection system reaches a hard cut-off.

Thresholds must come from the battery, controller and system design—not generic voltage values copied from another installation.

Define recovery logic

When solar charging returns, switching everything on simultaneously may cause a voltage dip and another shutdown. A staged restart is usually easier to diagnose and places less immediate demand on the power system.

A hypothetical recovery sequence could be:

Allow the battery to recover above a defined restart threshold.
Energise the network switch.
Wait for the switch to complete its boot process.
Start the backhaul radio and confirm the wireless link.
Start the critical camera.
Add remaining fixed cameras in stages.
Restore the PTZ camera and other higher-load devices last.
Confirm that monitoring and recording have resumed.

Use separate shutdown and restart thresholds where the controller permits it. This hysteresis helps prevent rapid cycling when battery voltage is close to the cut-off point.

Also decide whether individual PoE devices may be restarted remotely. Port cycling can recover some unresponsive equipment, but repeated automatic cycling can hide an underlying power, cable or firmware problem. Set a limit on restart attempts and generate an alert when that limit is reached.

Validate night operation and restart behaviour

Daytime commissioning alone cannot confirm an off-grid network design. During strong charging, the PV source may hide inadequate battery capacity, excessive voltage drop or unstable low-voltage behaviour.

Run a controlled commissioning sequence under representative load conditions.

Inspect the installation. Check polarity, cable labels, protective devices, grounding arrangements, connectors, weather sealing and strain relief.
Confirm open-circuit and operating voltages. Verify that each controller, switch and powered device receives voltage within its specified input range.
Start one load at a time. Record the input voltage and current as each camera and radio is connected.
Apply the expected simultaneous load. Activate night modes, PTZ movement and other high-demand functions where applicable.
Check data performance. View all required camera streams while testing wireless throughput and packet stability.
Observe battery-only operation. Confirm that the system remains stable after PV contribution falls away. Do not infer full autonomy from a short test.
Trigger a controlled low-voltage shutdown. Verify the intended load priority and ensure critical equipment disconnects before damaging or uncontrolled behaviour occurs.
Restore charging power. Confirm that the controller, switch, radio and cameras restart in the intended order.
Test communications recovery. Verify that cameras reconnect to the recorder and that remote monitoring resumes without manual configuration.
Review logs and alarms. Look for repeated link changes, port overloads, low-voltage events or unsuccessful restarts.

A restart test should include both brief interruptions and a complete shutdown. Some devices recover from a short power loss but remain offline after the battery has been disconnected for a longer period.

Night testing should also confirm image quality and power consumption with infrared illumination active. A camera that draws modest power during daytime setup may become one of the site’s largest loads after dark.

No single commissioning test guarantees 24/7 availability. Solar input varies, batteries deliver less than their nominal stored energy, and network services can fail independently of the power system. The purpose of testing is to expose weak interfaces and confirm predictable failure and recovery behaviour.

Handover and maintenance checklist

Provide the site owner or operations team with enough information to support the network without reconstructing the design.

Handover records

Final power-and-data topology
Port map and device names
Camera and radio IP addresses
VLAN and management configuration
PoE mode for every powered port
Battery and controller settings
Load-priority sequence
Shutdown and restart conditions
Wireless alignment and baseline signal readings
Expected camera bitrates
Administrative access procedure
Firmware and configuration versions
Backup copies of switch, radio and camera configurations
Labels for disconnects, fuses and protective devices
Commissioning measurements and test results

Routine maintenance checks

Inspect solar-panel cleanliness, shading and mounting condition.
Check outdoor cables, connectors and enclosure seals.
Review battery, charging and low-voltage event logs.
Confirm that all expected cameras are recording.
Compare wireless link readings with the commissioning baseline.
Investigate repeated PoE port restarts instead of treating them as normal.
Test remote access and alarm delivery.
Confirm that time settings remain synchronised across cameras, switches and recorders.
Repeat controlled restart testing after major configuration or equipment changes.
Recheck the power budget whenever a camera, radio or auxiliary load is added.

Common design mistakes include treating nominal battery watt-hours as usable energy, powering equipment from an incompatible battery voltage, forgetting the far-end backhaul load, relying on labelled wireless rates, and testing only in daylight. Avoiding these errors is more important than selecting components by headline capacity alone.

As a practical next step, compare the linked Maxsol examples against the project’s required port count, simultaneous load, wireless distance, input voltage, environmental conditions and management needs. Confirm every current datasheet and interface before treating any solar kit, switch and radio combination as compatible.