Rückmeldungen zu smarthomeNG Version 1.10.0

[aschwith]

Hallo zusammen,

mit dem Update auf V 1.10.0 hat sich das Verhalten des RotatingFileHandlers beim Logging geändert. Das betrifft auch die Standard Log Dateien smarthome-warnings und smarthome-details. Inhalt und Dateiname sind jetzt um einen Tag verschoben, hier ein Beispiel:

Die Datei smarthome-warnings.2024-02-11.log enthält alle Logs vom 10.02.2024.
Die Datei smarthome-warnings.2024-02-10.log enhält alle Logs vom 09.02.2024.
usw...

Könnt ihr das Verhalten bestätigen?

[Msinn]

Das ist eine Option, die es bereits seit einigen Versionen in SmartHomeNG gibt. Dafür wurde auf Wunsch extra ein neuer Filehandler geschrieben. Falls Du in der etc/logging.yaml als Handler für Deine Logs den Standard RotatingFileHandler auswählst, hast Du wieder das alte Verhalten.

Das einige was sich in v1.10 geändert hat, ist die logging.yaml.default, die als Vorlage bei Neuinstallationen verwendet wird. Hier ist jetzt der neue Handler voreingestellt.

Die Verschiebung um einen Tag, von der Du berichtest, kann ich nicht nachvollziehen.

[Msinn]

Nachtrag: Ich habe gerade gesehen, dass kurz vor dem Release Onkelandy am Rotating File Handler Änderungen vorgenommen hat. Die Änderungen habe ich bei mir nichtg laufen, weshalb ich wohl auch keine Verschiebung der Daten habe.

Onkelandy Kannst Du Dir das anschauen und wieder in Ordnung bringen?

[Onkelandy]

Hmmm, ich kann das Problem teilweise nachvollziehen, aber interessanterweise nicht bei allen Logfiles, obwohl überall der Shng Handler am Start ist.
Kurz vor dem Release habe ich eigtl. nur einen neuen Handler eingefügt, aber nichts am alten geändert.
Diese Änderung hier vor 3 Monaten ist eigentlich die einzige, die am Shng RotationHandler vorgenommen wurde:
https://github.com/smarthomeNG/smart...7aa1e12945f05d

Ob das zu dem Phänomen führen kann...? Ist der ShndTimedRotatinghandler am Start?

[aschwith]

Hi Onkelandy: Ja, benutze seit langem den lib.log.ShngTimedRotatingFileHandler handler. Das neue Verhalten ist bei mir definitiv mit der Umstellung auf v1.10.0 reingekommen. VG

[aschwith]

Ich habe noch ein anderes Thema in deine Richtung Msinn: In der V 1.10.0 sind bei mir durch Commit f63c5ba unschöne Triggerschleifen entstanden. Dabei werden Statusrückmeldungen von Aktoren ungewollt direkt wieder als Kommandos an Aktoren gesendet.

Normalerweise verhindern wir das ja in jeden Plugin über einen Filter in der jeweiligen update_item:

if caller != self.get_shortname():

Mit Commit https://github.com/smarthomeNG/smart...bb8975d577182f funktioniert das nicht mehr zuverlässig für Items, die sowohl Statusrückmeldungen als auch Kommandos versenden können UND ein eval Statement haben, also z.B.:

level:
type: num
value: 0
enocean_rx_key: D
visu_acl: rw
enforce_updates: True
enocean_tx_eep: A5_38_08_03
enocean_tx_id_offset: 7
ref_level: 55
eval: value if int(value) == 0 or int(value) > 35 else 35
log_change: q_hkr_items​

Hier passiert jetzt folgendes:
Statusupdate kommt über Plugin rein, hier im Beispiel über Enocean
eval vom Item level wird ausgeführt und bekommt den Caller eval:enocean (neu seit V1.10, vorher war der Caller nur enocean)
Das Update wird in dem Filter in der Plugin update_item Methode nicht gefiltert und geht direkt wieder als Kommando an das Plugin
Filter in plugin item_update greift nicht und triggert das Senden des Kommandos für level.

Ich verstehe den Sinn und Zweck, den Caller entprechend mit der Info eval: zu erweitern. Wenn wir das so beibehalten wollen, müssten wir allerdings die Filterbedingung in der update_item Methode JEDES Plugins erweitern.