Neu: Die KI-Firewall überwacht jedes Modul und erklärt jeden Vorfall in einfachen Worten. So funktioniert es

Referenz für Alarmbedingungen

Wie Alarmbedingungen vergleichen – Operatoren, Zahlen versus Text, all/any-Gruppen, gerätespezifische Attributgrenzen, Topics und Regeln über mehrere Schlüssel.

Jede Schwere einer Schwellwertregel hat genau eine Bedingung. Eine Bedingung ist entweder ein einzelner Vergleich (ein Blatt) oder eine Gruppe von Bedingungen. Diese Seite beschreibt, wie Hermetry sie auswertet, damit Sie vorhersagen können, wann ein Alarm geöffnet wird.

Aufbau

Condition = { "key": …, "op": …, "value": …, "topic"?: … }
          | { "all": [ Condition, … ] }
          | { "any": [ Condition, … ] }

Das Formular bearbeitet einen Vergleich pro Schwere. Gruppen werden im JSON-Modus geschrieben.

Operatoren

opWahr, wenn
>der Wert größer als der Schwellwert ist
>=größer oder gleich
<kleiner als
<=kleiner oder gleich
==gleich
!=ungleich

Es gibt kein „zwischen“: Verwenden Sie all mit >= und <=. Es gibt keine Arithmetik: Eine Bedingung kann nicht „Sollwert + 10“ oder „mehr als der andere Sensor“ ausdrücken. Dafür berechnen Sie in einem Flow einen abgeleiteten Schlüssel (siehe Derived values) oder verwenden eine Formel der Regelkarte.

Wie Werte verglichen werden

Wert und SchwellwertVergleich
Beides sind Zahlen oder Text, der als Zahl lesbar ist ("23.5", "1e3")Als Zahlen. "80" und 80 sind gleich.
Alles andere mit == oder !=Als Text: true ist gleich "true".
Alles andere mit >, >=, <, <=Immer falsch.
Das Gerät hat null gesendet== ist falsch und != ist wahr.

Ein als Text gemeldeter Status funktioniert also mit ==: { "key": "state", "op": "==", "value": "fault" }. Boolesche Werte funktionieren ebenfalls: { "key": "door_open", "op": "==", "value": true } trifft auch auf ein Gerät zu, das "true" sendet.

Gerätespezifische Schwellwerte aus Attributen

Statt einer Zahl kann der Wert auf ein Attribut des Geräts verweisen:

{ "key": "temperature", "op": ">", "value": { "attribute": "max_temp" } }

Geben Sie im Formular unter Value attribute:max_temp ein.

  • Hermetry liest das Attribut mit diesem Namen aus den server-Attributen des Geräts und danach aus den shared-Attributen. Client-Attribute werden nicht verwendet.
  • Ein Gerät ohne dieses Attribut wird für diesen Vergleich nicht geprüft: Das Blatt ist falsch. Geben Sie jedem Gerät das Attribut oder fügen Sie eine zweite Schwere mit einer festen Zahl hinzu.
  • Ein geändertes Attribut wird innerhalb von etwa 30 Sekunden verwendet.

So kann eine Regel Geräte mit unterschiedlichen Grenzwerten bedienen. Legen Sie die Attribute auf dem Reiter Attributes der Geräte fest, per Import oder über die API. Siehe Attributes.

Gruppen: all und any

{
  "all": [
    { "key": "door_open", "op": "==", "value": true },
    { "key": "pressure", "op": "<", "value": 1.2 }
  ]
}
  • all ist wahr, wenn jeder Teil wahr ist; any, wenn mindestens einer wahr ist.
  • Gruppen können bis zu 4 Ebenen tief verschachtelt werden.
  • Die Bedingung einer Schwere darf insgesamt höchstens 16 Vergleiche enthalten.

Regeln über mehrere Schlüssel

Geräte senden Schlüssel häufig in getrennten Nachrichten. Eine Regel wird auf den zuletzt bekannten Werten des Geräts ausgewertet, nicht nur auf der gerade eingegangenen Nachricht:

  • Eine Regel wird nur bei einer Nachricht ausgewertet, die mindestens einen ihrer Schlüssel enthält (aus einem passenden Topic). Eine Nachricht ohne einen ihrer Schlüssel öffnet oder schließt sie nicht und zählt nicht als Probe für das Debounce.
  • Für einen Schlüssel, den die Nachricht nicht enthält, verwendet der Vergleich den letzten Wert dieses Schlüssels, den die Regel auf diesem Gerät gesehen hat.
  • Ein Vergleich, dessen Schlüssel die Regel auf dem Gerät noch nie gesehen hat, ist falsch.

Beispiel: Der Türstatus kommt jede Minute, der Druck alle zehn Sekunden. Die oben stehende all-Regel wird geöffnet, sobald beide wahr sind, unabhängig davon, welche Nachricht zuletzt kommt.

Die gespeicherten Werte werden zusammen mit dem Zustand der Regel aufbewahrt. Ein Gerät, das 30 Tage lang still ist, verliert diesen Zustand und beginnt neu.

Topic-Filter

Für Geräte, die auf eigenen MQTT-Topics veröffentlichen, kann ein Blatt auf ein Topic beschränkt werden:

topicDas Blatt gilt für
fehltNachrichten aus jedem Topic
"factory/line1/temp"Nachrichten genau aus diesem Topic
nullNachrichten nur aus den Standard-Topics

Derselbe Schlüssel auf zwei Topics zählt als zwei verschiedene Werte. Im Formular stellen Sie das unter Advanced > Only from topic ein. Siehe MQTT topics and payloads.

Schlüssel

Ein Schlüssel ist ein Telemetrie-Schlüssel: ohne Leerzeichen, keine reine Zahl, höchstens 128 Zeichen. Schlüssel unterscheiden Groß- und Kleinschreibung: Temperature und temperature sind verschiedene Schlüssel. Ein Schlüssel, den das Profil nicht deklariert, wird mit einer Warnung akzeptiert; ein zahlenähnlicher Schlüssel nur, wenn das Profil ihn deklariert.

Schweregrade

Bei mehreren Schweregraden werden alle Bedingungen bei jeder Nachricht ausgewertet, und die höchste wahre Schwere gewinnt:

"severities": [
  { "severity": "CRITICAL", "condition": { "key": "temperature", "op": ">", "value": 90 } },
  { "severity": "MAJOR",    "condition": { "key": "temperature", "op": ">", "value": 80 } },
  { "severity": "WARNING",  "condition": { "key": "temperature", "op": ">", "value": 70 } }
]

Bei 85 ist der Alarm Major; bei 95 eskaliert er zu Critical; bei erneut 85 kehrt er zu Major zurück (nach dem Debounce zum Schließen); unter 70 (minus der Hysterese) wird er geschlossen.

Was eine Bedingung nicht kann

Nicht möglichAlternative
Zwei Schlüssel oder zwei Geräte vergleichenEine Formel der Regelkarte oder ein Flow, der einen abgeleiteten Schlüssel schreibt
Tageszeit oder Kalender verwendenEine Regel der Regelkarte mit einem Zeitfenster
„Hat sich seit 10 Minuten nicht geändert“Ein Flow mit einem Watchdog- oder Delta-Block
Arithmetik im SchwellwertEin abgeleiteter Schlüssel oder ein gerätespezifisches Attribut
Ein Client-Attribut als Schwellwert lesenDen Grenzwert als server- oder shared-Attribut speichern