Item für Wert über/unterschreiten und Zeitkomponente

[Msinn]

Ich habe mal kurz in das timmy Plugin geschaut. Das was ich zur Implementierung für das Zeitglied für die Hysterese brauche ist allerdings viel simpler.

Ich habe mich heute morgen rangesetzt und das Zeitglied für den unteren und den oberen Schwellwert in ca. 20 Zeilen Code im Item Objekt dazu implementiert bekommen. Ich muss das jetzt nur noch ausgiebig testen.

Die Konfiguration wird folgendermaßen aussehen:

hysterese_input:
    type: num
    name: 'z.B. Helligkeit'
    ...​
​
hysterese_item:
    type: bool
    name: 'z.B. Beschattung an/aus'
    hysteresis_input: ..hysterese_input
    hysteresis_upper_threshold: <oberer Schwellwert> % <Mindestdauer in Sekunden>
    hysteresis_lower_threshold: <unterer Schwellwert> % <Mindestdauer in Sekunden>

Schwellwerte und Mindestdauern können als Float Werte angegeben werden.

Wenn die Hysterese für einen oder beide Schwellwerte ohne Mindestdauer konfiguriert werden soll, wird einfach % <Mindestdauer in Sekunden> weg gelassen:

helligkeit:
    type: num
    ...​
​
beschattung:
    type: bool
    hysteresis_input: ..helligkeit
    hysteresis_upper_threshold: 5000
    hysteresis_lower_threshold: 900.5 % 60

[Cannon]

Wäre es nicht eine Option oder eben auch alternativ ohne Prozent möglich? In der Regel, beispielsweise TV, der bei > 100 Watt "an" zeigen und bei unter < 30 Watt wieder "aus" zeigen soll. Dann wäre der obere Treshold 100 und der untere 30 (ohne Prozent) .. und ggf. noch die Dauer.

Super wäre auch, wenn man die Werte aus einem anderen Item beziehen könnte. Denn sonst müsste man jedes mal SmartHomeNG neu starten, wenn man damit testet.

[Msinn]

Wäre es nicht eine Option oder eben auch alternativ ohne Prozent möglich? In der Regel, beispielsweise TV, der bei > 100 Watt "an" zeigen und bei unter < 30 Watt wieder "aus" zeigen soll. Dann wäre der obere Treshold 100 und der untere 30 (ohne Prozent) .. und ggf. noch die Dauer.

Ich verstehe Deinen Kommentar im Moment nicht.
Wie ich oben schrieb ist die Dauer Angabe (mit Prozent Zeichen) optional. Im Beispiel siehst Du ja auch den hysteresis_upper_threshold ohne Angabe einer Dauer.

[Cannon]

Wie ich oben schrieb ist die Dauer Angabe (mit Prozent Zeichen) optional

Die Dauer war in meiner Message nicht relevant. Das heißt aber die Angabe des upper- und lower-tresholds erfolgt nicht in Prozent, sondern in absoluten Werten? Das Prozentzeichen ist nur ein Teiler? :-)

[Onkelandy]

Die Dauer war in meiner Message nicht relevant. Das heißt aber die Angabe des upper- und lower-tresholds erfolgt nicht in Prozent, sondern in absoluten Werten? Das Prozentzeichen ist nur ein Teiler? :-)

So ist es wohl. Wobei tatsächlich uU ein klein wenig verwirrend

[Msinn]

Ja, das %-Zeichen dient nur als Delimiter. Der Hintergrund ist, dass andere Sonderzeichen wie <, >, *, & besondere Bedeutungen in yaml Dateien haben. Die Verwendung dieser Sonderzeichen würde dazu führen, dass bei einer fehlerhaften Konfiguration des Attributes nicht nur das eine Item nicht funktioniert, sondern dass mit hoher Wahrscheinlichkeit die gesamte ymal Datei ungültig wird.

Andere Zeichen, die als Delimiter in Frag kämen habe ich vermieden, um von mir angedachte Erweiterungen der Attribut-Definitionen nicht zu torpedieren.

[Cannon]

Ja, das %-Zeichen dient nur als Delimiter.

Macht es nicht vielleicht Sinn für die Dauer ein eigenes optionales Item-Attribut zu erstellen, anstatt einen Delimiter zu verwenden?

[Msinn]

Fünf Item Attribute statt drei Attribute machen es auch nicht gerade übersichtlicher.

Ich habe es nun so implementiert und habe eigentlich nicht vor das zunändern und die Tests von vorne zu beginnen.

[Onkelandy]

Finde ich gut argumentiert und auch sinnvoll, das in einem einzigen Attribut abzubilden.
In der Doku vielleicht kurz auf diese Besonderheit des Delimiters hinweisen?
Apropos... da ist zwei Mal ein "wird" zu viel drin

...annimmt, wird findet ein Update des Wertes False statt.

Eine Konfiguration mittels Items wäre aber nicht un-nice..
hysteresis: sh.<itempfad zum Wert>() % sh.<itempfad zur Dauer>()

[Msinn]

Das sind die angedachten Erweiterungen, von denen ich oben schrieb.

[Msinn]

Wenn man bei den angedachten Erweiterungen damit leben kann, dass in den Attributen kein Python Code implementiert wird, der mehrere Statements enthält (die durch ein Semicolon getrennt werden), könnte das %-Zeichen als Trenner durch ein ;-Zeichen ersetzt werden. Das schafft vermutlich weniger Verwirrung.