Beispiele und Fehlersuche
Die folgenden fünf Regeln sind die des mitgelieferten Demo-Datensatzes (Wasserwerk). Sie sind vollständig und erprobt und eignen sich als Ausgangspunkt für eigene Regeln.
Alle Beispiele setzen voraus, dass die Signale eine Eigenschaft tragen, an der die Regel sie erkennt — im Demo-Datensatz heißt sie signal_role und liegt am Signal, während die Grenzwerte am Standort gepflegt und nach unten vererbt werden. Vier Standorte, vier Grenzwerte, eine Regel.
1. Grenzwert mit zwei Stufen und echter Hysterese
Der Klassiker: Pegel über dem am Standort gepflegten Grenzwert, kritisch ab einem zweiten Wert, und der Alarm geht erst 10 cm unter dem Grenzwert wieder zu.
| Feld | Wert |
|---|---|
| Ausführungsrhythmus | 0 * * * * ? (jede Minute) |
| Zeitbereich | now-15m bis now |
| Kritisch | values.size() > 0 && values.max() > props.level_max_critical |
| Hoch | values.size() > 0 && values.max() > props.level_max |
| Rückfallbedingung | values.size() > 0 && values.max() < props.level_max - 10.0 |
| Ausschlaggebender Wert | values.max() |
| Kontinuitätstoleranz | PT15M |
| Objekte | Eigenschaftsbedingung signal_role EQUALS level |
| Alarmtext | Pegel {{ signal.name }} liegt bei {{ values.max() }} cm |
| Handlungsempfehlung | Zulauf prüfen, bei weiter steigendem Pegel Abschlag öffnen. |
Wozu die Rückfallbedingung: ohne sie würde ein Pegel, der um den Grenzwert pendelt, den Alarm im Minutentakt auf und zu machen.
2. Mittelwert mit Anhebe- und Abfallverzögerung
Motortemperatur einer Pumpe. Eine einzelne warme Minute ist kein Alarm, und nach dem Abkühlen bleibt der Alarm noch eine halbe Stunde offen.
| Feld | Wert |
|---|---|
| Ausführungsrhythmus | 0 * * * * ? |
| Zeitbereich | now-15m bis now |
| Kritisch | values.size() > 0 && values.max() > props.motor_temp_max_critical |
| Hoch | values.size() > 0 && values.mean() > props.motor_temp_max |
| Ausschlaggebender Wert | values.mean() |
| Anhebeverzögerung | PT10M |
| Abfallverzögerung | PT30M |
| Kontinuitätstoleranz | PT15M |
| Objekte | signal_role EQUALS temp |
| Alarmtext | Pumpe {{ signal.name }} läuft mit {{ values.mean() }} °C |
Beachten Sie die Mischung: die kritische Stufe schaut auf das Maximum (eine einzelne Spitze ist kritisch), die hohe auf den Mittelwert (dauerhaft zu warm). Stufen dürfen verschiedene Aggregate verwenden.
3. Unterschreitung
Füllstand eines Hochbehälters unter dem Mindestwert. Eine Stufe genügt.
| Feld | Wert |
|---|---|
| Ausführungsrhythmus | 0 */5 * ? * * (alle 5 Minuten) |
| Zeitbereich | now-15m bis now |
| Mittel | values.size() > 0 && values.min() < props.tank_level_min |
| Ausschlaggebender Wert | values.min() |
| Kontinuitätstoleranz | PT15M |
| Objekte | signal_role EQUALS tank |
4. Datenausfall erkennen
Kein Wert im Fenster oder eine Lücke von mehr als 15 Minuten.
| Feld | Wert |
|---|---|
| Ausführungsrhythmus | 0 */5 * ? * * |
| Zeitbereich | now-30m bis now |
| Hoch | values.size() == 0 || maxGap() > duration(params.max_gap) |
| Parameter | { "max_gap": "900s" } |
| Kontinuitätstoleranz | PT15M |
| Objekte | Teilbaum eines Standorts und signal_role EXISTS |
| Alarmtext | Messreihe {{ signal.name }} unterbrochen |
| Handlungsempfehlung | Sensor, Gateway und Ingestion-Strecke prüfen. |
Drei Dinge sind hier bewusst so:
- Kein
values.size() > 0-Wächter, dennmaxGap()ist die einzige Funktion, die mit einem leeren Fenster umgehen kann — undvalues.size() == 0ist hier gerade der Alarmfall. - Die Schwelle steht in
params, nicht inprops: sie gehört zur Regel, nicht zum Objekt. Objekte mit unterschiedlicher Kadenz brauchen dagegenprops. - Der Selektor ist auf einen Teilbaum begrenzt. Eine Lückenregel über alle Signale erzeugt bei einem Ausfall der Datenstrecke eine Wand gleichartiger Alarme — genau das, was die Bündelung nicht abfangen kann, weil jedes Signal wirklich betroffen ist.
5. Langes Fenster für einen sichtbaren Tagesverlauf
Dieselbe Grenzwertfrage wie in Beispiel 1, aber über 24 Stunden. Der Alarm bleibt bestehen, solange die Überschreitung irgendwo in den letzten 24 Stunden liegt.
| Feld | Wert |
|---|---|
| Ausführungsrhythmus | 0 */10 * ? * * (alle 10 Minuten) |
| Zeitbereich | now-24h bis now |
| Mittel | values.size() > 0 && values.max() > props.level_max |
| Kontinuitätstoleranz | PT1H |
| Alarmtext | Pegel {{ signal.name }} erreichte {{ values.max() }} cm |
Ein langes Fenster ist ein anderes fachliches Versprechen als ein kurzes: „irgendwann heute" statt „gerade jetzt". Beide sind legitim — aber ein 24-Stunden-Fenster klärt seinen Alarm erst, wenn die Überschreitung 24 Stunden alt ist.
Meine Regel alarmiert nicht
Der Reihe nach prüfen:
- Ist die Regel aktiv? Der Schalter in der Regelliste.
- Überwacht sie überhaupt etwas? Prüfansicht öffnen und die Trefferliste ansehen. Ein Selektor mit einem Tippfehler im Eigenschaftsschlüssel trifft nichts, ohne einen Fehler zu melden.
- Stehen die erwarteten Objekte unter den Ausschlüssen? Eigenschaft fehlt heißt: ein von der Bedingung gelesener Schlüssel ist nirgends in der Kette gepflegt. Keine Messreihe heißt: keine Werte hinterlegt.
- Fehlt der
values.size() > 0-Wächter? Dann endet jeder Lauf ohne Werte im Fenster ohne Ergebnis — nicht als „nicht erfüllt". Prüfen Sie in der Vorschau die Zahl der Läufe ohne Ergebnis: ist sie hoch, liegt es fast immer hier. - Deckt das Fenster den Rhythmus ab? Sonst bleiben Strecken unbeobachtet, und der Alarm liegt genau in einer davon. Die Prüfansicht weist darauf hin.
- Wartet noch die Anhebeverzögerung? Sie greift erst über die Folge der Läufe — bei einem 10-Minuten-Rhythmus dauert eine Verzögerung von 5 Minuten mindestens 10 Minuten.
- Verwirft eine Datenlücke ständig den Fortschritt? Ist die Kontinuitätstoleranz kleiner als der normale Abstand zweier Messwerte, kommt keine Verzögerung jemals durch.
- Passen die Größenordnungen? Ein Grenzwert in Metern gegen Messwerte in Zentimetern liefert nie einen Treffer. Einheiten werden mitgeführt, aber nicht umgerechnet.
- Prüfen Sie es mit der Vorschau über einen Zeitraum, in dem der Alarm bekanntermaßen hätte entstehen müssen.
Meine Regel alarmiert dauernd
- Fehlt die Entprellung? Eine Anhebeverzögerung filtert einzelne Ausschläge heraus.
- Pendelt der Messwert um den Grenzwert? Eine Rückfallbedingung mit einem Abstand zum Grenzwert beendet das Flattern; eine Abfallverzögerung hält den Alarm zusätzlich offen.
- Trifft der Selektor zu viel? Ein leerer Selektor überwacht jedes Signal des Mandanten. Die Trefferliste sagt es.
- Ist das Fenster zu lang? Ein 24-Stunden-Fenster hält seinen Alarm einen Tag lang offen, auch wenn der Messwert längst zurück ist.
- Ist der Grenzwert an der falschen Stelle gepflegt? Ein weit oben in der Hierarchie hinterlegter Wert gilt für alle darunter. Einzelne Ausnahmen übersteuern ihn am Objekt — siehe dynamische Eigenschaften.
- Soll die Regel für ein einzelnes Objekt gar nicht gelten? Dafür ist die Ausnahmeliste da; sie ist billiger als ein Baum von Übersteuerungen.
Ich bekomme einen Alarm über die Regel selbst
Die Überwachung hat mehrfach hintereinander kein Ergebnis geliefert. Typische Ursachen:
- Die Zeitreihen sind nicht erreichbar — die Datenstrecke prüfen.
- Der Zeitbereich lässt sich nicht auflösen, etwa nach einem Tippfehler in
VonoderBis. - Die Bedingung scheitert an den Daten, z. B. ein Aggregat über ein textwertiges Signal.
- Das Fenster ist so groß geworden, dass es die Punktgrenze überschreitet.
Ein erfolgreicher Lauf setzt den Zähler zurück; der Alarm selbst bleibt und wird von Ihnen bearbeitet wie jeder andere.