Logging - Filter

[Tom Bombadil]

Es gibt noch 2 Ansätze, die euch helfen könnten:
- Sofern das Plugin in etc/plugin.yaml drin ist, aber mittels plugin_enabled: False ausgeschaltet wird, kommen auch keine Meldungen wegen Attribute
- Startet ein Attribut mit my_ wird die Meldung auch nicht geloggt.

Du hast meinen oben beschriebenen Use-Case nicht verstanden, und wir reden hier auch nicht von mal eben drei, sondern von hunderten Items (Coils/Registern):

heizung:

    regler:

        sensoren:

            sf1:

                type: num
                visu_acl: ro
                database: init

                # wenn Plugin trovis557x aktiviert
                desc: Speicherfühler 1
                trovis557x_var: SpeichertempSF1
                invalid_to_zero: True
                liste: []

                # wenn Plugin modbus_tcp aktiviert
                name: Speicherfühler 1
                modBusObjectType@trovis: HoldingRegister
                modBusAddress@trovis: 22
                modBusDirection@trovis: read
                modBusFactor@trovis: 0.1
                modBusDataType@trovis: float16
                modBusByteOrder@trovis: 'Endian.Little'
                modBusWordOrder@trovis: 'Endian.Little'

Plan war, derzeit individuelle Modbus-Implementierungen (Plugin trovis557x, danach helios) per modbus_tcp Plugin abzubilden - und das bei Verwendung derselben YAML-Datei, damit alte Datenbankeinträge nicht verloren gehen (bei mir z.B. 10 Sensoren, diverse Pumpen und Ventile über 5 Jahre). Man bekommt aber, je nach aktiviertem Plugin, für jedes Item die dann 'unbekannten' Attribute des jeils anderen Plugins um die Ohren gehauen - pro Item pro Attribut eine Zeile im Log.

Das Trovis-Plugin kann heute schon sowohl RTU als auch TCP. Die Trovis hat zwar -wie auch die Helios- hardwareseitig nur RTU, das sich per speziellem 'wrapping' Adapter aber auch auf TCP bringen lässt. Die Umstellung RTU-->TCP erfordert aber für bestehende Anwender -und davon gibt es einige- meist den Kauf und das Setup der speziellen Adapterhardware, worüber nicht alle 'glücklich' sein werden - daher die Dual-YAML. Es ist vorhersehbar, dass es in den Trovis / Helios Plugins irgendwann mal knallen wird, da sich sich die darunterliegenden Komponenten (z.B. pymodbus) derzeit ständig ändern.

Hintergrund ist, dass ich zukünftig weder das Trovis-Plugin noch das Helios-Plugin aktiv pflegen oder weiterentwickeln werde. Ich wollte also wenigstens eine 'saubere Übergabe' in Form einer langfristigen Lösung (Portierung nach modbus_tcp) implementieren.

Aber wie schon geschrieben: Egal, es stehen derzeit wichtigere Dinge an. Und Cannon hat richtig getippt, dass ich bei den Filtern einfach die andere Datei vergessen hatte. Also alle wieder hinlegen, kein Grund zur Panik.

/tom

[AndreK]

Hallo Tom Bombadil ,

ich habe dazu noch eine Idee. Was hälst Du von folgendem Vorschlag ?

1.) die Attribute aus dem Trovis-Plugin mit "my_" ergänzen, das sind ja nur 6 Stück, via suchen ersetzen in der Item-Definition ohne weiteres mögich. Damit wären diese aus der Prüfung raus.Egal ob das modbus_tcp Plugin oder das Trovis plugin verwendet wird

 trovis557x_var -> my_trovis557x_var

2.) Wenn das modbus_tcp Plugin nicht aktiviert ist werfen natürlich die Modbus-TCP-Attribute einen Fehler, das liese sich umschiffen wenn Du die Item-Attribute des Modbus-Tcp-Plugins in Deine plugin.yaml kopierst.

Damit wärst Du aus meiner Sicht aus allem raus und die Filter, die müsste ja auch jeder Nutzer entsprechend einrichten, können entfallen.
Die Items bleiben gleich und die historischen Daten sind nach wie vor im Zugriff.

Eventuell benötigt ja doch jemand die Prüfung der Meta-Daten auch für andere Plugins und kann oder will den Filter so nicht verwenden.


Viele Grüße
Andre

[Msinn]

Es gibt noch eine weitere (nicht dokumentierte) Möglichkeit.

Das influxdb2 Plugin kann so konfiguriert werden, dass es auch die Attribute des database Plugins nutzt. Dazu sind die Item Attribute des database Plugins im influxdb2 Plugin auch nochmal definiert. Damit dadurch keine Warnung ausgelöst wird, ist das jeweilige Item Attribut mit dem Eintrag **duplicate_use: True** versehen.

    database:
        type: str
        valid_list_ci: ['', 'no', 'yes', 'init', 'true']
        duplicate_use: True
        description:
            de: "Wenn auf 'yes' oder 'true' gesetzt, werden die Werte des Items in die Datenbank geschrieben. Wenn auf 'init' gesetzt, wird zusätzlich beim Start von SmartHomeNG der Wert des Items aus der Datenbank gelesen."
            en: "This attribute enables the database logging when set (just use value 'yes' or 'true'). If value 'init' is used, an item will be initalized from the database after SmartHomeNG is restarted."

[Tom Bombadil]

Danke Andre & Martin. Für beide Vorschläge müsste ich das Plugin nochmal anfassen; bei Andre's Vorschlag direkt in der Programmierung, da hier logischerweise mit den Attributen gearbeitet wird (die sind ja nicht nur zum Schönaussehen da); bei Martin's Vorschlag müsste ich in die plugin.yaml Dinge eingeben, die nicht von mir stammen und sich ggf. zukünftig auch ändern können.

Nach der Implementierung der Items (was ja das eigentliche Ziel dieser eigentlich als 'einfach mal schnell durchziehen' angedachten Aktion ist) dann die Änderungen an der items.yaml PLUS Plugin PLUS plugin.yaml testen und mögliche Fehler beheben, Push zu Git, PR, wie letztes Mal erst monatelang auf den Merge und dann auf ein neues Develop-Release warten usw - den ganzen Kram wollte ich mir eigentlich ersparen. items.yaml überarbeiten, pushen, und gut ist's - klassisches Fire&Forget bei dieser eher nett gemeinten Geste.

Mit den dank Cannon nun funktionierenden Filtern kann ich ja nun vernünftig arbeiten und die zusätzlichen Attribute ohne seitenlanges Scrolling auf mögliche Fehler testen. Wie lange noch, und ob undefinierte Attribute irgendwann überhaupt noch unterstützt werden (wie es mal diskutiert wurde), ist dann nicht mehr mein Problem.

So, Thema für mich durch, bin raus - sorry nochmal, dass ich oben eine simple Frage gestellt habe, soviel Tam-Tam wollte ich damit nicht auslösen.

/tom