eval_update_item - Update auf fremde Items

[Tom Bombadil]

Hallo,

was mich bereits häufiger zu aufwendigen Logiken oder Item-Bäumen mit Hilfsitems genötigt hat, ist die nicht vorhandene Funktion, 'fremde' Items mit einem Wert zu befüllen.

Dies betrifft insbesondere Items, die 'hart' mit einem Plugin für ein Bus- oder Remotesystem verbunden sind und auf diese Weise in beide Richtungen Konnektoren zwischen sh.py und dem Gerät bilden (bei mir z.B. mehrere Anbindungen über RS485). Die Anbindung ist eigentlich immer nur durch Verrenkungen zu machen.

Für KNX gibt es da ja bereits eine Art Sonderlösung ('knx_send' usw). Natürlich kann man die Item-Attribute nicht für jedes beliebige Plugin unendlich erweitern, das geht schon rein logistisch nicht.

Daher an die Entwickler: Wir haben (mal exemplarisch) eval und eval_trigger. Wäre es möglich, ein zusätzliches Attribut 'eval_update_item' zu schaffen, das den eigenen Wert zusätzlich noch in ein weiteres Item schreibt?

Mir ist bewusst, dass das mit einigen Grundsätzen von sh.py bricht und wahrscheinlich auch gleich die Hölle zufrieren wird, gepaart mit derben Flüchen von Vollblut-Programmierern, sich doch gefälligst an die Konventionen zu halten.

Gleichwohl würde es den Aufbau von vielen Systemen wahrscheinlich *deutlich* vereinfachen und viele Item-Strukturen weniger komplex und verständlicher machen. Der Preis wäre vermutlich ein erhöhter Support-Aufwand hier im Forum, weil es dann auch für den Laien zu einfach wird, mal eben schnell was aufzusetzen, wo es dann zick-zack durch die Itemstruktur geht. Aber dafür sind 'wir' ja dann da.

Danke für Euer Feedback,
/tom

[ivande]

Hallo Tom,

ich befülle fremde Items mit Hilfe eines untergeordneten Items "set_item" welches eine kleine Logik(set_item.py) triggert. Die Logik sucht innerhalb von "set_item" nach dem Attribut "item" , im welchen das zu befüllende Item (und evtl. auch der zu befüllende Wert in Klammern) angegeben werden kann.


set_item.py

#!/usr/bin/env python
#
#logger.info("praesenz")

#Beispiel
#item.conf
#[item_to_set]
#    type = num
#[xy]
#    [[set_item]]
#       type = num
#       eval = sh.xy()
#       eval_trigger = xy
#       item = sh.item_to_set(1) # fuelle fremdes Item mit "1"
#       #item = sh.item_to_set # fuelle fremdes Item mit Value von set_item
#
#logic.conf
#[set_item]
#    filename = set_item.py
#    watch_item = *.set_item

    
value = int(trigger['value']) # Wert des Ausloesenden Items
sourceItem = sh.return_item(trigger['source']) # Ausloesendes Item
item_x = sourceItem.conf['item'] # suche nach Attribut "item"

indexKlammerAuf = item_x.find('(')
indexKlammerZu = item_x.find(')')
indexSH = item_x.find('sh.')
if indexKlammerAuf == -1:
    x_value = value
    indexKlammerAuf = len(item_x)
else:
    # zu schreibender Wert zwischen den Klammern
    x_value = item_x[indexKlammerAuf+1:indexKlammerZu]
if indexSH == 0:
    item_str = item_x[3:indexKlammerAuf]
else:
    item_str = item_x[0:indexKlammerAuf]
# hole zu befuellenden Item aus String
item_x_action = sh.return_item(item_str)
if item_x_action is not None:
    #if value == 0:
    #    item_x_action(0) # schreibe den Wert in das Item
    #else:
    item_x_action(x_value) # schreibe den Wert in das Item
    result = item_x_action()

logger.debug('fuelle item: {0} mit: {1}'.format(item_x, x_value))

Ich verwende dies nicht oft. Außer bei verzwickten eval- und Unteritem- Situationen,..

Expertemeinungen: Befüllen fremder Items zukünftig evtl. direkt durch SH?

Gruß Ivan

[smai]

Ich habe noch nicht ganz verstanden, weshalb du nicht einfach auf dem Ziel-Item einen eval_trigger und ein eval = value machst.
Damit kann das Ziel-Item entweder direkt beschrieben werden, es holt sich aber auch den Wert des anderen Items.

Oder habe ich irgend etwas übersehen? Vielleicht magst du mal ein config-Beispiel zeigen.

[Tom Bombadil]

Hallo Ivan,

danke, die Logik ist netter Workaround!

Ohne den zugehörigen Sourcecode in smarthomeNG zu kennen - für die oben vorgeschlagene Variante dürfte wohl nicht mehr als ein 3...5-Zeiler zu ergänzen sein, denn das Zielitem ist ja bekannt (von Hand im Item konfiguriert), und der Zielwert ebenfalls (aus der eval-Abarbeitung bzw. dem Item selbst). Fehlt nur die eigentliche Zuweisung und ggf. notwendige Prüfungen (sofern überhaupt erforderlich).

Bei mir kommt oben geschilderter Fall häufiger vor, und auch hier aus dem Forum fallen mir spontan etliche Fälle ein, wo das Schreiben auf Items uns einiges an Support gespart hätte.

Und wenn ich es richtig verstanden habe, ist es ja nicht das Ziel von smarthomeNG, den "größten" Baum mit einer Ansammlung von steng logisch und elegant aufgebauten Hilfsitems des jeweils richtigen Datentyps zu haben - sondern ein einfaches, funktionierendes und wartbares System ...

/tom

[Tom Bombadil]

Ich habe noch nicht ganz verstanden, weshalb du nicht einfach auf dem Ziel-Item einen eval_trigger und ein eval = value machst.

Beispiel KWL Lüftungsstufe - die kann gesteuert werden über:

- integrierte Anlagenlogik
- Gerät am gleichen oder einem anderen Bus (Fernbedienung, Sensor, KNX, ...)
- manuelle Eingabe der Lüftungsstufe in der Visu
- Stoßlüftungstaste in der Visu (triggert gleichzeitig Logik oder Item-autotimer, um später wieder auf vorherige Stufe zurückzuschalten),
- diverse Logiken (CO2-Schwellwerte, Anwesenheitssensor, UZSU-Zeitschaltung, automatischer Sommerbypass + Stoßlüftung nachts, Winter-Frostschutz),
- diverse evals auf zugehörigen Items.

Ok, zugegeben, Logik ist einfach. Aber es geht ja um die Items. ;-)

Das sind nur die Punkte, die mir spontan einfallen, da gibt's sicher noch mehr. Alle diese Werte gehen über ein und dasselbe Connector-Item "Lüftungsstufe" zum Schreiben oder Lesen auf den KWL-Bus. Mal davon abgeshen, das ich einem eval auf einem direkt mit dem Bus veknüpften Item nicht so recht traue (was wahrscheinlich Quatsch und ne persönliche Macke ist) - das eval für alle oben genannten Dinge möchte ich mal ohne diverse Hilfsitems sehen, dürfte ne recht lange Zeile werden ...

Ein anderes Beispiel ist z.B. Heizungssteuerung, oder jedes weitere Gerät, das über einen eigenen Bus am smarthomeNG hängt und über mehr als nur ein oder zwei Parameter, Items oder Logiken gesteuert wird.

/tom

[dafra]

+1

Ich löse das bei mir auch immer über (Trivial-)Logiken, die ich mir gerne sparen würde.

Mein Beispiel: Ich habe eine Gruppe von Hues, die ich sowohl einzeln als auch in der Gruppe steuern möchte. Das Gruppen-Item bekommt seine Befehle vom KNX Bus und aus der Visu, einzeln steuern geht nur über die Visu. Wenn das Gruppen-Item geändert wird, läuft das Skript welches all HUE-Items aktualisiert.
Wenn das Gruppen Item einfach via 'set_Item' (oder 'eval_update_item' oder wie auch immer) alle Lampen direkt schreiben könnte anstatt über den Umweg "Logik", wäre das deutlich schlanker.

Voraussetzung wäre natürlich, dass man mehrere fremde Items angeben kann, die aktualisiert werden.

Gruß, Daniel

[smai]

Das Hue-Beispiel lässt sich doch genau per eval_trigger lösen:

[hue_all]
knx_listen = 1/0/0
[[hue1]]
knx_listen = 1/1/0
[[[hue1a]]]
eval = value
eval_trigger = hue_all | hue_all.hue1
knx_listen = 1/1/1
[[[hue1b]]]
eval = value
eval_trigger = hue_all | hue_all.hue1
knx_listen = 1/1/2
[[hue2]]
knx_listen = 1/2/0
[[[hue2a]]]
eval = value
eval_trigger = hue_all | hue_all.hue2
knx_listen = 1/2/1

So kann z.B. hue1 per 1/0/0, 1/1/0 oder 1/1/1 gesetzt werden, ohne Logik oder kompliziertem eval. Oder sehe ich das falsch?

Versteht mich nicht falsch, ich bin nicht gegen die Idee. Ich wollte nur aufzeigen, dass es auch ohne Logik geht.

Vom Namen her würde ich übrigens set_item deutlich bevorzugen, da es mit eval ja eigentlich nicht direkt zu tun hat.

[dafra]

... stimmt, aber dann habe ich anstatt einer Logik ein Hilfsitem (für jeden trigger ein Item + das 'eigentliche' Item) - so wie Tom es im ersten Post beschrieben hat. Es sei denn, eval_trigger funktioniert auch auf das Item selbst. Das weiß ich gerade nicht, müsste ich mal ausprobieren. Trotzdem danke für den Denkanstoß.

Gruß, Daniel

[Tom Bombadil]

Solange KNX im Spiel ist, kann man den Bus quasi als Register nutzen und 'über Bande' (knx_listen) trotzdem irgendwie noch geschickt fremde Items befüllen. Alle Anwender ohne KNX (was die Mehrheit der potentiellen Anwender sein dürfte und mich selbst einschliesst) sind aber Hoëcker - da geht's nur mit diversen Hilfsitems ...

/tom

[smai]

Ich glaube, ich bin zu doof oder kompliziert um das zu verstehen.

Mein Beispiel müsste doch auch ohne KNX funktionieren, eval_trigger löst meines Wissens auch aus, wenn du den Wert per Visu, OneWire oder was auch immer setzt.

Und pro Trigger ein Item brauchst du doch auch bei der Logik, oder wie triggerst du die? Du schreibst ja selbst auch vom "Gruppen-Item".
Bzw. was verstehst du unter Trigger? Dasselbe Gruppen-Item kann natürlich auf unterschiedlichen Wegen (z.B. Visu und KNX) gesetzt werden.

Was ich grad nicht weiss, ob ein per eval_trigger gesetztes Item wiederum einen eval_trigger bei einem anderen Item auslöst. Oder was meinst du mit "auf das Item selbst"?

Vielleicht denk ich aber auch zu sehr in KNX, ich war mir nicht bewusst, dass überhaupt jemand SH ohne KNX einsetzt.

[Tom Bombadil]

ich war mir nicht bewusst, dass überhaupt jemand SH ohne KNX einsetzt.

Genau da liegt IMHO das Denkproblem. Es heißt ja smartHOME, nicht smartKNX. Es gibt viele Anwender, die es ohne KNX einsetzen.

/Tom

Nachtrag: Und es gibt mit Sicherheit auch einen Grund, warum es für KNX eigene Variablen auf den Items gibt, die man als 'Normal-User' nicht verwenden kann. Damit wird im Grunde das gemacht, worum es in diesem Thread geht.

[smai]

Das Denkproblem sehe ich trotzdem nicht, wie geschrieben funktioniert meine Struktur auch ohne KNX.
Vielleicht bin ich mir aber einfach gewohnt, dass man mit KNX für alles eine separate Gruppenadresse und damit oft auch ein Item hat und für euch ist das dann ein ungewolltes Hilfs-Item.

P.s. ohne KNX ists ja nicht richtig smart *duckundrenn*

Zu deinem Nachtrag: Das sind einfach Attribute, die im KNX-Plugin definiert sind. Sowas kann jedes Plugin und jede Logik definieren, ist nix spezielles für KNX.
Und diese Attribute bewirken einfach, dass etwas auf den KNX-Bus gesendet oder davon gelesen wird. Aber das brauchst du ja auch für jeden anderen Bus oder Funkprotokoll wie bei der Hue.
Oder schreibst und liest du alles in selbst implementierten Logiken?

[Tom Bombadil]

Schau Dir mal diesen Beitrag aus dem Visu Forum an, und dann die Lösung, wie man das ganze geschickt über Items lösen kann, wenn KNX im Spiel ist.

Und selbst da behaupte ich, dass mehrere verteilte Items vom Typ 'Level' mit der gleichen GA im Spiel sind, wenn der Threadersteller die Anlage auch noch über eine Visu tagsüber stufenweise regeln will (boost macht man eher selten).

Jetzt streiche mal alle knx_ Zeilen, und versuch das über ein einziges Item 'level' ohne Redundanz zu lösen (unter Berücksichtigung aller Einflussfaktoren, siehe oben, ich schick Dir auch gern mal mein halbfertiges helios.items mit mittlerweile knapp 1000 Zeilen). Wenn Du es fertig hast gern an mich, ich kann's brauchen, ich tüftel an den Logiken und Evals und Hilfsitems schon seit über 2 Jahren ...

/tom

[Tom Bombadil]

Zu deinem Nachtrag: Das sind einfach Attribute, die im KNX-Plugin definiert sind. Sowas kann jedes Plugin und jede Logik definieren, ist nix spezielles für KNX. Und diese Attribute bewirken einfach, dass etwas auf den KNX-Bus gesendet oder davon gelesen wird. Aber das brauchst du ja auch für jeden anderen Bus oder Funkprotokoll wie bei der Hue. Oder schreibst und liest du alles in selbst implementierten Logiken?

Ja, z.B. in einem erweiterten Plugin (ursprünglich implementiert von @marsellus), nur mit eigenen Items, Hilfsitems und Logiken. Ändert aber nichts an der Grundsituation, und wir schweifen vom eigentlichen Thema ab.

/tom

[smai]

Und selbst da behaupte ich, dass mehrere verteilte Items vom Typ 'Level' mit der gleichen GA im Spiel sind, wenn der Threadersteller die Anlage auch noch über eine Visu tagsüber stufenweise regeln will (boost macht man eher selten).

Da stimme ich dir definitiv zu.

Aber das Streichen der knx-Zeilen ändert ja nichts, ausser dass du ja [[[level]]] auf irgend eine andere Art an das Gerät schicken musst, wie machst du das?
Falls du in diesem Beispiel das Boost-Level einfach auf ein anderes Item übertragen willst, kannst du dort ja ein eval_trigger = kwl.boost.level machen.

Dein Einwand im Thread dort ist übrigens ebenfalls korrekt. Falls jemand das Level sonstwie verändert hat, wird das nicht berücksichtigt. Da auf kwl.boost.level nur ein knx_send und kein knx_listen ist, reagiert dieses auch nicht auf den Bus sondrrn sendet nur.

Im eval darf man übrigens auch den Wert von anderen Items setzen, man könnte also folgendes machen:

     [[boost]]
           type = bool
           visu_acl = w
           autotimer = 25 = 0
           eval = sh.kwl.level(204) if value else sh.kwl.level(sh.kwl.level_alt())
       [[level]]
           type = num
       [[level_alt]]
           type = num
           cache = True
           eval = sh.kwl.level_alt() if sh.kwl.level.changed_by() == 'Init' else sh.kwl.level.prev_value()
           eval_trigger = kwl.level

Das level habe ich eine Ebene nach oben geschoben, weil es ja eben nicht nur von boost her verwendet werden soll.