mal wieder Fachwissen gefragt

[peter-pan]

Frage:
Ändert sich denn der Wert des Items "Pufferspeichersensor_Temperatur" bzw. gibt es dieses Item überhaupt ? Gibt es dazu Meldungen im Logger ?

[Snatsch]

Ja es kommen Meldungen im Log wenn sich die Temperatur ändert.

Code: Alles auswählen

2021-10-25 21:55:15.169 [INFO ] [hab.core.model.script.Pufferspeicher] - Rule triggert ! Wert : 64.8 °C

[peter-pan]

Die Nachricht kommt aber nicht von der Regel, die du zuletzt gepostet hast, sondern von der anderen:

Code: Alles auswählen

rule "Pufferspeicher Nachricht"
when 
    Item Pufferspeichersensor_Temperatur changed 
then
    logDebug("warmwasser", "Rule getriggert! Wert : {} ", Pufferspeichersensor_Temperatur.state )
    if(!(previousState instanceof Number))
       logWarn("warmwasser", "kein gültiger Vergleichswert! Setze Wert unter 55.")
    val nPrev = if(previousState instanceof Number) (previousState as Number).floatValue else 50
    if(!(newState instanceof Number)) {
       logWarn("warmwasser", "Sensor Item liefert keinen gültigen Zahlenwert. Abbruch!")
       return;
    }
    val nNew = (newState as Number).floatValue
    if(nNew > 55 && nPrev <= 55) {
       logInfo("warmwasser", "Pufferspeicher hat Temperatur 55 °C überschritten! ")
       bPufferspeichersensor_Temperatur = true
       Meldung.postUpdate("Der Pufferspeicher hat die Temperatur 55 °C überschritten!")
    }
end 

Es könnte aber auch die erste Rule gewesen sein.

Der Log, den du bekommst ist ein LogInfo. Die Rule hier gibt aber ein LogDebug aus. Da passt irgendwas nicht ganz zusammen.

[udo1toni]

Nein, das ist eindeutig.

Code: Alles auswählen

2021-10-25 21:55:15.169 [INFO ] [hab.core.model.script.Pufferspeicher] - Rule triggert ! Wert : 64.8 °C
                                                       ^^^^^^^^^^^^^^
                                                    Dies ist der Loggername

In der zweiten Rule lautet der Loggername aber warmwasser, woran man erkennen kann, dass da etwas nicht so funktioniert wie vorgesehen.

Bist Du sichern, dass die Rule ordnungsgemäß geladen wurde?

[peter-pan]

Ich meinte ja nur, dass in der Regel von dir ein "logDebug" als erstes kommt und diese Regel hat er doch als "nicht laufend" gepostet. Aber vielleicht hab ich das ja nur falsch verstanden.

[Snatsch]

habe sie jetzt noch einmal neu geladen. mal schauen

[Snatsch]

Hallo Ich glaube die Meldung kommt von der Rule

Code: Alles auswählen

rule "Pufferspeicher hat 85 Grad ereicht"

when 
     Item Pufferspeichersensor_Temperatur changed 

then
    logInfo("Pufferspeicher", "Rule triggert ! Wert : {} ", Pufferspeichersensor_Temperatur.state )
    
    if(!(Pufferspeichersensor_Temperatur.state instanceof Number)) {
       logWarn("Pufferspeicher Gradzahl", "liefert keinen gültigen Zahlenwert")
       return;
    }
    if((Pufferspeichersensor_Temperatur.state as Number).floatValue > 85) {
       logInfo("Pufferspeicher", "hat Temperatur von über 85 Grad ereicht! ")
       Meldung.postUpdate ("Achtung der Pufferspeicher hat eine Temperatur von über 85 Grad !")

    }
end 

Die Rule mit den 55 Grad gibt keine Meldung aus

[peter-pan]

Wieviele Rules hast du jetzt eigentlich im Einsatz ?
1) rule "Pufferspeicher hat 85 Grad ereicht"
2) rule "Pufferspeicher Nachricht"
3) rule "Pufferspeicher hat 55 Grad ereicht"

Bist du auch sicher, dass du nicht evtl. die Rules doppelt angelegt hast ?

Kannst du die Rules in der jetzigen Ausprägung noch einmal posten ? Evtl. könntest du auch, der besseren Lesbarkeit halber, die Logger noch etwas spezifizieren, z.B.: Pufferspeicher55 statt Pufferspeicher, etc.

[udo1toni]

Das ist ohnehin nicht so ganz der richtige Weg, damit umzugehen.

Leider wird das nirgendwo in der Dokumentation hervorgehoben, aber es ist grundsätzlich nicht gut, mehrere Rules zu programmieren, die einen identischen Trigger nutzen. Besser ist es, in der Rule die weiteren Unterscheidungen zu programmieren.

Ursprünglich ging es ja aber um etwas anderes... Die Meldungen sollten nicht ständig wiederholt werden.
Dazu gibt es, wie erläutert, zwei Möglichkeiten.
Die erste Möglichkeit nutzt einen Merker. Wenn die Nachricht versendet wird, wird der Merker gesetzt. Wie das geht, habe ich in diesem Posting viewtopic.php?p=37083#p37083 in der ersten Variante gezeigt.

Möchte man noch weitere Schwellwerte für die Alarmierung vorsehen, muss man für jeden einzelnen Schwellwert einen Merker anlegen und in der Rule entsprechend prüfen, ob der Merker gesetzt ist oder nicht. Alternativ könnte man auch mit einer Zahl als Merker arbeiten, da die verschiedenen Warnungen ja definitiv nacheinander auftreten werden.

Die zweite Möglichkeit nutzt previousState, um gezielt zu prüfen, ob der Grenzwert beim aktuellen Durchlauf überschritten wurde. Der Punkt ist hier, dass man sich nicht merken muss, ob man die Botschaft versendet hat. Stattdessen wird geschaut, ob der letzte Wert unter dem Grenzwert und der aktuelle Wert über dem Grenzwert liegt. Nur wenn beide Bedingungen erfüllt sind, wird die Nachricht versendet. Dies erspart den Merker.
Wie das funktioniert, habe ich in der 2. Rule im gleichen Posting erläutert.

Nun geht es um die Meldungen im Log. Dazu muss ich nochmal ausholen, um wieder mal (aber ich werde nicht müde...) klarzustellen, dass die zwei übergebenen Parameter an die Funktion logX() keine beliebigen Strings sind. Dass hier keine Fehlermeldungen kommen, liegt nur daran, dass openHAB stoisch beliebig viele Logger anlegt. Also:

logX(String,String) ist die Funktion, wobei X entweder Error, Warn, Info oder Debug sein kann. Damit werden exakt diese vier Dringlichkeitsstufen geloggt. Der erste String gibt den Loggernamen an, der zweite String ist die Loggermeldung.
Man muss nicht zwingend überall den gleichen Loggernamen verwenden, aber es ist sinnvoll, zumindest pro Rule nur exakt einen Loggernamen zu verwenden.
Der Loggername sollte keine Leerzeichen enthalten und möglichst nur Kleinbuchstaben des englischen Alphabets nutzen. Wenn man möchte, kann man Loggernamen hierarchisch gestalten und dann einen Punkt als Trennung verwenden.
FALSCH:

Code: Alles auswählen

logWarn("Pufferspeicher Gradzahl", "liefert keinen gültigen Zahlenwert")

RICHTIG:

Code: Alles auswählen

logWarn("pufferspeicher", "Gradzahl liefert keinen gültigen Zahlenwert")

(Formal - inhaltlich könnte man den Meldetext durchaus noch anpassen...)

Warum ist das denn so wichtig?

Weil der Log-Mechanismus in openHAB eine der am wenigsten verstandenen Funktionen ist (und es gibt davon so einige...)

Deshalb mal hier, was der Logger kann:

• individuelles Logging pro gewählter Einheit (z.B. hat jedes Binding einen eigenen Logger)
• individuelle Ziele pro Logger (z.B. Systemmeldungen nach openhab.log und openHAB Bus nach events.log)
• individuelle Loglevel pro Logger
• Die LogLevel sind im laufenden Betrieb wählbar und unmittelbar aktiv

Das bedeutet: Ich kann pro Rule einen eigenen Loggernamen nutzen. Dann kann ich (wie erwähnt im laufenden Betrieb) Loggermeldungen pro Rule steuern, also welche Meldungen ich sehen möchte und welche Meldungen ich nicht sehen möchte. Ich könnte mit entsprechendem Regelsatz auch dafür sorgen, dass Loggermeldungen, bestimmte Rules betreffend, zusätzlich in eine eigene Datei geschrieben werden (oder auch exklusiv...).

Der Loggername ist essenziell für die korrekte Steuerung des LogLevels und der Zuordnung, was mit den Loggermeldungen geschehen soll. Der Loggername hat ein Prefix. Es lautet bei openHAB3 org.openhab.core.model.script. und kann nicht geändert werden. Alle Loggermeldungen aus Rules heraus haben also einen Loggernamen der mit org.openhab.core.model.script. beginnt und danach noch den Inhalt des ersten übergebenen Strings anhängt, im Beispiel oben wäre das dann org.openhab.core.model.script.pufferspeicher

Mit diesem Namen kann man nun beeinflussen, welche Meldungen angezeigt werden. Über die Karaf Konsole kann im laufenden Betrieb der LogLevel gesteuert werden, so:

Code: Alles auswählen

log:set DEBUG org.openhab.core.model.script.pufferspeicher

Ab sofort werden alle Loggermeldungen des Loggers org.openhab.core.model.script.pufferspeicher ausgegeben, die mindestens der Stufe DEBUG entsprechen (das sind alle Stufen). Mit

Code: Alles auswählen

log:set WARN org.openhab.core.model.script.pufferspeicher

kann man aber auch dafür sorgen, dass nur noch Meldungen ab Stufe WARN ausgegeben werden, also weder INFO noch DEBUG, sondern nur noch WARN und ERROR.
Mit

Code: Alles auswählen

log:set DEFAULT org.openhab.core.model.script.pufferspeicher

wird eingestellt, dass der Wert von der nächsthöheren Instanz geerbt wird (das wäre dann org.openhab.core.model.script (ohne Punkt hintendran...).
Man kann auch das Logging für alle Rules auf einmal stummschalten:

Code: Alles auswählen

log:set OFF org.openhab.core.model.script

und dann gezielt nur für bestimmte Rules wieder einschalten (wobei sich der Befehl natürlich nur auf die Logger auswirkt, die noch keinen individuell festgelegten LogLevel haben).

Der Default LogLevel lautet INFO, das heißt, die Rule, welche ohne Merker auskommt, wird nicht bei jeder Ausführung eine Meldung produzieren, denn die erste logX-Funktion ist ja logDebug(), die Ausgabe wird also normalerweise unterdrückt.

[Snatsch]

Vielen Dank für eure Hilfe. Das ist sehr viel Lesestoff von Udo1toni. Noch mal zur Aufklärung von meinem Vorhaben. Wir haben einen Kachelofen der Wasserführend ist. Der Ofen steht im Wohnzimmer und ich bin oft (sehr oft) im Arbeitszimmer im Keller . Wenn der Pufferspeicher eine Temperatur von ca.55 Grad erreicht ist es möglich ohne zusätzlichen Gasverbrauch meine Heizungen auf 21 Grad zu stellen. Wenn aber meine Frau im Ofen auflegt, hat schon mehrere mal der Pufferspeicher gekocht. Deshalb soll unser Google Minni eine Ausgabe machen wenn 85 Grad erreicht sind.