Logik anpassen via Backend Server

[Msinn]

Hallo,
die neue Version ist sehr geschwätzig, im log habe ich noch nicht alle Meldungen analysiert.

Nicht, wenn Du das Logging richtig konfigurierst. Schau mal in die Doku zum Thema Logging. Da sind Best Practices beschrieben.

wo kommen denn diese Meldungen her ?

Da fehlt eine (redundante) Übersetzung im Plugin. Wenn Du das Logging nach den Best Practices konfigurierrst, siehst Du die nicht mehr (es sei denn, Du konfigurierst explizit das plugin.backend vom Level auf INFO oder DEBUG).

[whe]

am Logging bin ich im September schon mal gescheitert.
dann werde ich es noch mal versuchen mit der 1.4.
man könnte ja auch das YAML file entspr ausliefern.

[psilo]

whe die best practices sind eine kurze seite in der doku... da man vorher nicht weiss wer welches plugin nutzt, macht ein "vorausliefern" wenig sinn

[whe]

jetzt steht fast nichts mehr im log
und auch meine eigenen Meldungen aus den Logiken erscheinen nicht mehr.

zudem halte ich es nicht für die richtige Methode, Meldungen zu unterdrücken.
entweder sie sind sinnvoll, dann gehören sie ins log.
oder sie sind überflüssig, dann sollte man sie in einen anderen Level stecken oder erst gar nicht produzieren.

[Msinn]

Die Meldungen sind sinnvoll, nur nicht für jedermann! Deshalb kann man sie ausblenden.

Es ist die richtige Methode und im Python Logging so angelegt.

[Msinn]

Ich bin jetzt nicht an meinem System, kann Dir daher nicht sagen, wie Du für Deine Logiken das Logging wieder aktivierst.

[Msinn]

Du hast zwei Möglichkeiten aus Logiken zu loggen:

1. Du richtest in der etc/logging.yaml einen logger folgendermaßen ein:

loggers:
    logics.a_testlogic2:
        handlers: [file, file_additional]
        level: INFO

Dann werden aus de Logik a_testlogic2

• Warnungen in smarthome.log geschrieben (das liegt daran, dass der handler file nur Warnungen und höher schreibt.
• Außerdem werden Warnungen und Infos der Logik in smarthome-additional.log geschrieben.

ACHTUNG: a_testlogic2 ist NICHT der Dateiname des Python Codes, sondern der Name das Abschnitts unter dem die Logik in etc/logic.yaml definiert ist.

Wenn Du den level auf DEBUG setzt, werden Warnungen, Infos und Debug Meldungen in smarthome-additional.log geschrieben.

Dabei musst Du für jede Logik einen Logger in etc/logging.yaml anlegen.


Alternativ kannst Du einen generellen Logger anlegen und nutzen:

In allen Logiken fügst Du folgendes ein:

import logging
mylogger = logging.getLogger('mein_logik_logger')

mylogger.warning("Logik 'create_test2' wurde getriggert (WARNING)")
mylogger.info("Logik 'create_test2' wurde getriggert (INFO)")
mylogger.debug("Logik 'create_test2' wurde getriggert (DEBUG)"

und Du richtest einen einzigen Logger ein:

loggers:
    mein_logik_logger:
        handlers: [file, file_additional]
        level: INFO

So bleibt smarthome.log "sauber" und enthält nur wirklich wichtiges (WARNING, ERROR, CRITICAL, EXCEPTION) und in smarthome-additional.log kannst Du so detailliert loggen, wie Du möchtest.

[whe]

so hätte ich es ja auch gerne; aber als normal Sterblicher, kriege ich das einfach nicht hin.
im Moment versuche ich den HUE Fehler zu deguggen, selbst da kommt jetzt nichts mehr raus.

 [smarthome@SmartHomeNG /usr/local/smarthome/bin]$ python3 smarthome.py -d
[18/Dec/2017:20:44:34] ENGINE Bus STARTING
[18/Dec/2017:20:44:34] ENGINE Serving on http://192.168.178.28:8384
[18/Dec/2017:20:44:34] ENGINE Serving on http://192.168.178.28:8383
[18/Dec/2017:20:44:34] ENGINE Bus STARTED

als Anlage mein logging.yaml

[Msinn]

Ich verstehe nicht was Du da loost/loggen möchtest:

 
 [18/Dec/2017:20:44:34] ENGINE Bus STARTING [18/Dec/2017:20:44:34] ENGINE Serving on http://192.168.178.28:8384 [18/Dec/2017:20:44:34] ENGINE Serving on http://192.168.178.28:8383 [18/Dec/2017:20:44:34] ENGINE Bus STARTED

Ich sehe in den Einträgen weder wer loggt noch die Severity (DEBUG, INFO, WARNIG, ERROR, CRITICAL)

root:
    level: INFO
    handlers: [file]

bewirkt, dass alle INFOs (und höher) in smarthome.log gehen. Um das zu beschränken musst Du

root:
    level: WARNING
    handlers: [file]

schreiben.

Um Deine Logik trotzdem INFOs (in smarthome-additional.log) loggen zu lassen, musst Du unter loggers:

loggers:

    ...

  logics.<dein_logik_name>:
    level: INFO
    handlers: [file_additional]

hinzufügen.

[whe]

Msinn

ich möchte hier niemanden ärgern, ich möchte nur einfach verstehen was in meinem System abgeht.
Die Best Practices sind sicher eine gute Empfehlung, aber wenn ich alle Meldungen ignorieren soll, frage ich mich, wieso sie denn erstellt werden.
deshalb möchte ich nochmals meine logfile von heute anhängen.
bis um 10, war alles super, dann fängt das Teil INFOs zu produzieren ohne Ende. Das muss doch einen Grund haben.
ich will das nicht ignorieren.

eine Meldung nervt mich allerdings schon seit Wochen und Monaten, die werde ich dann doch jetzt mal auskommentieren:

 
 2017-12-19  10:03:44 INFO     Main             VISU: Websocket handler uses protocol version 4

Das System ist doch auch für Normale Anwender gebaut.

PS: sicher werde ich es auch irgendwann schaffen, das logging so zu konfigurieren, wei es sinnvoll und hilfreich ist.

Gruß Wil

[psilo]

whe die debug logs im backend helfen uns bspw zu sehen, ob wir irgendwo übersetzungen vergessen haben. dem normalen user kann das wurscht sein..

[psilo]

in meinen anderen plugins hilft es zur Fehlersuche.. wenn alles geht sollte debug aus sein..

[bmx]

Vielleicht bauen wir auch mal eine Konfigurationsmöglichkeit für das Logging ins Backend ein...

[psilo]

die infos kommen von cherrypy. mit uns haben die wenig zu tun. passiert wenn du dich durchs backend klickst.. deswegen leitet man die eben in ein additional log..

[Msinn]

Das Logging ist vom Grundprinzip her so gedacht, dass im normalen Betrieb Warnungen und Fehler geloggt werden. Ein fast leeres Log bedeutet: Alles Ok.

Wenn Probleme auftreten (mit und ohne Fehlermeldungen), kann man einfach für die betroffenen Teile von SmartHomeNG (z.B. ein Plugin ider eine Library) den Loglevel hochsetzen (auf INFO oder DEBUG), um mehr Informationen zu erhalten. Da das selektiv möglich ist, "ertrinkt" nicht gleich in allen Meldungen aller Plugins, Libraries, etc.

Wenn ein Anwender für einige Teile seiner Installation mehr Informationen möchte, kann er z.B. für Logiken die er erstellt hat, das Logging so einstellen, das es seinem Informationsbedarf entspricht. Dabei ist es möglich (wie ich Dir gestern schon schrieb), entweder in den Logiken so zu loggen, dass der Loglevel für alle Logiken gleich ist, oder es kann für jede Logik einzeln festgelegt werden, wie der Loglevel sein soll. Dadurch kann der Anwender, wenn er eine Logik erstellt, den Loglevel für diese Logik auf DEBUG setzen, ohne dass andere Logiken dabei geschwätziger werden.

Bei Bedarf können die Logausgaben einzelner Plugins, Libraries, Logiken, etc. auch in weitere Logdateien isoliert werden.

Das System ist doch auch für Normale Anwender gebaut

Deshalb sollte das Logging auch nur Warnungen und Fehler ausgeben. Im kommenden Release werden wir den Loglevel entsprechend voreinstellen.