Zustandsdaten und Lebenszyklus-Ereignisse

Der Pass einer Batterie endet nicht am Werkstor. Zwei Arten von Informationen begleiten sie durch ihr Leben: Zustandsdaten, also der gemessene Gesundheitszustand und die Nutzung einer Einheit, und Lebenszyklus-Ereignisse, die festhalten, was mit ihr geschehen ist. Beides lässt sich über die API mit einem Schlüssel melden, der den Scope condition hat.

ZustandsdatenLink zum Abschnitt kopieren

Zustandsdaten sind die dynamischen Felder des Registers (der Abschnitt condition, Anhang XIII Nummer 4): Messwerte einer Einheit wie condition.capacity_fade, condition.remaining_capacity, condition.number_of_full_cycles oder, bei Elektrofahrzeugbatterien, condition.state_of_certified_energy. Welche Felder gelten, hängt von der Batteriekategorie ab; getCondition nennt sie in field_keys, mit ihren aktuellen Werten und measured_at.

Im aktuellen Register gehören alle Zustandsfelder zur Stufe legitimate_interest; im öffentlichen JSON erscheinen sie daher nie (Zugriffsstufen).

Messwerte statt deklarierter AngabenLink zum Abschnitt kopieren

Was ein Batteriemanagementsystem gemessen hat, kann ein Prüfer nicht besser beurteilen als das Gerät selbst. Eine Zustandsmeldung wird deshalb als Messung angenommen, ohne den Prüfschritt, den deklarierte Daten brauchen:

• Jeder Wert wird direkt als approved gespeichert, mit seinem measured_at, seiner source (api für einen Schlüssel, supplier für den Bericht eines Servicepartners, manual für ein Mitglied). Ein Mitglied steht in recorded_by, ein Schlüssel im api_key des Lebenszyklus-Ereignisses der Meldung (Werte nennen keinen Schlüssel).
• reviewed_at ist der Zeitpunkt der Annahme; einen Prüfer gibt es nicht, das Vier-Augen-Prinzip gilt hier also nicht.
• Jede angenommene Meldung erzeugt ein Lebenszyklus-Ereignis condition_update und einen Audit-Eintrag.

Zustandswerte, die ein Mitglied im Editor der Einheit eingibt oder per Tabelle importiert, durchlaufen weiterhin die normale Prüfung (Herkunft und Freigabe).

Eine Meldung sendenLink zum Abschnitt kopieren

updateCondition führt die gesendeten Werte mit den Zustandsdaten der Einheit zusammen:

curl -s -X PATCH "$BATTERYPASS_URL/api/v1/batteries/$BATTERY_ID/condition" \
  -H "Authorization: Bearer $BATTERYPASS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "measured_at": "2026-10-24T06:00:00Z",
    "note": "Wöchentliche BMS-Auslesung",
    "values": [
      { "field_key": "condition.capacity_fade", "value": 3.2 },
      { "field_key": "condition.number_of_full_cycles", "value": 412 }
    ]
  }'

Die Antwort nennt die angenommenen Werte (accepted), die übersprungenen (skipped), das erzeugte Ereignis (event) und das Ergebnis der Veröffentlichung (publication).

Regel für die NeuveröffentlichungLink zum Abschnitt kopieren

Ist der Pass der Einheit veröffentlicht, müssen angenommene Zustandsdaten in eine neue Passversion gelangen. Wann das geschieht, legt die Organisation in ihren Einstellungen im Portal fest (condition_republish, von getCondition als republish geliefert):

publication.outcome in der Antwort sagt, was geschehen ist:

Lebenszyklus-EreignisseLink zum Abschnitt kopieren

Ein Lebenszyklus-Ereignis hält fest, was an einem bestimmten Tag mit einer Einheit geschehen ist. Sie melden es mit createLifecycleEvent und lesen die Historie, das neueste zuerst, mit listLifecycleEvents.

Zwei weitere Arten zeichnet BatteryPass selbst auf: condition_update bei jeder angenommenen Zustandsmeldung und repurposed, reused oder remanufactured, wenn ein Mitglied im Portal eine Second-Life-Batterie anlegt.

Ein Ereignis hat occurred_on (ein Datum zwischen Herstellungsdatum und heute), optional eine description (bis zu 2000 Zeichen) und bis zu 20 evidence_ids, also Dokumente, die bereits in der Nachweisbibliothek liegen, etwa ein Reparaturprotokoll. Ereignisse, die ein Schlüssel meldet, tragen source api und nennen den Schlüssel in api_key.

Nächste SchritteLink zum Abschnitt kopieren