Item Attribute is undefined

[z1marco]

Hallo,

ich hab ne Frage zu den Items in SmarthomeNG. Ich bin vom Image 1.7.1 auf 1.8.2 umgestiegen.

Ich hatte bei 1.7.1 so eine Nachdimmen Funktion implementiert. Diese funktioniert leider nicht mehr.

Ich hab folgende Fehlermeldung weil er das Item wohl nicht kennt.

Item 'EG.Schlafzimmer.Licht_Decke', attribute 'nachdimm_wert': Attribute is undefined and has value '50' (defined in eg.yaml)

Folgende Item Konfiguration hab ich:

Licht_Decke:
    type: bool
    autotimer: 120m = 0
    knx_dpt: 1
    knx_send: 1/1/115
    knx_listen: 1/1/116
    nachdimm_wert: 50
    nachdimmen:
        type: bool

Warum kann SmarthomeNG nicht mit dem Attribute nachdimm_wert umgehen? Früher hat das geklappt.

Ich hab eine Logik mit watch_item: '\*.nachdimm_wert' laufen.

vielen Dank für Eure Erklärung

[bmx]

Weil es derzeit keinen Mechanismus gibt um eigene Attribute zu definieren und mit Typprüfung zu versehen. Das wäre eine Erweiterung im Core. Derzeit werden nur von bekannten Plugins über die Definition der Attribute im Plugin Typprüfungen vorgenommen.
Du kannst ja mal ein Issue auf Github erfassen damit das nicht in Vergessenheit gerät. Funktionieren sollte das aber eigentlich trotzdem...?

[z1marco]

OK. War das immer schon so? Bei wem läuft denn die Nachdimm Logik aus der Dokumentation mit 1.8.2?

Im Admin Interface ist dieses Attribut nicht vorhanden. Deswegen scheint das watch_item auch nicht zu funktionieren. Ich will ja im Prinzip wenn ein Nachdimm Wert gesetzt ist die Logik auslösen?

Hab schon Log ausgaben in die Logik gesetzt und die Logik wird nicht ausgeführt. Vermutlich weil es das Attribut nachdimm_wert nicht gibt.

[z1marco]

Sorry für den Doppelpost. Ich dachte dass ich mit meinen Fragen mein Problem lösen kann. Dies scheint leider nicht der Fall zu sein. Für mein Grundproblem Nachdimmen hatte ich einen neuen Post eröffnet. Dort werde ich meine Erkenntnisse posten. Es geht aber nicht und es muss wohl eine Umstellung zwischen 1.7.1 und 1.8.2 gegeben haben.

https://knx-user-forum.de/forum/supp...n-von-leuchten

[Cannon]

Ja die Prüfung der Attribute wurde meiner Erinnerung nach in der Version 1.8. eingebaut. Ich bin über dieses Feature auch nicht sonderlich glücklich, da nach jedem Start erst mal 2000 Zeilen ins Log geschrieben werden, weil meine Attribute aus Logiken kommen.

[Tom Bombadil]

Ja die Prüfung der Attribute wurde meiner Erinnerung nach in der Version 1.8. eingebaut. Ich bin über dieses Feature auch nicht sonderlich glücklich, da nach jedem Start erst mal 2000 Zeilen ins Log geschrieben werden, weil meine Attribute aus Logiken kommen.

Ist bei mir auch so - da die angemaulten Items auch in meinen beiden wichtigsten Plugins sowie diversen Logiken verwendet werden, schreibt man eben auch nicht mal schnell mal ein my_ davor, ohne vorher wieder tiefer in die Pluginmechaniken einzusteigen. Auch wird dadurch IMHO die Flexibilität der Verwendung von Items eingeschränkt - ich mache hier sehr viel mit 'User defined Attributes', was früher absolut zulässig und kein Problem war.

Wenn ich es richtig gelesen habe, wurden in 1.9.1 weitere Änderungen/Anpassungen am Handling dieser Attribute implementiert. Für mich der Hauptgrund, bei meiner uralten Version zu bleiben und keine shNG-Upgrades mehr einzuspielen. Zu viele unangenehme Überraschungen in der jüngeren Vergangenheit - und es funktioniert grad alles so schön, bis eben auf diese Fehlermeldungen im Log, aber damit kann ich leben ...

/tom

[Msinn]

Die Erfahrungen mit der Prüfung der Item Attribute sind unterschiedlich. Bei einigen Anwendern hat sich gezeigt, dass die Prüfung sie auf Fehler (z.B. falsche Attributnamen) hinwies oder auch darauf, dass Attribute in der Konfiguration eingetragen waren, die es "nicht gab", die also keine Funktion hatten (ausser Verwirrung zu stiften).

Mittelfristiges Ziel ist, dass alle benutzten Item Attribute definiert sind (mit Typ, Default, gültigen Werten, ...). Dadurch können Fehlkonfigurationen besser erkannt werden und ein geplanter GUI Editor für die Item Dateien benötigt diese Informationen, um je nach Typ einen passenden Attribut-Wert Editor (mit Prüfungen) zur Verfügung zu stellen.

Die Möglichkeit bei benutzerdefinierten Item-Attributen ein my_ davor zu schreiben um die Warnung zu unterdrücken stellt auch nur eine Übergangslösung dar. Damit weiss dann der Anwender zumindest auch noch in fernerer Zukunft, dass es sich um ein von ihm definiertes Attribut handelt, welches nicht von Plugins verwendet wird.


Bei Attributen, die in Plugins verwendet werden sollte es auch nicht notwendig sein ``mal schnell mal ein my_ davor`` zu schreiben. Attribute die von Plugins verwendet werden, sind ja in den Metadaten des Plugins definiert und daher bekannt und lösen keine Warnung aus.

Geplant ist, mit dem Release 1.10 eine Möglichkeit zu schaffen, benutzerdefinierte Attribute analog zu den Definitionen in den Plugins (mit Typ, etc.) zu definieren.

[Cannon]

Geplant ist, mit dem Release 1.10 eine Möglichkeit zu schaffen, benutzerdefinierte Attribute analog zu den Definitionen in den Plugins (mit Typ, etc.) zu definieren.

Das klingt doch toll!

[Tom Bombadil]

Schon verstanden, Martin - bei allem Respekt vor Deiner Arbeit, aber ich bleib bei meiner alten Version. Wir reden hier eben nicht über 'dann muss ich mal eben ein oder zwei Attribute anpassen'.

Im folgenden Beispiel sind die Details aus Gründen der Lesbarkeit an dem Item definiert, wo auch der zugehörige Wert drinsteht. Wenn ich Dich richtig verstanden habe, muss ich zukünftig für jedes 'eXX' eine eigene Typdefinition machen??? Verschieben in den Plugin-Code fällt aus - ich habe keine Lust, bei jedem Firmwareupdate zu prüfen, ob es vielleicht neue Fehlertypen gibt:

Item (Value wird per RS485 gelesen - jedes eX erzeugt eine Log-Fehlerzeile beim Startup):

ventilation:

        _device_error:

            name: Aus der KWL ausgelesener Fehlercode
            type: num
            helios_var: device_error
            visu_acl: ro
            # Fehlercodes aus dem Handbuch für die Fehleranzeige in der Visu --> ErrNo:Name:Description:Countermeasures
            e0:   0:Kein Fehler:Kein Fehlertext:Keine Fehlerbehebung
            e1:   1:?:?:?
            e2:   2:?:?:?
            e3:   3:?:?:?
            e4:   4:?:?:?
            e5:   5:Zuluftsensor defekt:Fühler lose, Kurzschluss <br/>oder Temperatur >90°C gemessen:Gerätestecker ziehen (ausschalten), kurz warten und wieder einstecken
            e6:   6:CO2-Alarm:CO2-Wert >5.000 ppm seit mehr als 3 Minuten:Ursache ermitteln oder ggf. Sensor überprüfen lassen.
            e7:   7:Außenluftsensor defekt:Fühler lose, Kurzschluss oder Temperatur >90°C gemessen:Gerätestecker ziehen (ausschalten), kurz warten und wieder einstecken
            e8:   8:Abluftsensor defekt:Fühler lose, Kurzschluss oder Temperatur >90°C gemessen:Gerätestecker ziehen (ausschalten), kurz warten und wieder einstecken
            e9:   9:Frostwarnung:Außenluft <0°C und Zuluft <8°C - Frostgefahr am Wärmetauscher:Der Alarm verschwindet automatisch bei normalisierten Temperaturen
            e10: 10:Fortluftsensor defekt:Fühler lose, Kurzschluss oder Temperatur >90°C gemessen:Gerätestecker ziehen (ausschalten), kurz warten und wieder einstecken

Auswertung für die Visu weiter unten in derselben .yaml:

ventilation:

    alarms:

        last_error:
            name: Aktueller Fehler
            type: str
            value: "'':'':'':''"
            eval: str(eval("sh.ventilation.rs485._device_error.conf['e" + str(sh.ventilation.rs485._device_error()) + "']"))
            eval_trigger: ventilation.rs485._device_error

            code:
                name: Bezeichnung des aktuellen Fehlers
                type: str
                value: ''
                eval: self.return_parent()().split(':')[0]
                eval_trigger: ventilation.alarms.last_error

            description:
                name: Beschreibung des aktuellen Fehlers
                type: str
                value: ''
                eval: self.return_parent()().split(':')[1]
                eval_trigger: ventilation.alarms.last_error

            cause:
                name: Ursache des aktuellen Fehlers
                type: str
                value: ''
                eval: self.return_parent()().split(':')[2]
                eval_trigger: ventilation.alarms.last_error

            solution:
                name: Behebung des aktuellen Fehlers
                type: str
                value: ''
                eval: self.return_parent()().split(':')[3]
                eval_trigger: ventilation.alarms.last_error

Randbemerkung: Ich weiss, es gibt mittlerweile elegantere Methoden für das .split(), sowie auch relative Itemadressierung und structs für die Items unten - aber das hier läuft stabil seit ca. 2014/2015, und es gab bisher keinen Grund, es noch einmal anzufassen.

Etliche weitere Beispiele dieser Art sind hier vorhanden und laufen im Operativsystem ...

/tom

[Msinn]

'eXX' eine eigene Typdefinition machen???

Nein.

In den Item Definitionen gibt es auch bereits zwei Abschnitte, die Attribute definieren;

• item_attributes: Definiert einzelne Item Attribute
• item_attribute_prefixes: Definiert Prefixes für eine Gruppe von Attribut Namen, die erst zur Konfigurationszeit ihren vollständigen Namen erhalten. Ein Plugin, welches das intensiv nutzt ist z.B. das stateengine Plugin.

Wenn die vollständige Definition der Benutzer-Attribute kommt, würde item_attribute_prefixes Dein oben geschildertes Problem lösen.