Monitoring systems for solar arrays and battery storage look, at first glance, like a standard IoT telemetry problem: sensors, a gateway, a cloud dashboard. What makes them different in practice is the deployment environment — often remote, sometimes without reliable grid power to run the monitoring hardware itself, and connected to safety-critical battery systems where the monitoring data isn't just informational, it can be the input to a protective action. Reliability requirements follow from that context, not from a generic telemetry checklist.
Sensor accuracy has to match what the data is used for
Energy metering accuracy requirements aren't uniform across every point in the system — a rough estimate might be adequate for a homeowner-facing production dashboard, but billing, incentive-program reporting, or grid-interconnection compliance can call for meter-grade accuracy with proper calibration and, depending on the jurisdiction and use case, certified metering hardware. Deciding accuracy requirements up front, per measurement point, avoids two failure modes: over-speccing every sensor to metering-grade accuracy when it isn't needed and inflating BOM cost, or under-speccing a sensor that turns out to feed a compliance or billing function it wasn't designed for.
Designing for intermittent connectivity, not around it
Remote solar and battery installations frequently have unreliable or intermittent connectivity — cellular coverage gaps, satellite links with limited bandwidth, or sites where connectivity was never a design priority for the original installation. A monitoring system built with an "always connected" assumption breaks down here: it either loses data during gaps or requires constant babysitting. The more robust approach treats connectivity as intermittent by default — buffering data locally with enough storage to bridge realistic outage windows, timestamping readings at the point of capture rather than at upload time, and reconciling gaps on reconnect rather than silently dropping them. This is a firmware and local-storage design decision made early, not a cloud-side patch applied after data loss becomes a support problem.
Integrating with the battery management system, not working around it
Battery installations already have a battery management system (BMS) responsible for cell-level monitoring and protection — the site monitoring system's job is usually to aggregate BMS data alongside inverter and production data, not duplicate what the BMS already does well. That means the integration surface with the BMS (whatever protocol and data model it exposes) is a first-class design input, not an integration detail worked out late. Treating the BMS as the authoritative source for cell health and safety state, while the broader monitoring system focuses on system-level visibility and trending, keeps responsibilities clean and avoids two subsystems disagreeing about battery state.
Edge processing versus cloud analytics
Not every decision needs a round trip to the cloud. Time-sensitive protective actions — cutting off charging on an over-voltage condition, tripping an alarm on a fault — need to happen locally, at the edge, independent of whether connectivity is available at that moment; waiting on a cloud round-trip for a safety-relevant action introduces exactly the kind of dependency that intermittent connectivity makes unacceptable. Cloud-side analytics are the right place for trend analysis, fleet-wide comparisons, and predictive maintenance signals that aren't time-critical. Getting that split right — what has to be a local, deterministic response versus what can be a cloud-side judgment made later — is one of the more consequential architecture decisions in a distributed energy monitoring system.
Practical takeaway
Reliable solar and battery monitoring is fundamentally a hardware and firmware design problem before it's a dashboard problem — accuracy requirements, connectivity assumptions, and the edge/cloud split all need to be decided against the specific deployment environment. See our embedded hardware work for how we approach that.