SmartHomeNG Release v1.6

[schuma]

Ich hätte da eine Frage zu dem Admin Plugin:

Das neue Admin Plugin ist echt super und ich nutze das auch echt viel.
Leider kann ich das auf dem IPhone nicht oder nur bedingt nutzen.
Die obere Zeile zum Auswählen der verschiedenen Untergruppen belegt ca. die Hälfte auf dem Bildschirm und verdeckt somit die Auswahlmöglichkeiten der einzelnen Untergruppen.

z.B wenn ich Logs/Liste der Logger auswähle, kann ich nicht mehr die Auswahl Plugin Logger auswählen.

Anbei noch ein Foto: E804987C-222F-4E6B-A4CD-7DE2C2B02DD2.png
Ist das so bekannt?

Grüße, Marc

[Msinn]

Ja das ist bekannt. Bisher ist das Admin Interface von der Auflösung nur runter bis zu Tabletts (z.B. IPads) ausgelegt. Das soll sich in einem dr kommenden Releases ändern (nicht unbedingt im nächsten).

[schuma]

Ok, Danke.

[Morg]

Hi,

ich steige gerade vom (laufenden) Produktivsystem 1.4.2 um auf 1.6 und stoße auf einige Schwierigkeiten.

Zuerst - auch wenn oben im Thema noch auf den Debugmodus verwiesen wird, funktioniert der (bei mir) offensichtlich nicht mehr; in der Konsolenausgabe kommen wenn überhaupt nur noch spärlichste Meldungen an.

Wie kann ich denn auf die Schnelle zwischen "Produktionslogging" und Debugging hin und her schalten? Muss ich da jedesmal die logging.yaml umbauen?

Nachtrag:

Ich versuche, eine Testkonfiguration nur mit CLI sowie dem sml(x)-Plugin zum Laufen zu bringen. Nach dem Start mit "-d" bekomme ich in der Konsole nur Nachrichten von "ENGINE" angezeigt, im "smarthome-details.log" finde ich die nicht, dafür recht spärliche Infos über das Laden des CLI, aber keine allgemeinen Informationen über den Systemstart, das Laden von Plugins oder Parsen von Items.

Meine Befürchtung war, dass das SMLX-Plugin gar nicht geladen war. Per CLI bekomme ich aber offensichtlich korrekte (aktuelle) Werte. Wieso sehe ich denn die Debug-Meldungen nicht im Log?

Feedback zum ersten Eindruck: Entweder ist die logging-Konfiguration unnötig komplex, oder die mitgelieferte Standardkonfiguration ist untauglich, weil man als (unbedarfter) Einsteiger/Umsteiger nichtmal ausreichend Logging-Informationen bekommen kann.
Was spricht dagegen, den Kommandozeilen-Schalter "-d" beizubehalten, um _alle_ Meldungen auf die Konsole zu werfen, unabhängig von sonstiger Logging-Konfiguration?

[Morg]

Der Übersichtlichkeit halber:

Mit der Konfiguration von hier (https://www.smarthomeng.de/developer/logging.html) und der manuellen Ergänzung des sml-Plugins geht es so, dass ich erstmal alles zu Gesicht bekomme.

Wenn ich überlege, dass die Logging-Konfiguration zwischen "mitgeliefert" (entspricht "gem. User-Seite"), "gem. Dev.-Seite und ggf. der Erwartung von "klassischem Alles-Debug-Logging mit Option -d" erheblich unterscheidet, und dass ich als "Neuling" (nicht jeder kennt sich mit Python oder gar den Python best practices für Logging aus), finde ich es umso wichtiger, eine Möglichkeit zu haben, ohne großen Aufwand - und vor Allem ohne weitere Fehlerquellen! - ein umfängliches Logging aktivieren zu können.

Daher formuliere ich mein Feedback vom vorherigen Post mal so um: ich schlage vor, dass der Kommandozeilenparameter "-d" erhalten bleibt und - unabhängig vom per Datei konfigurierten Logging - ein Logging analog der Konfiguration auf der Entwicklerseite (https://www.smarthomeng.de/developer/logging.html) aktiviert. Das würde sicher dem einen oder anderen helfen, entweder schnell zwischen verschiedenen Logging-Varianten umzuschalten oder aber im Problemfall ein stabiles Logging zu aktivieren, auch wenn die logging.yaml unsauber konfiguriert, kaputt oder ggf. gar nicht vorhanden ist...

[Cannon]

ich steige gerade vom (laufenden) Produktivsystem 1.4.2 um auf 1.6 und stoße auf einige Schwierigkeiten.

Beim Logging hat sich einiges geändert. Ich musste das auch erst alles umbauen. Kann das aber auch nur aus dem Logs bestätigen, da ich das Logging im CLI bisher nicht nutze. Aber so oder so, müsstest du das anpassen. Was die Standard-Konfiguration betrifft, die wird meines Wissens ja von deiner alten Version übernommen. Sonst wären ja alle deine EInstellungen dahin. Das heißt du müsstest dir die Dokus anschauen, um zu sehen, was anzupassen wäre.

[Morg]

Mein Problem ist, dass ich am Logging bei der 1.4.2 nie was eingestellt habe. Wenn ich Details brauche, habe ich die mit "-d" gestartet und _alle_ Meldungen bekommen.

Wenn ich jetzt nicht die Default-Konfig der 1.6 nehme (da sehe ich quast gar nichts), sondern die von der Developer-Seite, dann sehe ich viel - aber wie ich gerade feststelle, immer noch nicht alles. Dazu muss ich erst alle "interessanten" Plugins manuell hinzufügen. Für sowas hätte ich einfach gerne eine "einfache" Option. Ich möchte beim Wechsel zwischen "Normalbetrieb" und "Debugging" nicht immer die logging.yaml umschreiben müssen. Die Option gab es bisher - der Kommandozeilenschalter. Wäre aus meiner Sicht gut, wenn der erhalten bliebe (und so funktioniert wie bisher...)

[Msinn]

Das -d steht aber nicht für "Details" sondern für "Debugging" und ist nur in der Lage von normal in die kleinste Getriebeübersetzung umzuschalten (sprich von Level WARNING auf DEBUG) und das global für alle Teile con SmartHomeNG. Das erschlägt einen schon von der Menge her. Auch sind viele der dabei geschriebenen Log Einträge für normale Anwender nicht verständlich.

Deshalb ist das Logging jetzt so gestaltet worden, dass der Loglevel z.B. nur für Logiken angehoben werden kann, was hilft wenn man Logiken schreibt/debugged und sich nicht durch alle Debug Meldungen des Core und der Plugins wühlen will. Dafür ist nur eine Zeile in der Logging.yaml anzupassen (was nicht viel aufwendiger ist, als das -d in den automatisierten Start zu knoten).

Da sich nicht jeder mit den Best Practices für Logging in Python auskennt, gibt es in der in der Anwender Doku und hier im Forum Beschreibungen, die Best Practices für SmartHomeNG beschreiben.

Wenn man tiefer einsteigen will, kann man auch nur den Loglevel einzelner Logiken, einzelner Plugins (oder aller Plugins) anpassen. Beschreibungen dazu gibt es in der Anwender Doku. Die Anpassung des Loglevel (und der anschließende Neustart des Core) können auch direkt im Admin Interface erfolgen.

Den Weg zurück zum -d kann ich mir nicht vorstellen, da dieses globale Debug-Logging viel zu Support intensiv war. Anwendern musste erklärt werden was sie im Log überhaupt sehen oder es wurden Bug Meldungen aufgemacht, weil jemand eine DEBUG Ausgabe für einen ERROR hielt...

In den kommenden Versionen wird die Konfiguration des Logging im Admin Interface auch noch einfacher werden, so dass man dafür nicht direkt yaml schreiben muss. Weiterhin wird die Änderung des Loglevel bestehender Logger zur Laufzeit (ohne Neustart von SmartHomeNG) möglich sein.

[Morg]

Die "Details" waren auch flapsig geschrieben. Zur detaillierten Fehlersuche, gerade auch beim Plugin-"Basteln" fand ich das immer einfacher. Neu starten musste ich den sowieso, da kann ich beim Neustart auch nen Parameter übergeben. (das Backend habe ich nie genutzt, war mir - ggf. auf meiner Hardware - viel zu langsam. ssh geht wunderbar...darum nutze ich auch mehr die Konsole als die Logfiles)

Ich lasse mir aber gern erklären, wie ich - beliebige oder gleich alle - Plugins auf einmal als Debugausgabe bekomme Wenn das (für mich) nutzbar ist - super.

(Trotzdem fände ich ein -d super, notfalls auch undokumentiert )

[schuma]

Wenn Du jedes Plugin in der Logging.yaml einträgst, kannst Du diese auch jetzt schon im Betrieb im Admin Interface umschalten.

Also zum Beispiel so:

loggers:
    knx_busmonitor:
        level: INFO
        handlers: [busmonitor_file ]
    plugins.indego:
        level: WARNING
    plugins.darksky:
        level: CRITICAL
    plugins.enigma2:
        level: CRITICAL
    plugins.uzsu:
        # handlers: [uzsu_file]
        level: WARNING

[Cannon]

und der anschließende Neustart des Core) können auch direkt im Admin Interface erfolgen.

Das hat bei mir noch bei keiner Version funktioniert. Das heißt es findet kein Restart des service statt. Ist das bei mir nur so?

nicht jeder kennt sich mit Python oder gar den Python best practices für Logging aus

Ich glaube SmartHomeNG betreiben zu wollen, ohne sich mit Python auszukennen oder ohne das lernen zu wollen ist unmöglich. Ich war vor ca. 1,5 Jahren auch Einsteiger und muss sagen es war schwer, aber ohne sich mit Python auseinanderzusetzen, würde man fast nichts umsetzen können.

[Morg]

Ich glaube SmartHomeNG betreiben zu wollen, ohne sich mit Python auszukennen oder ohne das lernen zu wollen ist unmöglich. Ich war vor ca. 1,5 Jahren auch Einsteiger und muss sagen es war schwer, aber ohne sich mit Python auseinanderzusetzen, würde man fast nichts umsetzen können.

Man muss zumindest bereit sein, sich damit auseinanderzusetzen, das will ich gar nicht bestreiten.

Aber wenn man sh.py gem. Anleitung installiert und es läuft (oder auch nicht), und dann hast du nichtmal "vernünftiges", sprich aussagekräftiges Logging, dann steht man vor einer Wand, die man selbst mit bestem Willen, Python zu lernen, nicht bezwingt.

Ich nutze sh.py ja nun auch schon eine Weile und habe ein Plugin komplett selbst geschrieben und ein weiteres mit angepasst, mit solchen Kleinigkeiten wie Lesen und Parsen von Binärdaten über die serielle Schnittstelle. Ich glaube also, dass ich mich schon ein bisschen mit Python auskenne. Aber wenn das Logging - mit den mitgelieferten Einstellungen - einfach keine Informationen gibt, ist es unheimlich schwierig herauszufinden, was gerade nicht geht. In der Situation hätte ich für ein "python3 smarthome.py -d" mit voller Debugausgabe einiges gegeben - tja. War nix.

Dass - wie Martin sagte - der "normale" Nutzer mit der Debugausgabe möglicherweise nichts anfangen kann, sie in vielen Fällen kontraproduktiv ist, da stimmen wir völlig überein. Aber es gibt halt immer Situationen, in denen ein "klick" für Licht im Dunkel sorgt. Hätte ich gestern "auf die Schnelle" die Log-Ausgaben gehabt, die ich jetzt bekomme, hätte ich nicht ewig mit der logging.yaml kämpfen müssen.

So eine Admin-Oberfläche ist ja alles schön und gut - aber im entscheidenden Moment kann ich die auch nicht nutzen. Entweder läuft sie nicht, oder ich komme - weil remote verbunden - nicht ohne weiteres dran. Das soll kein Bashing von GUIs werden, aber ich finde schade, dass dafür die einfachen Möglichkeiten über Bord geworfen werden...

[Onkelandy]

Reicht nicht dieser Eintrag unter "loggers" im logging.yaml für den gleichen Effekt?

plugins:
       handlers: [shng_details_file]
       level: DEBUG

[psilo]

Cannon

Das hat bei mir noch bei keiner Version funktioniert.

Gibts doch auch erst seit der letzten Version?! Was passiert denn genau bei dir? Ich habe das nur manchmal ganz selten, wenn pluginthreads hängen - meist von fehleranfälligen plugins wie dem sma plugin

[Cannon]

Gibts doch auch erst seit der letzten Version?! Was passiert denn genau bei dir?

Meines Wissens nach gab es das auch schon in Version 1.4. Es steht da dann:

"Restart des Service sollte erfolgen - Bitte warten"

Das steht im Log:

"WARNING plugins.backend.utils os_service_restart: Restarting SmartHomeNG"

Ein Neustart erfolgt aber nicht. Würde man ja dann auch im Log sehen.