> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/rules-engine/version-history-and-restore.md).
# Versionsverlauf
Durchsuchen Sie den Versionsverlauf von Regeln in Kilo IoT und stellen Sie jede frühere Version wieder her — vollständiges Audit darüber, wer was wann geändert hat.
Jedes Speichern — ob manuell, automatisch oder durch ein Sitzungsereignis ausgelöst — erstellt eine Version Ihrer Regel. Die Versionshistorie gibt Ihrem Team eine vollständige Prüfkette darüber, wie sich eine Automatisierungsregel entwickelt hat, wer sie geändert hat und wann. Wenn eine Änderung unerwartetes Verhalten einführt, können Sie jede vorherige Version wiederherstellen, ohne dabei etwas zu verlieren.
## Warum Versionierung in der Produktion wichtig ist
Automatisierungsregeln wirken sich direkt auf betriebliche Ergebnisse aus. Ein falsch konfigurierter Schwellwert, eine invertierte Bedingung oder ein fehlender Fallback-Zweig kann Fehlalarme erzeugen, echte Alarme unterdrücken oder Ihre Benachrichtigungskanäle überfluten. Die Versionshistorie bedeutet, dass Sie durch eine fehlerhafte Bearbeitung nie in die Enge getrieben werden. Sie können nachsehen, was sich geändert hat, eine bekannte gute Version wiederherstellen und erneut bereitstellen — ganz ohne die Regel aus dem Gedächtnis neu aufzubauen.
## Wo Sie es finden
Öffnen Sie eine Regel im **Bearbeiten** Bearbeitungsmodus und klicken Sie auf die **Verlauf** Registerkarte unter der Kopfzeile. Die Registerkarte „Verlauf“ ist nur Teil des Bearbeitungspfads. Wenn Sie gerade eine Regel unter `/rules/:id/view`anzeigen, wechseln Sie zuerst zu **Bearbeiten** . Die Verlaufsseite befindet sich unter `/rules/:id/edit/history`.
Über der Tabelle können Sie in einem Suchfeld Versionen nach folgenden Kriterien filtern:
* Versionsname
* Autor
* Speichertyp
## Versionshistorientabelle
Die Registerkarte „Verlauf“ zeigt eine Tabelle aller gespeicherten Versionen, sortiert mit der neuesten Version ganz oben.
### Spalten
| Spalte | Beschreibung |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Versionsname** | Eine menschenlesbare Bezeichnung für die Version. Standardmäßig der automatisch generierte Name. Direkt inline bearbeitbar. |
| **Datum & Uhrzeit** | Wann die Version gespeichert wurde, formatiert als „dd MMM yyyy, HH:mm“ |
| **Speichertyp** | Wie die Version erstellt wurde (siehe unten) |
| **Benutzer** | Das Teammitglied, dessen Sitzung die Version erstellt hat |
### Speichertypen
Jede Version dokumentiert, wie sie erstellt wurde:
| Speichertyp | Bedeutung |
| ---------------------- | ------------------------------------------------------------------------------------------------- |
| **manuell** | Der Benutzer hat auf die **Speichern** Schaltfläche ausdrücklich geklickt |
| **automatisch** | Periodische automatische Speicherung während einer aktiven Bearbeitungssitzung |
| **editor\_close** | Automatisch gespeichert, als der Benutzer den Editor verlassen hat |
| **Verbindungsabbruch** | Gespeichert, als der Browser geschlossen wurde oder die Verbindung unerwartet unterbrochen wurde |
| **session\_timeout** | Gespeichert, nachdem das Inaktivitäts-Timeout abgelaufen war und die Sitzung geschlossen wurde |
| **lock\_cleanup** | Von einem Hintergrundprozess gespeichert, als ein abgelaufener Lock erkannt und freigegeben wurde |
| **wiederhergestellt** | Diese Version wurde durch Wiederherstellung einer vorherigen Version erstellt |
Speichertypen helfen Ihnen, den Kontext jeder Version zu verstehen. Eine Reihe von „auto“-Einträgen gefolgt von einem „manual“-Eintrag zeigt, dass jemand aktiv gearbeitet und dann bewusst gespeichert hat. Ein „disconnect“-Eintrag zeigt, dass die Sitzung unerwartet beendet wurde — prüfen Sie, ob die Arbeit in dieser Version vollständig ist.
## Versionen umbenennen
Standardmäßig tragen Versionen automatisch generierte Namen. Sie können jede Version umbenennen, damit sie für Ihr Team aussagekräftig ist — zum Beispiel „Vor Gateway-Refactoring“ oder „Produktions-Baseline v3.“
Um eine Version umzubenennen:
1. Klicken Sie auf die **Stiftsymbol** neben dem Versionsnamen in der Verlaufstabelle.
2. Geben Sie den neuen Namen ein (bis zu 100 Zeichen).
3. Drücken Sie Enter oder klicken Sie an eine andere Stelle, um zu bestätigen.
Namensbeschränkungen:
* Maximal 100 Zeichen
* Darf den Namen einer anderen Version innerhalb derselben Regel nicht duplizieren
* Die Zeichen `<`, `>`, und `/` sind nicht erlaubt
Gut benannte Versionen machen es schneller, den richtigen Wiederherstellungspunkt zu identifizieren, wenn um 2 Uhr morgens etwas schiefgeht.
## Eine vorherige Version anzeigen
Um zu prüfen, wie eine Regel zu einem bestimmten Zeitpunkt aussah:
1. Suchen Sie die Version in der Verlaufstabelle.
2. Klicken Sie auf die **Augensymbol** (Anzeigen-Aktion) in dieser Zeile.
3. Der Editor öffnet einen schreibgeschützten BPMN-Viewer, der das Diagramm so zeigt, wie es in dieser Version existierte, auf einer Route unter `/rules/:id/edit/history/...`.
Bei der normalen Navigation entspricht das letzte Pfadsegment der ausgewählten gespeicherten Version aus der Tabelle.
In dieser Ansicht können Sie das Diagramm nicht bearbeiten oder ändern. Zwei Schaltflächen sind verfügbar:
* **Diese Version wiederherstellen** — Startet den Wiederherstellungsablauf (siehe unten)
* **Ansichtsmodus beenden** — Bringt Sie zurück zur Registerkarte „Verlauf“
## Eine Version wiederherstellen
Das Wiederherstellen einer Version macht sie zum aktuellen Zustand der Regel. Die Wiederherstellung überschreibt oder löscht keine Historie — sie erstellt einen neuen Eintrag oben in der Verlaufstabelle als aktuelle Version, und die zuvor aktive Version bleibt im Verlauf erhalten.
### So stellen Sie wieder her
1. Zeigen Sie die Version an, die Sie wiederherstellen möchten (klicken Sie auf das Augensymbol).
2. Klicken Sie auf **Diese Version wiederherstellen**.
3. Ein Bestätigungsdialog erscheint und erklärt, dass die Wiederherstellung eine neue aktuelle Version erstellt und die vorherige aktive Version im Verlauf bewahrt.
4. Klicken Sie auf **Wiederherstellen** um zu bestätigen.
5. Die Version wird als neue aktuelle Version mit dem Speichertyp „wiederhergestellt“ wiederhergestellt.
6. Die Plattform bringt Sie zurück zum Editor, wobei die wiederhergestellte Version als aktueller Entwurf angezeigt wird.
7. Die Registerkarte „Verlauf“ wird aktualisiert, um den neuen Eintrag oben anzuzeigen.
### Was nach einer Wiederherstellung passiert
* Die wiederhergestellte Version wird zur aktiven Version im Editor.
* Die Version, die vor der Wiederherstellung aktiv war, bleibt in der Verlaufstabelle erhalten — gespeicherte Arbeit bleibt über die Versionshistorie wiederherstellbar.
* Der neue Versionseintrag zeigt den Speichertyp **wiederhergestellt** und protokolliert den Benutzer, der die Wiederherstellung durchgeführt hat.
* Die wiederhergestellte Version ist ein Entwurf. Sie wird erst bereitgestellt, wenn Sie sie bauen und bereitstellen. Wenn das zuvor bereitgestellte Artefakt noch läuft, läuft es weiterhin mit der alten Logik, bis Sie einen neuen Build bereitstellen.
## Best Practices
* **Benennen Sie Versionen nach bedeutenden Änderungen.** Bevor Sie eine komplexe Regel refaktorisieren, speichern Sie manuell und geben Sie der Version einen wiedererkennbaren Namen. So haben Sie einen sauberen Wiederherstellungspunkt, falls das Refactoring schiefgeht.
* **Verwenden Sie Versionsnamen, um die Absicht zu dokumentieren.** Eine Version namens „Fehlender Fallback-Zweig für Luftfeuchtigkeit hinzugefügt“ ist viel hilfreicher als „Version 14“, wenn Sie Monate später durch den Verlauf scrollen.
* **Überprüfen Sie die Speichertypen vor dem Wiederherstellen.** Eine „auto“- oder „disconnect“-Version kann unvollständige Arbeit darstellen. Bevorzugen Sie nach Möglichkeit die Wiederherstellung aus einem „manual“-Speicher.
* **Vor dem Neuerstellen wiederherstellen.** Wenn sich eine bereitgestellte Regel fehlerhaft verhält, stellen Sie zuerst auf die letzte bekannte gute Version wieder her und bauen und bereitstellen Sie dann. Bearbeiten Sie die fehlerhafte Version nicht unter Zeitdruck.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/rules-engine/version-history-and-restore.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
