Nutzung/Bedeutung von Value in eval Ausdrücken

[Msinn]

on_update / on_change ist ja neu, so wie ich das verstanden habe, hast Du das neu zugefügt.

Ja das habe ich auf Basis meines Verständnisses gemacht und der Diskussionen die darüber seit längerer Zeit kreisten.

Wenn es eine größere Nutzung in der von smai und Dir beschriebenen Form gibt, können wir das gerne so lassen und sauber dokumentieren. Ich möchte auch nicht ohne Not Kompatibilitäten brechen.

Mir ist es nur wichtig das jetzt zu diskutieren, da ich bei einem Großumbau des Core bin. Da sind eine Reihe von Sachen nicht so gelöst, wie man sich das (objektorientiert) wünschen würde:

- Zu Plugins ist fast alles in lib.plugin implementiert. Bis auf eine Methode, die im sh-Objekt hängt
- Zu Items ist fast alles im sh-Objekt implementiert. Bis auf die Item-Klasse selber, die in lib.item implementiert ist.
- etc.

Ich bin dabei diese Methoden in lib.item, lib.plugin, lib.logic, etc. zusammenzuführen und jeweils ein sauber dokumentiertes API zu erzeugen, welches dann z.B. aus Logiken oder Plugins genutzt werden kann.

[mumpf]

Hallo Martin,

Du bist Admin hier Unterforum, oder? Sollte man diese Diskussion nicht aus dem Thread raustrennen? Wir sind ja sehr OT bezogen auf die Ursprungsfrage?
Kannst Du das machen?

Ansonsten sehe ich den Mehrwert der aktuellen Form von value (dem in eval) auf jeden Fall! Ich kan, falls von Dir gewünscht, konkrete Beispiele liefern, bei denen es ohne value nicht ginge. Ich muss dazu nur meine alten item.conf durchgehen (hab noch nichts mit yaml gemacht). Falls Dir das mehr zum Verständnis hilft?

Gefühlt brauche ich value vielen Stellen, aber es wäre interessant, ob die Realität genau so ist wie das "Gefühl".

Gruß, Waldemar

[Msinn]

Ich glaube Du hast auch noch andere Herausforderungen als wir im SmartHomeNG Team. Wir liegen eher bei 1500 bis 2000 Items. Deshalb ist es hilfreich zu erfahren, wie sich mit mit mehr als doppelt so vielen Items die Herausforderungen ändern.

Zum Thema Off-Topic: Das dachte ich auch schon. Ich separiere das ma in einen eigenen Thread.

[mumpf]

Hi Martin,

ja das mit meinen Herausforderungen hast Du gut erkannt. Ich habe allerdings das Problem schon sehr frühzeitig erkannt und schon vor langer Zeit einen Generator geschrieben, der die item.conf erzeugt. Mein eigentliches item-Format ist json. Daraus generiere ich die .conf-Files (früher), derzeit die Datenbank für die callidomus-Items und bin gerade dran, passende .yaml-Files zu generieren - der Weg ist aber noch lang und steinig.

So, aber das war wieder OT. Ich such mal die Beispiele raus.

Gruß, Waldemar

[mumpf]

OK, ein erstes - sehr einfaches - Beispiel:

                [[[[[Schalten]]]]]
                    eval = value
                    eval_trigger = OG.Kind.Licht.Hauptlicht.Schalten
                    knx_send_1 = 8/0/9
                    nw = yes
                    type = bool
                    visu_acl = rw
                    sp = rw
                    cache = True
                    knx_dpt = 1
                    knx_listen = 8/0/0 | 8/0/1
                    knx_send = 8/0/0

Hier ist nur eval = value, aber da kann nichts anderes stehen. Das Item wird per KNX geändert, über eine Logik (direkter setter) und eben auch über das Item OG.Kind.Licht.Hauptlicht.Schalten. Mit shNG würde man hier beim Item OG.Kind.Licht.Hauptlicht.Schalten ein on_change machen und das gleiche erreichen können.

Weitere Beispiele folgen.

[mumpf]

Ein weiteres Beispiel: Werteinschränkung

                    [[[[[[Schlafposition]]]]]]
                        value = 75
                        type = num
                        name = Schlafposition
                        visu_acl = rw
                        eval = value if int(value) >= 10 else 10

Das Item wird per Visu gesetzt, kann keinen Wert kleiner 10 annehmen. Hier sieht man den Unterschied von value als neuer Wert (anders als der Itemwert) oder value als der aktuelle Itemwert (wie Du es bisher verstanden hast).

Folgendes passiert, wenn value den neuen Wert repräsentiert (also aktuelles Verhalten): Schlafposition hat den Wert 10. Per Visu wird 5 gesetzt (value = 5), der eval gibt 10 zurück, Item wird nicht geändert und somit gibt es keine Folgetrigger anderer Items.

Folgendes würde passieren, wenn value den Itemwert repräsentieren würde: Schlafposition hat den Wert 10. Per Visu wird 5 gesetzt, Item nimmt diesen Wert an, Folgeitems werden getriggert. Jetzt wird das eval ausgeführt, gibt 10 zurück, Item nimmt den Wert 10 an und triggert erneut alle Folgeitems. Diesen Fall will man nicht haben.

Den Fall habe ich ca. 50 mal...

Ich schau mal weiter.

[Msinn]

Ok, Bedarf verstanden.

Besonders die Korrektur des von der Visu übermittelten Wertes ist anders nur mit Aufwand realisierbar.

[mumpf]

So, nochmal ähnlich wie der Fall eben:

                [[[[[StateText]]]]]
                    type = str
                    value = Initial
                    name = Name des aktuellen Status der StateEngine
                    eval = 'Automatik: {0}'.format(value)

Das Item wird von der StateEngine gesetzt. Auch hier ist wichtig, das keine unnötigen Item-Changes passieren, da das StateText-Item selbst bei Änderungen weitere Items triggert. Nach aktueller Zählung hab ich 157 Instanzen von StateEngines laufen, somit hab ich diesen Fall 157 mal...

[mumpf]

Ok, habe jetzt erst Deinen Zwischenkommentar gelesen. Aber weil ich es schon rausgesucht habe, hier noch ein Beispiel, warum value mit dem Datentyp der Quelle Sinn macht.

Ich möchte wissen, ob meine zyklisch sendende Baugruppe mit Temperatur und Luftfeuchte immer noch brav sendet:

                [[[[[Valid]]]]]
                    #Sendet der Sensor noch
                    name = Sensor sendet, Werte sind gültig/aktuell
                    type = bool
                    eval = (int(value) < 300)
                    eval_trigger = ..Feuchte | ..Temp
                    autotimer = 6m = 500

Hier ist das Ziel bool, die Quelle num. Früher war die 500 vom autotimer sogar str (weiss nicht, ob das immer noch so ist). Erst im eval wird nach bool umgerechnet. Das Item bleibt einfach so lange true, wie die Sensoren senden (alle 5 Minuten), wenn 6 Minuten nichts empfangen wurde, wird durch den autotimer mit 500 getriggert, der eval macht dann daraus ein false.

So, dann höre ich für heute mal auf, wenn Du noch Fragen hast bzw. Anregungen brauchst, dann nur raus damit.

Gruß, Waldemar