Seite 1 von 2
Logging - script.RULE in separates logfile
Verfasst: 24. Sep 2019 12:17
von trigan
Liebes Openhab Forum,
Es gibt ein paar spärliche Anleitungen für das Einrichten des logs.
Was für mich interessant wäre: Ich würde gerne alle rules betreffenden events in ein separates log file speichern, also kopieren.
In den Anleitungen verstehe ich es nicht, wie man das erreicht.
Ich kann es im shell so sortieren und in ein textfile schreiben:
cat /var/log/openhab2/openhab.log | grep "script.RULE" > rules.log
Dann könnte ich das textfile wieder irgendwie in openhab anzeigen. Geht das nicht einfacher?
Das riesige Log ist ja sehr nett aber was mir wichtig ist, wann werden meine rules ausgeführt.
Wenn ich nur 2 Minuten zu spät ins hablog schaue, ist das event meistens schon oben wieder rausgelaufen.
Idealerweise wäre eine Seite in Openhab, wo die Rules des ganzen Tages aufgelistet sind.
Kann mir da bitte Jemand weiterhelfen
Grüße
Re: Logging - script.RULE in separates logfile
Verfasst: 24. Sep 2019 12:49
von trigan
Bin etwas weiter gekommen:
das script legt die rules.txt in /var/www/html
Dann kann ich es im habpanel in einen frame legen als url : http://openhab_ip/rules.txt
Re: Logging - script.RULE in separates logfile
Verfasst: 24. Sep 2019 13:50
von udo1toni
Das ist von hinten durch die Brust ins Auge. Was Du möchtest, ist ein separates File für alles, was vom script Logger kommt. Der notwendige Mechanismus ist in openHAB schon drin (bzw. in log4j2)
Das Vorgehen ist hier beschrieben:
https://www.openhab.org/docs/administra ... arate-file
Du musst also einen neuen Logger anlegen. Dabei kommt es sehr auf die Version von openHAB an, da sich hier Namen geändert haben:
Entweder org.eclipse.smarthome.model.script oder org.openhab.model.script, das kannst Du über die Karaf Konsole herausfinden.
Anschließend musst Du angeben, dieser Logger landen soll. (in einem File, vergleichbar mit openhab.log oder events.log)
Es wird natürlich nur geloggt, was auch mit entsprechenden Befehlen angegeben wurde, die Ausführung von Rules wird weder in events.log noch in openhab.log aufgeführt, wenn in der Rule kein logXxxx() Befehl steht.
Was die Ansicht der Datei betrifft, so gibt es da keine vernünftige Lösung, außer sie über ein Tool zu öffnen. das Kopieren in den statischen Teil mag funktionieren, aber schön ist das nicht. Vielleicht funktioniert ein Link auf die Datei (evtl. kein symbolischer link, sondern nur ein hardlink), dann müsste zumindest nicht jedes mal die Datei kopiert werden. Natürlich kann man logTail dazu konfigurieren, die zusätzliche Datei zu berücksichtigen, ob das aber Dein ursprüngliches Problem löst?
Re: Logging - script.RULE in separates logfile
Verfasst: 28. Sep 2019 04:56
von trigan
Hallo,
vielen Dank für die Tipps: Ich werd das dann mit dem separaten Log mal versuchen. Bin nicht so fit mit Karaf aber nach der Anleitung kann ja Nichts schief gehen.
Grüße
Re: Logging - script.RULE in separates logfile
Verfasst: 28. Sep 2019 07:17
von udo1toni
trigan hat geschrieben: ↑28. Sep 2019 04:56
nach der Anleitung kann ja Nichts schief gehen.
J...N... doch.
Die Datei, die bearbeitet werden muss (nicht über karaf, sondern in einem normalen Text Editor) gehört zu den Innereien von openHAB. Wenn dort ungünstige Fehler enthalten sind, kann das gesamte Logging ausfallen.
Man sollte also auf jeden Fall ein Backup der Originaldatei machen.
openHAB schreibt auch selbst in die Datei, sobald man über Karaf am LogLevel einzelner Dienste dreht.
Da die Datei normalerweise statisch ist, muss openHAB nach den Änderungen neu gestartet werden, um die Änderungen auch zu sehen.
Re: Logging - script.RULE in separates logfile
Verfasst: 28. Sep 2019 13:54
von peter-pan
Ich hätte vielleicht auch noch eine "simple" Lösung anzubieten., die ich benutze.
Da ich im laufenden Betrieb nicht wissen will was meine Items gerade machen, habe ich über die Karaf-Console (openhab-cli console) den Level von "info" auf "warn" gesetzt.
Code: Alles auswählen
openhab> log:list
Logger │ Level
───────────────────────────────────────────────────┼──────
ROOT │ WARN
javax.jmdns │ ERROR
org.apache.karaf.jaas.modules.audit │ INFO
org.apache.karaf.kar.internal.KarServiceImpl │ ERROR
org.apache.karaf.shell.support │ OFF
org.apache.sshd │ WARN
org.eclipse.jetty.util.thread.ThreadPoolBudget │ ERROR
org.eclipse.lsp4j │ OFF
org.eclipse.smarthome │ INFO
org.eclipse.smarthome.binding.openweathermap │ INFO
org.eclipse.smarthome.rules │ DEBUG
org.jupnp │ ERROR
org.openhab │ INFO
org.openhab.binding.avmfritz │ INFO
org.openhab.binding.homematic │ ERROR
org.openhab.binding.http │ ERROR
org.openhab.binding.weather │ INFO
org.openhab.persistence.mapdb │ INFO
org.openhab.ui.paper │ WARN
org.ops4j.pax.url.mvn.internal.AetherBasedResolver │ ERROR
org.ops4j.pax.web.pax-web-runtime │ OFF
smarthome.event │ WARN
smarthome.event.InboxUpdatedEvent │ ERROR
smarthome.event.ItemAddedEvent │ ERROR
smarthome.event.ItemRemovedEvent │ ERROR
smarthome.event.ItemStateEvent │ ERROR
smarthome.event.ThingAddedEvent │ ERROR
smarthome.event.ThingRemovedEvent │ ERROR
smarthome.event.ThingStatusInfoEvent │ ERROR
openhab> log:set warn smarthome.event
Das macht alles etwas übersichlicher und kann jederzeit wieder zurück gesetzt werden.
Ausserdem benutze ich in manchen Rules noch einen Counter, damit ich nicht jeden Log sehe, sondern nur jeden 2, 4 10, etc., damit ich sehe, das die Rule "noch lebt"
Beispiel(chillcount):
Code: Alles auswählen
var chillCount = 4
rule "Windchill_Calculate" // thx to @Udo_Hartmann for the Rule-Body and @dmaillie for the math-stuff - 2019-01-13
when
Item Dummy3x received command ON or
Item localHourlyForecastTemperature_00 received update
then
if(triggeringItem.state === null) { // neu
logWarn("windchill"," Triggering Item: {} previous State: {}",triggeringItem.name, triggeringItem.state) // neu
return; // neu
} // neu
if(!(localHourlyForecastWindSpeed_00.state instanceof Number)|| !(localHourlyForecastWindSpeed_01.state instanceof Number))
{
logWarn("windchill","Windspeed not of Type Number!")
return;
}
if(!(localHourlyForecastTemperature_00.state instanceof Number)|| !(localHourlyForecastTemperature_01.state instanceof Number))
{
logWarn("windchill","Temperature not of Type Number!")
return;
}
var speedCurrent = Math.pow((((localHourlyForecastWindSpeed_00.state as Number).floatValue) * 1.0), 0.16)
var speedForecast3 = Math.pow((((localHourlyForecastWindSpeed_01.state as Number).floatValue) * 1.0), 0.16)
var tempCurrent = (localHourlyForecastTemperature_00.state as Number).floatValue
var tempForecast3 = (localHourlyForecastTemperature_01.state as Number).floatValue
localHourlyForecastWindchill_00.postUpdate(13.12 + 0.6215 * tempCurrent - 11.37 * speedCurrent + 0.3965 * tempCurrent * speedCurrent )
localHourlyForecastWindchill_01.postUpdate(13.12 + 0.6215 * tempForecast3 - 11.37 * speedForecast3 + 0.3965 * tempForecast3 * speedForecast3 )
chillCount ++
if (chillCount >= 4) // logInfo every 2 hours (or every 4th time) - Temperature is updated every 30 Minutes by another Rule/Binding
{
logInfo("windchill"," I'm alive - Temp: {} Speed: {}",tempCurrent,speedCurrent)
chillCount = 0
}
end
Re: Logging - script.RULE in separates logfile
Verfasst: 29. Sep 2019 07:09
von Tokamak
Sorry, da OT:
In welchen Situationen ist
richtig?
Ich dachte, state wäre immer gesetzt, wenn auch initial mit dem NULL-Objekt?
Re: Logging - script.RULE in separates logfile
Verfasst: 29. Sep 2019 10:31
von peter-pan
@Tokamak
Frage: Was ist OT ?
Also soweit ich weiss ist der Zustand des Items beim Starten von OH zuerst "null" und wird dann ggf. durch einen Channel, wenn einer mit dem Item verlinkt ist, gesetzt, oder evtl wenn eine Persistence existiert, wird der letzte Wert gesetzt.
Beim Starten von OH kann es aber sein, dass die Rules schon geladen und ggf. gestartet werden, bevor die ganzen Items geladen werden und dann könnte es zu dieser Konstellation führen. (IMHO).
Wie du aber in dem kleinen Hinweis in meine Rule siehst, habe ich diese nicht selbst erfunden, sondern "geklaut". Ich habe gerade im
Original-Post geschaut und ich glaube ich habe den "Schwachsinn" selber eingebaut, weil manchmal bekomme ich trotzdem eine ERROR-Message, beim Neustart.

Beim nächstem Item-Update, funktioniert aber alles normal
Am besten wäre es, wenn @udo1toni, was dazu sagen könnte, der hat mir hierbei geholfen.
Re: Logging - script.RULE in separates logfile
Verfasst: 29. Sep 2019 12:36
von udo1toni
Aaaalso:
Es gibt verschiedene Fälle.
- triggeringItem === null -> Es gab kein Item, welches die Rule getriggert hat. Das kann natürlich nur dann passieren, wenn eine Rule Trigger hat, die nicht auf einem Item basieren, z.B. System started oder Time cron. Gut, das im Hinterkopf zu haben, denn so kann man die verschiedenen Fälle unterschiedlich behandeln.
- triggeringItem.state == NULL -> Der Status des Items ist NULL. Das kann passieren, weil z.B. eine Rule den Status so setzt - mit Item.postUpdate(NULL).
Auch ein Binding kann das tun, z.B. das expire Binding wird gerne so verwendet, um Items, die nicht mehr mit gültigen Werten gefüllt werden, zurückzusetzen.
- triggeringItem.state == UNDEF -> Der Status des Items ist UNDEF. Siehe Punkt 2.
- triggeringItem.state === null -> gibt es nicht(!)
Der Status eines Items ist zu keinem Zeitpunkt null, niemals.
Falls ich das in einer meiner Rules verwendet habe, hab ich in geistiger Umnachtung einen Fehler gemacht. Das kommt eigentlich bei jedem nicht getesteten Code vor... 
Re: Logging - script.RULE in separates logfile
Verfasst: 29. Sep 2019 17:01
von peter-pan
Hallo Udo,
erst mal Danke, dass du dich da eingeklingt hast und zweitens, wie oben schon gesagt, den Schwachsinn hab ich selber "gebastelt". Werde das natürlich sofort abändern. Und last but not least, Danke für die ausführliche Erläuterung.
Gruss
Peter