Configuring Data Loggers

Data loggers are the bridge between the equipment at your plant and the Mirox platform: once a logger is configured, the Mirox-Agent starts polling that device on a schedule, normalizing every reading into a single metric vocabulary and streaming it into the platform. This guide walks you through adding a logger, mapping a discovered device to an adapter, confirming it responds with a live probe, and applying your changes — plus the limits of what onboards automatically.

Before You Start

A logger is configured against a network device that has already been discovered on the plant network. If the device you want isn't there yet, run a discovery scan first — see Managing Network Devices. You also need the secure connection to the plant to be up; the Agent reaches devices over the VPN tunnel.

Where Data Loggers Live

Every plant has a Data flow page where you manage its loggers and watch data come in.

Open in Mirox: Data flow — or open Your plants, pick a plant, and switch to the Data flow tab.

The page header shows live tiles for logger health (healthy vs. total), Agent availability, and network traffic, so you can see at a glance whether collection is working. The Data Loggers tab is where you add and manage loggers; the Apply changes button at the top right pushes your configuration to the Agent.

How Data Loggers Are Onboarded

Adding a logger is a guided flow built around a real conversation with the device. The platform opens a temporary read-only connection — a probe — so you can confirm the device responds and see its live readings before you commit anything. There are two ways into the flow:

Possible Loggers (auto-detected) — when a discovered device's vendor and type match a known adapter, it appears in the Possible Loggers table with the matching adapter pre-filled. This is the fast path.
Add Logger (manual) — when detection misses or misclassifies a device, the Add Logger button lets you pick any network device and an adapter yourself.

Either way, the same wizard runs and the same live probe confirms the device before you save.

Adding an Auto-Detected Logger

Open in Mirox: Data flow (or pick your plant under Your plants and open the Data flow tab).
In the Possible Loggers table, find the device you want. Each row shows the device name, IP, vendor/type, and the adapter the platform matched it to.
Click the + button on the row. The onboarding wizard opens with that device and adapter already bound.
Follow the wizard steps (below) and Save the logger.

Adding a Logger Manually

On the Data flow page, click Add Logger.
On the Pick device step, search the network-device list by name, IP, vendor, type, model, or description, and select the device.
Choose the adapter to use, then click Continue.
Follow the remaining wizard steps and Save the logger.

The Onboarding Wizard, Step by Step

The wizard is a single dialog with a sidebar of steps and a live agent-log strip along the bottom, so you can watch the Agent talk to the device the whole time. A connection badge next to the device name reports the probe state (Connecting, Probing, Idle, Error, Done). Which steps appear depends on the adapter:

Step	When it appears	What you do
Pick device	Manual add only	Choose the network device and adapter
Identity	Devices that need configuration	Confirm the device and adapter are correct
Credentials	Adapters that require sign-in	Enter the device username and password
Probe	Zero-config devices	Watch the live readings the device exposes
Map values	Generic loggers	Browse every raw value the device exposes and map each one to a known metric
Dry run	Generic loggers	Review the exact metrics your mapping would produce
Summary	Devices that need configuration	Review and save

Credentials and the Vault

If the adapter needs to sign in to the device, the Credentials step asks for a username and password. Credentials you have already stored for that device in the credential vault are offered here so you don't re-type them, and what you enter can be reused for proxy access later.

Janitza Needs No Credentials

Janitza meters onboard with no credentials at all. Huawei SmartLogger and Phoenix Contact controllers do need device sign-in, so the Credentials step appears for them even though they are otherwise zero-config.

Fronius can replace a feed-in meter

Small Fronius parks often have no dedicated grid feed-in meter. When onboarding a Fronius logger, enable the "Use as grid meter" option to publish the whole device's combined power and total energy as the park's main grid series — no separate meter needed.

SMA Power Manager lists its own devices

SMA Power Manager (the SMA Data Manager / ennexOS plant controller) onboards zero-config: sign in with an ennexOS user account and the manager reports every device it knows — component ID, name, product, serial number, IP address and firmware — automatically, so there is no component list to type. Three switches control what it collects: collect plant totals (turn off where a dedicated grid meter already measures them), collect inverter series, and exclude limit channels. An inverter that another logger already reads directly is withheld automatically — the Power Manager keeps reporting its derating reason, but not its telemetry, so nothing is published twice.

SMA Sunny Central keeps its identity

SMA Sunny Central (the legacy per-inverter web interface) also onboards zero-config. Where the same plant has an SMA Power Manager configured, the wizard resolves the Sunny Central's identity from the Power Manager's device list automatically, so the unit keeps the same component and history it already had.

blue'Log string monitoring is a wizard field

A blue'Log fronting string-monitoring hardware gets a string monitoring step: turn tracking on or off, pick which inverter the strings belong to, and set how often the string layer is read (every Nth cycle). When the logger already knows its inverter, that inverter is filled in for you; otherwise you choose it from the plant's inverters.

Sungrow Logger onboards zero-config

Sungrow Logger signs in with the same username and password as the logger's own web interface (SSL and ping behaviour are optional advanced settings). Alongside its inverters' readings, it also collects the logger's active fault list as alarms and reports each inverter's serial number, model, firmware and rated power automatically.

INTILION batteries: pick the unit type, and pair the identifier

An INTILION plant puts two different controllers on the same protocol: one plant controller for the whole site and one battery unit controller per storage unit. Pick which one you are onboarding under Unit type — neither carries a serial number, so this is the only thing that tells the platform what it is reading, and a wrong choice is refused rather than published.

For a battery unit controller, give the unit a battery unit identifier and use exactly the same identifier on the protection relay of that unit's medium-voltage feeder. The relay measures the grid side and the controller the battery side; matching identifiers make them one storage unit instead of two half-measured ones.

Running the Live Probe

The Probe step opens a short-lived dry run against the device. The Agent reads what the device exposes and streams live samples back — they refresh every second, and the bottom log strip shows the underlying exchange.

Wait until samples appear. The connection badge moves to Probing and then settles once readings are flowing.
If nothing arrives, the wizard retries automatically a few times. If it still can't reach the device, you'll get a clear message and a Reconnect button to try again.
A stalled probe almost always means the device isn't reachable from the Agent — check that discovery still sees it and that the VPN tunnel is up.

The Probe Is Read-Only

The probe never changes the device or saves anything by itself. It exists so you can confirm the device answers and see its real values before you commit the logger.

Mapping a Generic Logger's Values

Some loggers are generic — they expose a long list of raw values the platform can't interpret on its own (a power meter, a pyranometer, and a dozen other channels behind one device, each named in the device's own vocabulary). For these, the wizard runs an interactive mapping flow instead of a read-only preview:

On the Map values step the Agent enumerates every raw value the device exposes and streams them back with their group, name, unit, and a live sample. You get a searchable table.
For each raw value you care about, pick the known metric it represents from the dropdown. Leave the rest unmapped. You can invert a sign per value where needed; unit prefixes (kW, kWh, …) are rescaled to base SI automatically.
The Dry run step re-runs the device through your mapping and shows the exact metrics that would be produced — your accept/deny checkpoint.
Summary confirms what will be saved.

Advanced settings per value

Each mapped value has an Advanced settings panel, collapsed by default — most values need none of it. Open it when the device reports a value that has to be reshaped before it is published:

Factor — multiply the reading (e.g. an impulse counter whose every tick is worth 200 Wh). Applied on top of the automatic unit rescaling.
Limit high / Limit low — reject readings outside this range instead of publishing them. Use it for a device that emits an out-of-range spike when its input is unread.
Ignore values — drop specific raw readings entirely, comma separated (e.g. 0 for a counter that reports zero while its input is disconnected).
Invert sign — flip the import/export direction.

Leave a field empty and it is not applied at all. Anything you set is shown as a short badge (×200 · ≥-10000) on the value row and again on the Summary step, so you can check the whole mapping before saving.

Only the values you map are collected, and each raw value maps to exactly one metric.

Mapping Readings (Manual Override Adapters)

For non-generic adapters that still expose a configuration step, the Configuration step shows every reading the probe found and lets you choose which to collect, set the polling interval, and apply per-reading corrections (for example, inverting a sign). When you continue, the platform re-probes with your configuration so the Summary step shows the values exactly as they'll be stored.

Saving

On the final step — Summary for manual adapters, or the Probe step itself for zero-config devices — click Save logger (or Add for zero-config). The logger is saved as a pending change. Nothing reaches the Agent yet.

Applying Your Changes

New loggers, edits, and removals are staged until you publish them to the Agent in one batch.

Make all the logger changes you want.
Click Apply changes at the top of the Data flow page (it reads Apply N pending change(s) when you've queued some this session).
The Agent redeploys with the new configuration and starts collecting shortly after.

Apply Is Always Safe

You can press Apply changes at any time — if there is nothing new to publish, it does nothing. After a page refresh the pending counter resets to zero, so use Apply changes to be sure the latest configuration is live.

Managing Existing Loggers

The Data Loggers table lists everything configured for the plant, with search, sorting, and health per logger. The ⋮ action menu on each row lets you:

Edit logger — adjust the logger's configuration.
Edit network device — jump to the device on the Networking page to change its IP, credentials, SNMP, or proxy settings (these live in one place, not duplicated here).
Pause / Resume — temporarily stop collection for a chosen window (15 minutes up to 24 hours) and resume it. Useful during maintenance so a known outage doesn't raise events.
Remove logger — delete a logger you added through the wizard.

Removing or pausing a logger is also a pending change — remember to Apply changes afterward.

What Can Be Onboarded Through the Wizard

Three kinds of device onboard through the wizard:

Zero-config families — the adapter already knows the device's full reading set, so you only confirm the live probe and save. Today these include Janitza meters (no credentials needed), Huawei SmartLogger, Phoenix Contact controllers, SMA Sunny Central, SMA Power Manager, and Sungrow Logger.
Generic loggers — devices that expose arbitrary raw values the platform can't interpret on its own. These onboard through the interactive Map values → Dry run flow described above, where you bind each raw value to a known metric. QReader and blue'Log are onboarded this way.
Manual-add adapters — a family the platform reads in full but must never guess at. The WAGO PFC200 alarm PLC is the one today: it reads a site's alarm system contacts over read-only Modbus TCP with no credentials, but a WAGO is a blank controller every integrator programs differently and nothing on the wire says which program is running. It is therefore never offered in Possible Loggers — use Add Logger, choose the adapter, and set the integrator profile (abo_uegs today), optionally an alarm identifier and any contacts that are not wired. The live probe then shows each contact's state before you save.

Device families outside all three groups still work, but they aren't wizard-onboardable today: they need a per-device configuration that Mirox prepares and ships with the Agent. Treat onboarding automation as device-specific, not universal.

Your Device Isn't Listed?

If your equipment isn't covered by an existing adapter, Mirox builds one — often even for legacy gear or undocumented interfaces, as long as the device exposes its data somehow. Click Request logger support below the Possible Loggers table (the adapter picker in the wizard links to the same request); the plant and device details are attached automatically, and new device support is typically ready within a day.

Step by step: Request an Integration.

To understand how adapters speak each device's protocol, normalize units, and discover components, see the Data Scraper architecture page — this guide deliberately doesn't repeat it.

Migrating a Hand-Written Configuration

A small number of plants onboarded before the wizard existed still run on a hand-written configuration (a legacy overlay) instead of the configuration the platform would generate from their logger rows today. For these, Mirox system administrators have a migration view on the plant's Data flow → Agent config tab that shows what moving off the overlay would look like before anything changes:

the configuration the platform would generate without the legacy overlay,
a diff against the overlay currently live at the plant, and
per logger, whether the generator can already produce an entry for it and what is still missing (an unresolved inverter identity, a missing string-monitoring binding, an inventory that hasn't been captured yet, and so on).

From there, an administrator can re-probe an individual logger to fill in what's missing, clear the overlay, and deploy the generated configuration — without renaming any component or losing its history. This is an internal migration tool, not a customer-facing setting: it exists so the last hand-written plants can move onto the same generated configuration every other plant already uses.

Managing Network Devices — discover and classify the devices a logger is configured against
Configuring Components — map collected metrics onto inverters, strings, and combiner boxes
Data Scraper — how adapters collect, normalize, and forward your data
Request an Integration — ask Mirox to add an adapter for an unsupported device
Using the Proxy — open a device's own web interface in the browser using stored credentials