PV Weather Station Offline Data: What Survives a Network Outage?

An outage is not one failure mode

PV weather station offline data are available only if a powered acquisition device records them locally and the configured software retains them. A solar panel, a 4G modem and a cloud dashboard do not, by themselves, establish offline recovery. For a NiuBoL station, specify the record interval, retention period and reconnection behavior, then test those functions with the selected logger and receiving server.

Separate a network outage from a measurement outage

A plant network can fail while the weather sensors and logger remain powered. In that case, local acquisition may continue if it has been configured to do so. A logger power failure is different: the system cannot be assumed to measure conditions while the acquisition equipment is off. The gap may remain unrecoverable even after communications return.

A third condition is a failed individual sensor while the logger and modem remain online. Other channels may continue normally, but the missing sensor value is not restored by a working internet connection. The receiving system should distinguish unavailable measurements from delayed valid records and from a current zero reading.

This distinction matters for PV performance analysis. A zero irradiance value inserted during a daytime outage can look like darkness or a severe weather change. Repeating the last good value can create the opposite problem: apparently steady sunlight during an unobserved period. Keep the quality and timing of each observation visible rather than filling gaps silently.

Know what is being recorded at the field station

The NBL-W-HPRS pyranometer supplies irradiance in W/m² for its configured sensing plane. The logger records the signal and may calculate interval statistics or integrate irradiation when that function is included. The pyranometer is not a historical weather database. Whether the observation represents a horizontal plane or a module plane depends on the installation, not on the presence of remote communications.

Use the same channel identity in local files and remote records. A station with horizontal and inclined pyranometers needs distinct names for those observations. If a delayed batch arrives after reconnection, its original measurement time and plane must remain attached. A recent upload time does not make an old measurement current.

Storage hardware is not a retention guarantee

The NiuBoL TG462 and TG462S provide local storage options and industrial acquisition interfaces. They can be configured for weather-station data collection and remote transmission. The storage capacity establishes a hardware resource; the project software determines what is written, how much remains available and what is sent after an outage.

Record size, sample interval, file overhead, event logs and space reserved for software all affect retention. As a planning example, a 200-byte record stored once per minute is 288000 bytes per day before overhead. Use the configured record format and allocated storage for the actual retention calculation; the example does not specify the TG462's record size.

Agree how delayed records enter the plant system

Current data and recovered historical data need different treatment at the receiver. The application should use the measurement timestamp to place a delayed observation in its historical interval, not overwrite a current live value merely because the old record arrived last. If duplicate deliveries are possible, test that they do not create duplicate irradiation contributions.

Keep a defined channel name, unit, timestamp and validity indicator with each record. For interval statistics, state the averaging or integration period as well. If clock synchronization is unavailable during a network outage, verify how the logger maintains time and how any later correction is recorded. Do not infer a timekeeping capability from optional GPS location support.

For MQTT or a customer-owned server, confirm the application payload and historical-upload method before ordering. A supported network protocol is not a promise that a particular SCADA database accepts historical batches automatically. Configuration or software work may be needed on either side of the connection.

Test recovery with a controlled network interruption

1. Record the normal local and server values, timestamps and channel definitions.
2. Interrupt the intended network path while keeping acquisition power on. Check that the local record continues at the specified interval.
3. Restore the connection and compare the recovered timestamps and values with the retained local records.
4. Verify that the receiving system handles duplicates and does not classify the historical batch as current observations.
5. Test a logger restart separately, using the approved procedure, to establish which records and settings survive.
6. Confirm how unrecoverable gaps are displayed and excluded from calculations that require valid data.

Keep the test within a controlled maintenance window so it does not interrupt operational equipment unintentionally. Repeat it on the installed communication route: a successful office Ethernet test does not establish recovery over the selected cellular service. Specify the required outage duration and record load rather than using an undefined short disconnection as proof of long-term retention.

Check power reserve separately from data recovery

A solar-powered station needs an energy budget for the logger, modem, sensors and losses. Communication demand can differ from acquisition demand. Battery reserve should be selected for the site's weather and usable capacity, not described as unlimited operation because a solar panel is present. A surviving network connection cannot replace missing acquisition power.

For a quotation, provide the sensor interfaces, acquisition interval, longest required offline period, destination server and available power. State whether recovery must be automatic or whether local export is acceptable. NiuBoL can then review the logger and software requirements separately from the sensors and power package.

Write a recovery timeline before disconnecting the network

Make the acceptance test a sequence the integrator can reproduce. Record the last successful upload, disconnect the mobile or Ethernet link while leaving station power on, and note the local logging interval. Reconnect after several scheduled records, then compare the received history with the logger clock. Check whether late records retain original observation times, whether duplicates are inserted and how a missing sensor is shown during the same interval. A screenshot of the live page after reconnection is not enough; the export must contain the delayed records in a usable order.

Repeat a separate test for power interruption if that failure mode matters at the site. A battery or panel may keep part of the equipment alive while a modem or accessory stops. State the expected behavior of each component and identify the period that cannot be reconstructed. The project can then price additional storage or power reserve against a real requirement rather than a vague claim that the station works offline.

Project Decision FAQ

Q1. Does a 4G PV station automatically retain data while offline?

No. The logger must remain powered and its configured software must write and retain local records. Confirm and test buffering and retransmission for the ordered system; cellular capability alone does not establish those functions.

Q2. Can historical records be recovered after total station power loss?

Records stored before the interruption may be recoverable if retained, but measurements not acquired while the system was unpowered cannot be recreated as actual observations. Test restart persistence separately from network-outage recovery.

Q3. Is 32 GB storage enough for a year?

Capacity alone does not answer that question. Calculate the actual record load, allocated space and file-management overhead, then confirm the required retention with the configured application. The Micro SD capacity limit is not a one-year retention specification.

Q4. Can our own SCADA receive delayed records?

Only if the logger's historical-transfer method and the receiver's ingestion logic are compatible. Agree payload, timestamps, channel identity and duplicate handling. Test a recovered batch before relying on it for performance reporting.

Q5. What should happen to irradiance during an unrecoverable gap?

Mark it as missing or invalid. Do not silently substitute zero or the last good value. Any estimated replacement should be identified separately from measured data and assessed for the intended calculation.

Q6. How long should the outage test run?

Long enough to cover the project's expected communication interruption and at least one configured logging cycle. Disconnect only the network first, then verify local timestamps and later backfill; test station power loss separately. The acceptance result should state what was measured, what was buffered and what could not be recovered, rather than a generic 'offline capable' label.

Q7. Should delayed records retain the original observation time?

Yes. A backfilled record needs its original observation timestamp and an identifiable arrival time or recovery status. If the receiving application replaces observation time with upload time, solar conditions will align with the wrong electrical interval. Include a deliberate outage in the integration test and compare both time fields after reconnection.

Q8. Who owns the local storage configuration?

Assign responsibility in the project scope. The sensor, logger, communications service and customer platform are separate parts of the chain; a purchase of weather sensors alone does not establish buffering or retrieval rights. Ask for the configured retention rule, export path and recovery demonstration before signing off on the station.

Summary

PV weather station offline data depend on powered acquisition, configured storage and compatible recovery software. Specify and test each part separately. NiuBoL irradiance sensors and TG462-series loggers can form the measurement chain, but an intact historical record requires more than a working modem or a large memory card.

NBL-W-SRS-Solar-radiation-sensor-instruction-manual-V4.0.pdf

NBL-W-HPRS-Solar-Radiation-Sensor-Instruction-Manual-V3.0.pdf