Inverter Status Codes

Every inverter reports an operating status about itself — on-grid, standby, power limited, fault, and so on — in its manufacturer's own vocabulary. Mirox now records that status for every inverter it collects data from, decodes it per manufacturer into your language, and shows it next to the platform's own component states. You get the device's own word about its condition, without opening the manufacturer's portal or driving to the site.

What is recorded

• The raw manufacturer code, per inverter, every polling cycle (typically once a minute) — stored as its own time series next to the inverter's measurements, so a status can be looked up for any moment in the past and every change is on record.
• The device's own word, not a Mirox verdict. The status code is what the inverter says about itself. It is separate from the component states the Digital Twin derives from measured production, and from the health events the platform opens on its own evidence. Show them side by side; they answer different questions.
• No status is a gap, never a code. When an inverter sends no status — the logger cannot reach it, or the device reports "not available" — nothing is recorded for that moment. The platform never fills the gap with a state of its own.
• The meaning is the manufacturer's. The same number means different things for different makers (Huawei 512 is On-grid, an SMA 512 is something else entirely). Mirox therefore stores the manufacturer next to every reading and decodes with that manufacturer's table.

Beside the manufacturer's own word, Mirox also records one standard operating state for every inverter, translated from that manufacturer's code: producing, producing — limited by the grid operator or a setpoint, self-derating (the inverter is throttling itself to protect itself), idle (night, start-up checks, waiting), stopped by command, stopped by protection, fault, unreachable, or unknown. The same situation therefore reads the same on every make, so a park with four manufacturers can be scanned in one pass. The raw code stays visible beside it, and a code no decode table carries yet is shown as unknown together with its number.

Where you see it

On a park's Analysis → Inverters table and on Components → Inverters, the Status code column shows the decoded status text with the raw code underneath:

• the text is what an operator reads, in the interface language;
• the raw code is what a support ticket or the manufacturer's manual needs;
• a dash means the inverter has sent no status recently;
• Unknown code means the inverter reported a number the decode table does not carry yet — the number stays visible, and no meaning is guessed for it (see When a code is unknown).

The column can be sorted, so inverters that are not in their normal operating state come to the top. The reading is taken from the last polling cycles only; a status that is hours old is not shown as if it were live.

Supported manufacturers

Every decode table carries all six interface languages (English, German, French, Spanish, Italian, Portuguese) and is maintained centrally, so a state is worded the same in the interface, in notifications and in the AI assistant.

Examples

When a code is unknown

Manufacturers add states with new firmware. When an inverter reports a number the table does not carry yet, Mirox shows Unknown code together with the number, and keeps the reading — it is never dropped and never replaced by a guessed label. The decode tables are extended as new codes appear in the field; if you see an unknown code that matters to you, send the number, the manufacturer and the inverter model to support (or open a ticket) and it will be added for everyone.

Active alarm events

Beyond the operating status, Mirox takes the alarms and warnings a device raises about itself — an inverter's, and a battery converter's or container BMS's — into the park's events. Every such report is used twice, for two different questions: it is recorded exactly as the device sent it, and it is handed to Mirox's own monitoring as one more piece of evidence beside the measurements. Codes are decoded with the same per-manufacturer tables as the status, and the device's own wording and severity (critical, major, minor, warning) are kept with every entry.

• Two records, two purposes. When an inverter raises an alarm about itself — Huawei 2005 Fan abnormal, say — Mirox files a small device-reported alarm record for that inverter: opened the moment the device raises the code, closed the moment the device withdraws it, one record per code, carrying how often it came back. The severity the device assigned decides whether it reads as Inverter fault reported by device or Inverter warning reported by device (Battery fault reported by device / Battery warning reported by device for a battery). These records are a plain mirror of the manufacturer's own active list: they are never weighed against our measurements, they never move a health state or an availability figure, and the device's withdrawal is what closes them.
• The same report becomes an input for Mirox's own monitoring. In parallel the alarm is translated into Mirox's standard vocabulary and handed to the monitoring that already watches that inverter's measurements. One code drives exactly one lane, so one fact never gets two lifecycles — a thermal code feeds the temperature finding, an insulation code the insulation finding, arc-fault and residual-current codes a safety alarm, a report that the logger cannot reach an inverter that inverter's own Logger cannot reach inverter record (and from there, after an hour of daylight, a no-communication event), and everything Mirox has no measurement of its own for becomes an Inverter device fault (or a Battery device fault, which is also where a battery's communication reports stay). Inverter Events sets out the full routing.
• A blue service item, not a production alarm. A device fault stands on an inverter that is still producing, and it is shown that way: in maintenance blue in the event list, as a Device fault state on the analysis page, and counted by the blue wrench on the station row beside the four service findings. The inverter keeps being counted as producing everywhere on that page.
• Gating, so that a single blip never becomes an alarm. How long a code must stand before it opens an event depends on the severity the manufacturer itself attached — a fault-class code needs two consecutive checks, a warning-class one a second raise, and anything unlabelled falls to the cautious warning side. Arc-fault and residual-current reports are the exception in the other direction: an Inverter safety alarm opens on a single live report, day or night. See Inverter Events for the exact thresholds.
• Where the device's word confirms a Mirox finding. For the two classes Mirox also measures itself, the machine's report is corroboration: it strengthens the streak our own measurement is already building, and it can never block a clean verdict. The device's word confirms a finding on its own only where our own comparison cannot judge that inverter at all — a park that publishes no cabinet temperature, a logger with too few comparable units — and even there only at fault severity. For insulation it is currently the only route to a confirmed finding, because escalation on our own reading is deliberately switched off until the calibration is re-run around November 2026. There is no phase-imbalance or efficiency finding reachable from an alarm report at all: no manufacturer's list carries those conditions.
• One record, updated in place. If the inverter withdraws the fan alarm in the evening and raises it again the next afternoon, the event stays open and its count goes to 2 — never a second event. Opening it shows the reasoning and the Device reports table: each code with its count, the maker's severity word and its message, and a Live marker on the codes the device is still raising.
• Closing is Mirox's decision. A device that stops repeating its own fault has not been repaired — it has stopped talking about it. A withdrawn code therefore goes on hold and is released only by an independent check, by enough quiet days on which the failing part was actually exercised, by a ceiling on how long it may stand, or — for the classes somebody had to walk up to and reset — by the withdrawal itself. The counts per class are in Inverter Events.
• When the inverter stops producing — or stops answering — the production event takes the report over. The device fault is closed into the new Inverter production outage, which from then on carries every code the machine raises; the reachability record is closed the same way into an Inverter not communicating event. Either close is recorded as escalated, never as resolved. When the event itself closes, a successor record opens if a claim still stands. The codes are corroboration, never a cause — the hand-over is described in full on the events page.
• What never becomes a finding. Routine self-tests, and codes that only describe night or dusk (no energy fed in, DC voltage too low), are recorded but never open anything of ours — though they are quoted in the reasoning of other findings when they explain the situation. When most inverters of a park report the same grid word within minutes — a grid disturbance, a damp dawn — that is a property of the grid, and Mirox suppresses the opening of one finding per inverter. Inverter stopped by command, Inverter protective stop and Inverter self-derating are not read from the alarm list at all: they come from the inverter's operating state.
• Supported today: Huawei SUN2000 inverters behind a SmartLogger (both transports, Huawei's complete official alarm list); SMA Sunny Central — the SC-COM plant gateway's fault registers and the classic per-inverter web interface's event log; the SMA Data Manager / Power Manager's own paired message log (device not reachable, waiting for setpoints, device reports error, plus a few informational housekeeping notices); and the Sungrow Logger's active fault list (the SG-series grid-protection and fan-alarm codes, with any other code shown in the device's own wording until it is added to the decode table). Zebotec plant controllers report an operating state only and have no alarm list, so no alarm events are produced for them. Further manufacturers follow.
• Classic Sunny Central note: reading the event log requires the installer login; with a plain user login the inverter's measurements are unaffected but its alarms cannot be read.
• SMA Data Manager note: its message log only claims the inverters the manager itself monitors — an inverter read directly by its own Sunny Central reports its alarms through that route instead, so nothing is reported twice. Only a small share of its several thousand message tags is classed today; the rest are untranslatable, which means they open a device fault at Error level and nothing at Warn, and that no thermal, insulation or safety finding can be reached from this family.

Working with the data

• Component export. The status is available as the component raw metric comp_raw_inverter_vendor_status for the inverter component type in the Metrics Export API — one value per inverter and time step, the raw manufacturer code.
• Raw time series. In Grafana and MiroxQL the series is powerplant_inverter_vendor_status, labelled with inverter_id, inverter_vendor (the decode table) and inverter_model. Read it with the last value per inverter; never average or sum a status code — the result would be a state no device ever reported.
• AI assistant. The AI assistant and the MCP tools answer questions about an inverter's reported status and its active alarms from the same data and the same decode tables.

Related Features

• Inverter Events — every event an inverter can carry, what opens it and how it closes
• Component States — the platform's own, evidence-based state of every component
• Real-time Monitoring — live production data next to the status
• Data Loggers — which loggers and inverter families are supported
• Metrics Export API — exporting the status as a time series