Darkwin101 hat geschrieben: ↑29. Aug 2020 18:11
Die ganzen Logbefehle sind Blödsinn da alle log ausgeführt werden
Na, so ganz stimmt das nicht
Code: Alles auswählen
rule "Motion Detected"
when
Item Doorbell_Motion changed to ON
//
then
KnxEGLichtWzKamin.sendCommand(ON)
// degub logging
logDebug("doorbird_motion.rules", "Motion Detected Doorbird Debug") // wird nicht ausgeführt
logError("doorbird_motion.rules", "Motion Detected Doorbird Error") //wird ausgeführt
logInfo("doorbird_motion.rules", "Motion Detected Doorbird Info" + KnxEGLichtWzKamin.state) // wird nicht ausgeführt
logWarn("doorbird_motion.rules", "Motion Detected Doorbird Warm") // wird nicht ausgeführt
end
wird nur ausgeführt, wenn der passende Logger auf DEBUG steht (eher unwahrscheinlich, default ist INFO)
logInfo() wird nicht ausgeführt, da man den Status nicht einfach als String verwenden kann -> Rule bricht mit
NullPointerException ab.
logWarn() wird auch nicht ausgeführt, da die Rule schon vorher gecrasht ist.
Darkwin101 hat geschrieben: ↑29. Aug 2020 18:11
dies wäre Hilfreich wenn du mehrer bedingungen im Then teil hättest damit du weisst bis wo die Rule ausgeführt wird
log-Meldungen sind grundsätzlich hilfreich zum eingrenzen von Fehlern. Aber BITTE verwendet das so, wie es gedacht ist!
Es gibt vier verschiedene Stufen, eben Debug, Info, Warn und Error. Diese werden im Log auch so gekennzeichnet und sollten auch ihrer Stufe entsprechend verwendet werden.
Debug: detaillierte Informationen, die nur im Ausnahmefall interessant sind.
Info: allgemeine Informationen
Warn: Warnmeldungen (z.B. weil ein Wert nicht gelesen werden konnte und in der Folge ein Default Wert verwendet wird)
Error: Wenn die Rule abgebrochen werden muss, weil ein schwerer Fehler aufgetreten ist.
Alle log-Befehle einer Rule (oder auch thematisch zusammengehörender Rules) sollten den gleichen Logger verwenden. Der Logger ist der erste String.
BITTE verwendet nicht das Wort "rules" oder "rule" im Loggernamen, das ist doppelt gemoppelt. Alle Logger aus der Rules Engine gehören zu
org.openhab.module.script, das ist eindeutig, und wenn man den Loggernamen kurz genug wählt (!), sieht man genug von dieser Zeichenkette, um die Meldung zuordnen zu können.
Im vorliegenden Fall wäre meine Wahl einfach doorbird, was dann als vollständigen Loggernamen org.openhab.module.script.doorbird ergibt. Im Log selbst werden die letzten 36 Zeichen angezeigt, was dann [ org.openhab.module.script.doorbird] ergibt.
Über den Loggernamen kann man zur Laufzeit (ohne openHAB zu beenden) jederzeit wählen, wie weitreichend die Meldungen sein sollen, das geht über die Karaf Konsole. Man kann dort das Logging (pro Logger) auf die Stufen TRACE, DEBUG, INFO, WARN, ERROR, OFF und DEFAULT einstellen. Alles unterhalb der gewählten Stufe wird nicht geloggt, wenn man also WARN wählt, werden logWarn und logError geloogt, logDebug und logInfo aber nicht. DEFAULT erbt die Einstellung des übergeordneten Elements (org.openhab.module.script, das erbt INFO von org.openhab (über org.openhab.module)
Zum Testen (und so waren die logBefehle sicher gedacht
) ist es natürlich vollkommen ok, sie einfach hinzuschreiben.
Zum testen, bis wohin ein Code ausgeführt wird, ist es hingegen sinnvoller, den Log-Text (das ist der zweite String der Meldung) zu variieren, z.B. so:
Code: Alles auswählen
rule "Motion Detected"
when
Item Doorbell_Motion changed to ON
//
then
logInfo("doorbird", "Motion Detected - Rule wurde getriggert.")
KnxEGLichtWzKamin.sendCommand(ON)
logInfo("doorbird", "Motion Detected - Licht wurde geschaltet.")
end
Sollte nun etwas nicht funktionieren, kann man nachverfolgen, an welcher Stelle etwas schief gegangen ist
openHAB4.3.5 stable in einem Debian-Container (bookworm) (Proxmox 8.4.1, LXC), mit openHABian eingerichtet
