OEM alert reference

How alerts arrive from integrations, which provider keys apply, and what to expect per OEM

Alerts ingested from OEM and partner systems share the same Texture schema, but each integration differs in polling cadence, severity mapping, resolution behavior, and alert volume. Use this reference when tuning workspace alert configuration or investigating noisy fleets.

For the alert data model, REST operations, and visibility controls, see Alerts, Alerts API, and Alert configuration.

Provider key vs connection slug#

Two identifiers appear in documentation and the Dashboard:

Usually these match (e.g. enphase / enphase, sma / sma). When they differ, an OEM override toggled in the Dashboard may not hide alerts until the override key matches the stored provider value. See OEM overrides and filtering below.

Provider summary#

Manual and programmatically created alerts use other provider values (for example manual or values you supply when creating an alert).

SolarEdge#

Ingestion#

SolarEdge alerts primarily flow through SolarEdge Web Monitoring (POST-based site/account alert APIs) via the alert and OEM adapters. A separate SolarEdge Monitoring API v2 (GET /v2/sites/{siteId}/alerts, OAuth) exists for device-oriented monitoring; alert polling today is centered on the web monitoring integration.

Provider key#

• Dashboard slug: solaredge-web
• Stored Alert.provider: solaredge

When hiding SolarEdge alerts with OEM overrides, confirm whether your workspace stores solaredge on alert rows. If overrides use solaredge-web but alerts carry solaredge, filtering may not apply until keys align.

Severity and status#

In practice, many rows arrive with serverStatus unset, so status often follows the boolean fallback path. That can produce a mix of open and resolved states that do not match the SolarEdge UI verbatim.

Volume and operational quirks#

• High INFO volume — Low impact scores map to INFO; disabling INFO in workspace configuration is a common noise reduction step.
• Deduplication — The pipeline deduplicates alerts across sites and poll cycles; repeated upstream signals may collapse to a single Texture alert per logical condition.
• Rich OEM text — Titles and descriptions often include HTML and long remediation steps from SolarEdge; type / subtype are inferred via message mapping where possible.
• Upstream auto-clear — Some SolarEdge alert types clear automatically after sustained normal operation (for example, grid export conditions over 24 hours). Texture reflects status updates on subsequent polls.
• v2 API limits — The OAuth v2 alerts endpoint does not support date-range or pagination parameters; bulk historical backfill via v2 is limited compared to web monitoring.

Enphase#

Ingestion#

Enphase system alarms are polled per site through the alert adapter when Enphase connections are active.

Provider key#

• Dashboard slug: enphase
• Stored Alert.provider: enphase

Severity and status#

Severity may arrive as a JSON number or string depending on the API layer; the mapper normalizes both.

Volume and operational quirks#

• Moderate INFO share — Codes 4–6 map to INFO; tune severity filters if informational alarms dominate.
• Explicit resolution — Cleared upstream alarms move to RESOLVED when alarm_end_time is populated on the next poll.
• Title prefix — Ingested titles are often prefixed for traceability (e.g. enphase:…).
• Unknown severity codes — Codes outside 1–6 may fall back to INFO or fail ingestion depending on adapter configuration; monitor for new Enphase severity values after platform updates.

SMA#

Ingestion#

SMA alerts are ingested via provider-grant polling in the alert adapter and through the OEM adapter for connected sites.

Provider key#

• Dashboard slug: sma
• Stored Alert.provider: sma

Severity and status#

Volume and operational quirks#

• Duplicate status pings — SMA may emit repeated notifications for the same condition. The OEM path deduplicates high-frequency repeats; you may still see bursts after reconnects.
• Short-lived events — Rapid Appeared / Solved cycles can create multiple alert rows over time; use status filters in the alerts query for open-only views.
• Unknown labels — New level or occurrence strings may map to soft defaults (INFO / OPEN) or be dropped depending on adapter strictness.

Also Energy#

Ingestion#

Also Energy alerts are pulled via the Also Energy app integration (provider grant polling) in the alert adapter. Hardware and site metadata are resolved before alerts are published.

Provider key#

• Dashboard slug: also-energy (app / grant identifier)
• Stored Alert.provider: also-energy

Severity and status#

Severity and status are derived from Also Energy alert fields (alert code, title, and hardware state). Alert codes are mapped to Texture type / subtype where a known mapping exists.

Volume and operational quirks#

• Hardware-centric alerts — Many events relate to inverter/hardware faults and communications on monitored hardware.
• Grant-scoped polling — Ingestion runs in the context of Also Energy provider grants; sites without a valid grant do not poll.
• Feature gating — Alert adapter processing can be disabled per manufacturer via platform feature flags during cutover or maintenance (alerts may pause without changing workspace configuration).

Other OEM paths#

These integrations publish alerts through the OEM adapter with stable provider keys matching their manufacturer slug in most cases:

Treat entries in the Dashboard OEM list as the connection slug; verify provider on a sample alert when tuning overrides.

OEM overrides and filtering#

Workspace alert configuration hides alerts by OEM slug in the Dashboard. At runtime, filters compare overrides against Alert.provider, not the providerName / providerCode display fields.

Practical guidance:

1. Open an alert you want to suppress and note its stored provider in the Dashboard or via support tooling.
2. If Dashboard slug and Alert.provider differ, align the override key with the stored provider value, or hide by severity until keys match.
3. After saving configuration, confirm filtered alerts no longer appear in the Dashboard for that integration.

Reducing alert volume#

Related guides#

• Alerts — Overview and capture principle
• Alert configuration — Dashboard visibility controls
• Alerts API — List and filter alerts via REST
• Devices and OEMs — Connecting manufacturer accounts