SmartHomeNG Release v1.6

[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]

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...)

[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]

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...

[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?

[schuma]

Ok, Danke.

[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]

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

[psilo]

Die Frage ist, woher er {'min': '2.9.1'} (nicht 2.19!) hat?!

bei withings musste ich das so eng fassen, da das nokia paket sonst die zicken kriegt..

[bmx]

Im Withings-Plugin findet sich requirements.txt

nokia>=1.0.0,<=1.2.0
arrow>=0.12,<=0.13.1
requests>=2.19,<=2.21
requests-oauth>=0.4.1,<0.5
requests-oauthlib>=1.0,<1.1

in base.txt dagegen

# SmartHomeNG-lib
requests>=2.20.0

Da das nur ein Warning und kein Error ist, kannst Du das IMHO ignorieren. Sinnigerweise sollte man für das Whithings PLugin die Requirements dann ohnehin aus Sicheitsgründen anheben. Ich weiß aber nicht, wer das überhaupt alles nutzt.

[stromi1]

Hallo,
hab von Version 1.4.1 mit git pull auf 1.6 upgedatet, auch die plugins aus dem Master branch. Mit pip3 alle requirements installiert. Allerdings bekomme ich nach dem Start folgende Fehlermeldung:

2019-08-05 15:21:58 WARNING __main__ -------------------- Init SmartHomeNG 1.6.master (1b2cb3e6) --------------------
2019-08-05 15:21:58 WARNING __main__ Running in Python interpreter 'v3.5.3 final' (pid=747) on linux platform
2019-08-05 15:21:58 WARNING lib.shpypi - requests: MULTIPLE requirements [{'min': '2.20.0'}, {'min': '2.9.1'}]

In den requirements hab ich schon gesucht und die doppelten Einträge entfernt, aber woher lib.shpypi das bezieht, weiß ich nicht.

[psilo]

so lange du nur ein plugin nutzt, ist das egal. bei 2 plugins oder dem database plugin mit multiplen instanzen geht das visu_websocket (das redet ja mit der SV) plugin vermutlich nach first come first serve vor..

[Cannon]

Das hat mit der smartVISU nichts zu tun. Die Meldung sagt aus, dass in SmartHomeNG möglichst ein anderes Plugin verwenden solltest, da in einem der kommenden Releases das sqlite Plugin nicht mehr zur Verfügung steht

Genau das war mir bewusst. Wie kann ich aber das database-plugin für die SmartVISU nutzen? Mir ist die Verbindung dahin nicht klar. Vorher hatte ich das "alte" und im item sqlite: 'yes' gemacht und in den plugins konfiguriert. Jetzt mache ich einfach database: 'yes' und muss woanders für die SmartVISU nichts weiter festlegen? Woher weiß denn die VISU, dass sie das database-plugin nutzen soll?

[Msinn]

Das hat mit der smartVISU nichts zu tun. Die Meldung sagt aus, dass in SmartHomeNG möglichst ein anderes Plugin verwenden solltest, da in einem der kommenden Releases das sqlite Plugin nicht mehr zur Verfügung steht. Das gilt für das sqlite und für das sqlite

_visu2_8 Plugin. (Die beiden Plugins unterscheiden sich nur darin, dass das originale sqlite Plugin nur smartVISU bis v2.7 unterstützte).

Die Empfehlung ist, das database Plugin anstelle des sqlite Plugins zu nutzen.

[Cannon]

Ich habe mit der Version 1.6. noch ein Problem mit dem sqlite-Plugin der SmartVISU.

Plugin 'sqlite_visu2_8' (section 'sql') is deprecated. Consider to use a replacement instead

Ich verstehe die Meldung schon. Mir ist nur nicht klar, wie ich der SmartVISU klarmachen kann, dass sie das normale database-plugin nutzen soll. Ich finde in den Dokus dazu auch nichts.