item Funktion für optionalen Namen

[Simikuen]

Hallo,

leider ergab meine Suche keinen Erfolg. :-(

Ich bin dabei eine Logic zu schreiben. Dabei möchte ich den optionalen Namen vom Item mit ausdrucken. Daher die Frage gibt es bei den Items eine Funktion mit der ich den optinalen Namen ausgeben kann?. Mit item.id() bekommt man ja den Itempfad. Sowas bräuchte ich auch für den optionalen Namen.

Besten Dank.

[mumpf]

Hi,

was ist denn für Dich der "optionale Name"? Meinst Du das name-Attribut bei der Item-Definition? Falls ja, das ist item.conf['name']. So bekommst Du alle Attribut-Werte ausgelesen.

Gruß, Waldemar

[Msinn]

Du kannst statt item.path einfach item ausgeben. Falls ein Name definiert ist, wird dann der Name ausgegeben, falls kein Name definiert ist, wird der Pfad ausgegeben.

[Simikuen]

Hi,

was ist denn für Dich der "optionale Name"? Meinst Du das name-Attribut bei der Item-Definition? Falls ja, das ist item.conf['name']. So bekommst Du alle Attribut-Werte ausgelesen.

Gruß, Waldemar

Ja genau das meine ich.

nur bekomme ich bei item.conf['name'] im Log einen KeyError: 'name'. Es funktioniert nur wie von Msinn beschrieben.

Muss da eventuell noch was importiert werden?

[Msinn]

item.conf['name'] soltest Du nicht unbedingt nutzen, wenn es nicht notwendig ist. Der Zugriff auf die Konfiguration von Items wird übrigens in den kommenden Versionen von SmartHomeNG überarbeitet.

Als erstes werden mit der Version 1.6 folgende Änderungen eingeführt (die bereits im develop Branch implementiert sind):

• Bisher kann der Pfad über item.id() ermittelt werden. Zusätzlich wird mit v1.6 dazu item.path() eingeführt und soll längerfristig item.id() ersetzten
• Bisher kann der Name (bzw. Pfad, falls kein Name definiert ist) über item ermittelt werden. Zusätzlich wird mit v1.6 dazu item.name() eingeführt und soll längerfristig item ersetzten.

Weiterhin werden Methoden eingeführt um auf andere Konfigurations-Attribute zuzugreifen, ohne die interne Speicherstruktur (item.conf['Attribut-Name']) zu nutzen. Das ist die Voraussetzung, damit in späteren Versionen die interne Struktur zur Speicherung der Attribute geändert werden kann.

[Simikuen]

Hi Msinn,

besten Dank für die Info. Werde wie vorgeschlagen nur item verwenden.

Grüße
Mirko

[mumpf]

Hi Martin,

Bisher kann der Pfad über item.id() ermittelt werden. Zusätzlich wird mit v1.6 dazu item.path() eingeführt und soll längerfristig item.id() ersetzten

Warum das? Ich will nichts gegen den zusätzlichen item.path() sagen, es mag ja Leute geben, die die Item-Id als Pfad betrachten, nichtsdestotrotz ist item.id() korrekt und ein entfernen erzeugt bei allen Usern Arbeit, ohne irgendeinen Vorteil zu bieten.

Weiterhin werden Methoden eingeführt um auf andere Konfigurations-Attribute zuzugreifen, ohne die interne Speicherstruktur (item.conf['Attribut-Name']) zu nutzen.

Das finde ich sehr gut, macht den Zugriff sicherlich einfacher. In einem solchen Falle müssen zwar auch alle User Nacharbeiten, hier gibt es aber eine Vereinfachung und es steigert die Übersichtlichkeit. Du denkst aber daran, dass es am Item frei wählbare Attribute gibt, auf die man auch weiterhin zugreifen können will?

nur bekomme ich bei item.conf['name'] im Log einen KeyError: 'name'.

Ich glaube, dass bei dem Item dann kein Name vergeben wurde, oder? Ein Attribut, das Du nicht setzt, ist natürlich in der conf nicht enthalten. Der Zugriff auf item berücksichtigt das und gibt in dem Fall dann die id aus. Da steht also so was wie

return item.conf['name'] if 'name' in item.conf else item.id()

Gruß, Waldemar

[Simikuen]

Hi Waldemar,

das dachte ich auch das Name nicht gesetzt ist. Daher habe ich mal die einzelnen Möglichkeiten mir ausprinten lassen.

2018-10-29  10:53:16 WARNING  logics.AnzahlOffeneFenster Ausgabe von item(): ( 2)
2018-10-29  10:53:16 WARNING  logics.AnzahlOffeneFenster Ausgabe von item.id(): ( EG.Wohnzimmer.Fenster3)
2018-10-29  10:53:16 WARNING  logics.AnzahlOffeneFenster Ausgabe von item: ( Balkontuer EG Wohnzimmer Ost)
2018-10-29  10:53:16 ERROR    logics.AnzahlOffeneFenster Logic: logics.AnzahlOffeneFenster, File: /usr/local/smarthome/logics/AnzahlOffeneFenster.py, Line: 15, Method: <module>, Exception: 'name'
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/scheduler.py", line 493, in _task
    exec(obj.bytecode)
  File "/usr/local/smarthome/logics/AnzahlOffeneFenster.py", line 15, in <module>
    logger.warning("Ausgabe von item.conf['name']: ( {0})".format(item.conf['name']))
KeyError: 'name'

die item.yaml sieht so aus

EG:

    Wohnzimmer:

        Fenster1:
            type: bool
            knx_dpt: 1
            knx_cache: 0/5/5
            knx_listen: 0/5/5
            knx_init: 0/5/5

        Fenster2:
            type: bool
            knx_dpt: 1
            knx_cache: 0/5/6
            knx_listen: 0/5/6
            knx_init: 0/5/6

        Fenster3:
            name: Balkontuer EG Wohnzimmer Ost
            type: num
            eval: sum
            eval_trigger:
              - EG.Wohnzimmer.Fenster1
              - EG.Wohnzimmer.Fenster2

Python Codeschnipsel

for item in sh.match_items('EG.Wohnzimmer.Fenster3'):
    logger.warning("Ausgabe von item(): ( {0})".format(item()))
    logger.warning("Ausgabe von item.id(): ( {0})".format(item.id()))
    logger.warning("Ausgabe von item: ( {0})".format(item))
    logger.warning("Ausgabe von item.conf['name']: ( {0})".format(item.conf['name']))
    if item() < 2:
        counter.append(item)

auf die anderen Attribute von Fenster3 komme ich aber auch nicht. Habe auch versucht item.conf['name'] das in eine Variable zu bringen. Kommt aber identischer Fehler.

Grüße
Mirko

[mumpf]

Hi Mirko,

sorry, dann scheint das nicht für alle Attribute zu gelten und ich lag falsch. Ich verwende das primär für eigene Attribute und ging davon aus, dass alle Attribute in der conf stehen. Sorry für die Falschinformation, aber die Lösung mit item reicht ja...

Gruß, Waldemar

[Simikuen]

Hi Mirko,

sorry, dann scheint das nicht für alle Attribute zu gelten und ich lag falsch. Ich verwende das primär für eigene Attribute und ging davon aus, dass alle Attribute in der conf stehen. Sorry für die Falschinformation, aber die Lösung mit item reicht ja...

Gruß, Waldemar

klar. Reicht für mich.

[Msinn]

Noch ein paar Anmerkungen als Kommentare:

for item in sh.match_items('EG.Wohnzimmer.Fenster3'):

    # item() gibt den Item Wert aus, item gibt den Namen/Pfad aus
    logger.warning("Ausgabe von item(): ( {0})".format(item()))

    logger.warning("Ausgabe von item.id(): ( {0})".format(item.id()))
    logger.warning("Ausgabe von item: ( {0})".format(item))

    # in das conf dictionary werden nur Konfigurationsattribute übernommen, die von der
    # Item Klasse nicht intern verwendet werden.
    # Eine Möglichkeit ohne Exception ist item.conf.get('name', ''), wobei der 2. Parameter ''
    # der Wert ist, der Zurückgeliefert wird, falls es den Key nicht gibt.
    logger.warning("Ausgabe von item.conf['name']: ( {0})".format(item.conf['name']))

    # Verstehe ich nicht ganz: Wenn der Wert des Items < 2 ist, wird der Name des Items
    # an eine Liste angehängt die den Namen 'Counter' trägt?
    if item() < 2:
        counter.append(item)

[Msinn]

Warum das? Ich will nichts gegen den zusätzlichen item.path() sagen, es mag ja Leute geben, die die Item-Id als Pfad betrachten, nichtsdestotrotz ist item.id() korrekt und ein entfernen erzeugt bei allen Usern Arbeit, ohne irgendeinen Vorteil zu bieten.

Ich sprach von längerfristig und denke dabei an ein Release, welches sowieso eine Reihe von Breaking Changes bringen wird (z.B. Wegfall der conf Dateien). Das wird dann ein SmartHomeNG v2.0 sein (wann immer das kommen wird). Dabei möchte ich dann auch die Breaking Changes (soweit möglich) durch ein Migrationstool abfedern, welches eventuell auch in allen Logiken (und schon vor dem Release in den Plugins) auch eine Textersetzung von <item>.id zu <item>.path vornehmen könnte.

Im Moment ist mein Satz eher so zu verstehen, dass man ab v1.6 lieber <item>.path als <item>.id und <item>.name als <item> verwenden sollte.

[walldi]

Hallo,
in Python gibt es @property, womit sich die Implementierung von Attributen von der Verwendung abschirmen lässt und wodurch der Verwender eine eindeutige einfache Syntax an die Hand bekommt: zB wäre
item.id und item.name unmissverständlich. Und name würde man so definieren, dass es immer ein sinnvoller Wert geliefert wird, auch wenn nicht explizit definiert. ZB CamelCase(id).
item ist die Instanz des Objekts. Dass '{}'.format(item) auch name oder id liefert, ist ok aber nicht intuitiv. (__repr) Eigentlich nur für Debugging sinnvoll.
Ich fand immer, der Zugriff auf den Wert sollte item.val heißen, statt item(), aber...
Und dann sollten alle(!) Conf. - Attribute einheitlich und Mi-fest über ein @property Dict (zB: item.conf['cron'] zugänglich sein.
My 2ct.

[walldi]

... Zusätzlich wird mit v1.6 dazu item.path() eingeführt und soll längerfristig item.id() ersetzten...

=> warum ???

[Msinn]

item ist die Instanz des Objekts. Dass '{}'.format(item)

So ist es aber im ursprünglichen smarthome.py nicht implementiert worden (siehe __str__() Methode). Daher haben wir die ganze Verwirrung, die ich in der Zukunft auflösen möchte. Im ursprünglichen smarthome.py wurde auch kein @property Decorator genutzt (falls es ihn damals überhaupt schon gab).