A site loses its mobile connection overnight. The inverter and battery controller continue operating, but the cloud dashboard stops receiving fresh readings. An operator needs to know which protections, records and decisions still work at the site—and which will wait for the connection to return.
That is the useful starting point for edge computing. A computer near the equipment can collect data and run selected checks locally. It does not make every cloud function available offline, and it does not replace the equipment's protection systems.
This article gives operators a way to evaluate an offline design. The outage below is illustrative, not a report of a Gen318 deployment.
Walk through a communications outage
At 02:00, the cellular link drops. A local collector continues reading the supported equipment and storing readings with their source times. A configured rule flags an abnormal operating trend. The event is kept locally, along with the evidence behind it.
If an authorised person is on site, a local interface may make the event visible. If nobody is present and every remote communications path is down, the cloud operator cannot receive a new alert through that disconnected link. The system should make this limitation explicit.
At 08:00, connectivity returns. The collector uploads the backlog without duplicating readings already delivered. The cloud distinguishes when the event happened from when it was received. The operator can see the outage, the delayed evidence and any readings that were never collected.
Local collection preserved part of the record. Whether the system also made a control decision is a separate question.
Four functions with different authority
| Function | What it does offline | What to establish |
|---|---|---|
| Equipment protection | Enforces the device's designed electrical and thermal limits | Manufacturer requirements and commissioned protection settings |
| Local monitoring | Collects readings and records selected events | Supported signals, cadence, storage and clock behaviour |
| Advisory | Recommends a response using local rules or models | Available inputs, uncertainty and who reviews it |
| Authorised control | Issues permitted commands within an approved operating envelope | Explicit enablement, interlocks, limits and fallback behaviour |
A monitoring article should not imply that an AI model safely handles thermal runaway by adjusting a charge controller. Protection belongs to the engineered safety system. Additional supervisory control needs a defined scope and validation for the equipment concerned.
Gen318 treats actuation as an explicitly enabled capability. A demonstration of local advisory should not be described as proof that autonomous control is active on a customer's site.
Choose the smallest useful computation
Many useful local checks do not need machine learning: missing readings, persistent threshold breaches and comparisons with an expected operating envelope can be implemented with rules or statistical methods.
A model may add value when the task requires recognising a pattern that simpler methods miss. Evaluate it against that alternative. Ask for the inputs it needs, its memory use and latency on the intended hardware, and its behaviour when measurements are stale or incomplete.
LiteRT and ONNX Runtime provide options for deploying inference on constrained devices. They do not establish a universal accuracy or speed improvement. Quantisation results depend on the model, data and hardware. A benchmark for a language model is not evidence of battery-fault prediction performance.
The buying question is therefore “Which local decision improves our operation?” rather than “How many AI models fit on this board?”
Check the integration at the equipment
Victron's GX Modbus-TCP documentation describes local integration options. Use the documented register map and access settings for the installed equipment. The existence of an interface does not authorise every write or guarantee every signal is present.
Apply the same discipline to other manufacturers. Confirm model, firmware, gateway and permitted read/write access. A cloud API connection is not evidence of an equivalent local interface. A fleet may need different integration arrangements at different sites.
Before procurement, ask for a signal list: what is measured directly, what is calculated, what is unavailable, and what changes when the internet drops. This list is more useful than a row of compatible-brand logos.
Budget for an installed system
The single-board computer is one cost item. A deployable node also needs suitable power, enclosure, cooling, storage, communications interfaces, installation and support. The earlier article's board-only price should not be read as an installed system quote.
| Cost or constraint | Question for the proposal |
|---|---|
| Hardware and installation | What is included in the installed price? |
| Storage | How many days fit at the configured cadence, and what happens when it fills? |
| Power and environment | How does the node handle loss of supply, heat and storage wear? |
| Communications | Which data is prioritised after reconnection, and what bandwidth does it need? |
| Lifecycle | Who updates, replaces and recovers the node? |
A retention promise needs a stated sampling rate, number of signals and storage policy. Keeping thirty days of data is different from operating for thirty days without power, maintenance or fresh forecasts.
Include the technician's offline workflow
The phone needs its own offline design. A site computer storing telemetry does not make a technician's cloud application usable without coverage.
Before travel, the technician should be able to download the assigned work, equipment history and relevant instructions. During the visit, the app should preserve observations and distinguish capture time from later sync time. After reconnection, it should make failed uploads and conflicts visible.
Test that workflow with airplane mode, an interrupted upload and a restarted phone. Check access expiry and local storage as well as the happy path. An “offline” badge is not an acceptance test.
A buyer's acceptance checklist
Disconnect the link during a supervised demonstration and record what happens:
- Which readings, alarms and local interfaces continue working?
- Which decisions require the cloud or a person?
- What happens to stale forecasts, clocks and full storage?
- Which controls are enabled, and what is their fallback?
- Does reconnecting preserve event order and avoid duplicate totals?
- Can the field team finish and sync its work with gaps declared?
Offline operation is a set of testable behaviours. Buy the behaviours your sites need, and require evidence that they survive disconnection and recovery.
Editorial note
Revised 4 September 2026. Replaced the safety-critical opening, removed unsupported hardware economics and universal benchmark claims, and separated protection, monitoring, advisory and control. The example describes an evaluation scenario, not measured Gen318 field performance.
Sector context: NREL's African micro-grid performance-monitoring review and AMDA's Benchmarking Africa's Minigrids report. The acceptance tests in this article remain recommendations rather than findings from those reports.