Connections and status

In Ampere, connection and status are separate concepts.

• Connection — whether a pairing is still enrolled
• Status — whether the asset is reporting, producing, charging, or reachable right now

Ampere exposes both, but they are different fields and different questions.

Connection is not status

A connection answers a lifecycle question: is this pairing still current?

In practice, an active connection usually means disconnectedAt is null. When something is unlinked, Ampere keeps the record and sets a disconnect timestamp so history stays queryable. Reconnecting either clears that timestamp or creates a new link.

Status answers an operational question: is the asset talking to Ampere and doing useful work now?

Status lives on later fields — for solar inverters mainly lastProductionState, and for other domains on latest charge, temperature, or meter snapshots. Absence of recent telemetry does not automatically mean the resource was unlinked.

A solar inverter can stay connected and send nothing. Night, clouds, a Wi‑Fi drop, a powered-off inverter, or a local pairing that never received live data all leave the connection active. Only status changes.

Note: isActive on users, group assignments, or schedules is unrelated. It is not “device online.”

Layers that look like connections

These links are independent. One can be true while another is false.

When a link is removed, history is usually retained: the record remains queryable with a disconnect timestamp rather than disappearing permanently.

Group membership

You enrol addresses into groups. That membership is itself a connection: active while the address is currently linked to the group.

Adding an address to a curtailment pool, or taking it out, is enrolment into the pool. It says nothing about whether a Sparky/Flint is present, whether a cloud device is linked, or whether an inverter is producing.

• An address can be in a pool with no local pairing and no devices yet.
• A Sparky or Flint can sit at a home that is in no pool at all.

Those links do not move together automatically. See Groups.

Local vs cloud device connections

Devices at an address arrive through two enrolment paths:

Both paths use the same enrolment semantics: disconnectedAt = null means still enrolled; a timestamp means unlinked.

Local pairing (Sparky / Flint)

When you list group addresses, the payload may optionally include an active sparky or flint identity. That embed is a convenience for the current local pairing, not a second group membership.

• If sparky or flint is missing, there is no active local pairing.
• The address can still be in the group.
• After a swap or removal, historical local pairings may remain for past energy windows, but live paths use only the active pairing.

Cloud pairing

Cloud-linked devices attach straight to the address. They still have an enrolment lifecycle (disconnectedAt) and separate operational status fields. A cloud inverter can be enrolled with brand/model filled in long before any production snapshot arrives.

Chargers, batteries, vehicles, and similar assets follow the same broad pattern: enrolment first, live state second. Solar inverters are the most common place this distinction matters, so the examples below stay there.

A device record is not a live session

Ampere creates a device record as soon as onboarding gets far enough to persist identity: address, vendor, brand, model, site name, and similar fields.

Those identity fields mean:

• the link was stored, and
• the device is (or was) enrolled.

They do not mean:

• Ampere has spoken to the device since,
• telemetry is flowing, or
• the device is generating energy right now.

Getting brand and model back without production is exactly this: onboarding stored the link. A live session may never have completed.

What “linked” means on device lists

A “linked devices” count is often taken from list endpoints such as:

GET /api/v2/addresses/{address_uuid}/solar-inverters

That number is not “fully onboarded and sending production.” It is “there is a device record for this address.”

Important behaviours:

• Solar inverter list/detail include disconnected history so past production, forecasts, and schedules still resolve.
• Counting results.length includes historical devices.
• Counting only disconnectedAt: null means “still enrolled.”
• Neither count means “currently producing.”

Production is a later, separate stream. lastProductionState can be missing, stale, or isProducing: false while the inverter remains on the list. A connection attempt that stored identity but never received data looks the same as a healthy pairing at night: linked, no production.

So:

• linked / connected = registry and enrolment
• live data = timestamped state and intervals
• presence on the list = wrong proxy for health

Status fields to use

Capability flags such as info.isSteerable or liveDataSupported describe what the asset can do in principle. They are not liveness.

Presence of telemetry and production of energy are also not the same:

• an inverter can be online and not generating
• an inverter can generate nothing and still be connected
• for curtailment, “can we reach and steer it?” is a telemetry question, not disconnectedAt

Until a dedicated health score is exposed on list payloads, recent production intervals (or other recent domain intervals) are the honest proxy for “this asset is sending data.”

Connected but not producing

Once connection and status are separated, these cases are ordinary:

Local pairing and device enrolment do not disconnect each other automatically. Removing Sparky/Flint may clear the optional sparky / flint embed on a group address while solar inverter rows at that address remain enrolled.

How to read Ampere without mixing the layers

Do not treat any one of those as “the device is online.” They stack. An address in a pool, a local Sparky/Flint pairing, a cloud link, and an inverter on the list can all be true while the device is dark.

Guidance

• Do not use list length alone as a health KPI.
• For enrolment and portfolio counts, use connection fields (disconnectedAt) and group membership.
• For health and freshness, use timestamped state fields and recent interval data.
• Model local and cloud as different pairing paths that share the same enrolment semantics.
• Keep audit history: disconnected does not mean “never existed.”
• Keep operator language precise: “enrolled”, “producing”, and “fresh telemetry” are three different claims.