# Zustandsdaten und Lebenszyklus-Ereignisse > Wie gemessene Zustandsdaten ohne Prüfschritt in einen Pass gelangen, wie die Neuveröffentlichung geregelt ist und was Lebenszyklus-Ereignisse festhalten. 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. ## Zustandsdaten 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`](https://passport.kabin.sh/docs/de/api-reference/lifecycle/get-condition) 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](https://passport.kabin.sh/docs/de/concepts/access-tiers)). ### Messwerte statt deklarierter Angaben 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](https://passport.kabin.sh/docs/de/concepts/provenance-and-review)). ### Eine Meldung senden [`updateCondition`](https://passport.kabin.sh/docs/de/api-reference/lifecycle/update-condition) führt die gesendeten Werte mit den Zustandsdaten der Einheit zusammen: ```bash title="cURL" 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 } ] }' ``` | Regel | Wirkung | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Zusammenführen | Nur die genannten Felder ändern sich; `null` leert ein Feld. Höchstens 50 Werte je Anfrage. | | `measured_at` | Jeder Wert hat sein eigenes oder das der Anfrage. Es darf nicht in der Zukunft und nicht vor dem Herstellungsdatum der Einheit liegen. | | Ältere oder gleiche Messung | Ein Wert, der vor dem gespeicherten gemessen wurde, oder zur selben Zeit mit demselben Wert, wird übersprungen und in `skipped[]` genannt (`older_measurement`, `unchanged`). | | Alles oder nichts | Ein Feld, das kein dynamisches Feld der Einheit ist (`unknown_field`), ein ungültiger Wert oder zusammengeführte Daten, die eine feldübergreifende Prüfung nicht bestehen, lehnen die ganze Meldung ab. | 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öffentlichung 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): | Regel | Verhalten | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `immediate` (Standard) | Dieselbe Anfrage veröffentlicht die nächste Version, mit der Begründung `condition update` und ohne Mitglied als Veröffentlichenden. | | `daily` | Ein täglicher Job um 02:00 UTC veröffentlicht jeden veröffentlichten Pass, dessen Einheit nach der aktuellen Version Zustandsdaten erhalten hat; die Meldungen eines Tages ergeben so eine Version. | `publication.outcome` in der Antwort sagt, was geschehen ist: | `outcome` | Bedeutung | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | `published` | In dieser Anfrage wurde eine neue Version veröffentlicht. | | `unchanged` | Am Pass hat sich nichts geändert, es kam keine Version hinzu. | | `scheduled` | Der tägliche Job veröffentlicht sie. | | `blocked` | Die Veröffentlichungsprüfung hat abgelehnt (siehe `blockers`); die Meldung bleibt angenommen, und der Pass wird `update_needed`, bleibt aber online. | | `not_published` | Die Einheit hat noch keinen veröffentlichten Pass. | ## Lebenszyklus-Ereignisse Ein Lebenszyklus-Ereignis hält fest, was an einem bestimmten Tag mit einer Einheit geschehen ist. Sie melden es mit [`createLifecycleEvent`](https://passport.kabin.sh/docs/de/api-reference/lifecycle/create-lifecycle-event) und lesen die Historie, das neueste zuerst, mit [`listLifecycleEvents`](https://passport.kabin.sh/docs/de/api-reference/lifecycle/list-lifecycle-events). | Meldbarer Typ (`ReportedEventType`) | Typische Verwendung | | ----------------------------------- | ------------------------------------------------------------------------- | | `placed_on_market` | Die Batterie wurde in Verkehr gebracht | | `put_into_service` | Die Batterie wurde in Betrieb genommen | | `inspection` | Eine Inspektion oder Diagnose | | `repair` | Eine Reparatur | | `component_replaced` | Ein Modul, eine Zelle oder ein anderes Bauteil wurde getauscht | | `condition_update` | Eine Zustandsauslesung, die als eigenes Ereignis festgehalten werden soll | | `waste` | Die Batterie wurde zu Abfall | | `recycled` | Die Batterie wurde recycelt | | `custom` | Alles andere, beschrieben in `description` | 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`. > [!WARNING] > Ereignisse sind Aufzeichnungen: Sie ändern keine Daten der Einheit. Ein Ereignis `put_into_service` setzt nicht > das Datum `putting_into_service` der Einheit, und `waste` oder `recycled` ändert weder ihren Batteriestatus noch > beendet es ihren Pass. Messwerte melden Sie mit `updateCondition`; Daten der Einheit ändern Mitglieder im Portal. > Ereignisse lassen sich nachträglich weder bearbeiten noch löschen. ## Nächste Schritte [**Zustandsdaten senden**](https://passport.kabin.sh/docs/de/guides/push-condition-data): Messwerte aus einem Batteriemanagementsystem melden. [**Lebenszyklus-Ereignisse erfassen**](https://passport.kabin.sh/docs/de/guides/record-lifecycle-events): Reparaturen, Inspektionen und andere Ereignisse melden.