item.yaml: cycle ohne Wertzuweisung?

[Morg]

Moin,

gem. Doku zu Items/cycle sollte

cycle
Das Attribut definiert ein regelmäßiges Aufrufen des Items (und damit der verknüpften Logik oder Eval-Funktion).

item:
    cycle: 10
    enforce_updates: 'true'

ruft das Item alle 10 Sekunden auf und sorgt dadurch für das triggern von verknüpften Logiken und/oder Eval-Funktionen. Dazu muss enforce_updates auf truestehen, damit das Triggern erfolgt, auch wenn sich der Wert des Items nicht ändert.

man cycle setzen können, so dass das Item getriggert wird, aber nicht verändert.

Ich habe Folgendes in der items.yaml:

auf:
    type: bool
    gpio_in: 5
    nw_udp_send: 192.168.2.231:42011
    enforce_updates: true
    cycle: 60

Sobald der cycle einmal gelaufen ist, ist überall 'updated_by: Scheduler' gesetzt, soweit korrekt. Bei den Items (mehrere gleiche auf verschiedenen gpio-Pins) sind aber die, die auf 'True' standen, jetzt 'False' mit 'changed_by: Scheduler'. Cycle setzt also einen Wert (False), unabhängig vom vorherigen Item-Wert.

Habe ich die Doku falsch verstanden (nur triggern, nicht ändern), oder ist das ein Bug? Will jetzt nicht einfach den Code ändern, falls das Verhalten so geplant ist...

[Msinn]

Muss ich rein schauen. Aber selbst wenn es ein Bug wäre (der dann seit Anbeginn der Zeit besteht) ist eine Codeänderung keine gute Idee. Ich habe keine Idee wie viele laufende Indstallationen evtl. auf genau dem existierenden Verhalten aufsetzen und eine Code Änderung wäre deshalb ein Breaking-Change.

[Morg]

Kein Problem. Wenn das so nicht geht oder sich nicht - "generalkompatibel" - lösen lässt, dann baue ich in das network-Plugin noch einen nw_cycle-Parameter oder so ein und mach nen PR auf develop Neue Parameter sind ja bei vernünftiger Anwendung kein breaking change

[bmx]

Ich fände es gut, wenn cycle die gleichen Dauer und Wertparameter nutzen könnte wie Autotimer. Ich habe geradeso einen Anwendungsfall wo ich das gut gebrauchen könnte...

[Msinn]

Das würde ein etwas größerer Umbau, da cycle und autotimer recht unterschiedlich behandelt werden.

Für cycle wird zum Anfang ein Scheduler aufgesetzt, der periodisch ausgeführt wird. (Quasi "Fire & Forget")
Für autotimer wird ein Scheduler aufgesetzt, der einmal ausgeführt wird. Bei der Ausführung wird ein neuer Scheduler aufgesetzt, der dann natürlich auch mit neuen (Item-)Werten anders konfiguriert sein kann.

[Morg]

Unabhängig davon, ob cycle jetzt die Möglichkeit bekommt, den Wert nicht zu verändern (ggf. durch cycle: 60 = None?), müsste in jedem Fall die Doku angepasst werden, die stellt diese Möglichkeit nämlich dar.

[Msinn]

Wo hast Du das in der Doku gefunden? Auf der Seite zum Standard Attribut cycle https://www.smarthomeng.de/user/konf...ute/cycle.html habe ich es nicht gefunden.

[Morg]

Gleich im Text zum ersten Codebeispiel:

ruft das Item alle 10 Sekunden auf und sorgt dadurch für das triggern von verknüpften Logiken und/oder Eval-Funktionen. Dazu muss enforce_updates auf truestehen, damit das Triggern erfolgt, auch wenn sich der Wert des Items nicht ändert.

Hier ist ausdrücklich von "triggern", und nicht von "verändern" die Rede; zusammen mit dem Hinweis auf "enforce_updates" kann man das eigentlich nicht anders verstehen.

Im nächsten Absatz steht dann die Variante, wie cycle auch Werte zuweisen kann. Das passiert im ersten Teil doch nicht.

Wie sonst sollte man das verstehen? Wie ist es gemeint?

(Und nur, damit wir nicht aneinander vorbei reden: die dargestellte Möglichkeit ist nicht, "= None" zu setzen, das war nur ein Beispiel, sondern zu triggern, ohne den Wert zu ändern. Und das funktioniert nicht. Es wird immer False gesetzt)

[Msinn]

enforce_updates auf truestehen, damit das Triggern erfolgt, auch wenn sich der Wert des Items nicht ändert.

Das beschreibt nur die Funktionalität von enforce_updates. In dem Beispiel auf welches sich der Satz bezieht:

item:
    type: num
    cycle: 10 = 0
#    enforce_updates: true

wird zyklisch der Wert 0 gesetzt. Es wird darauf hingewiesen, dass man enforce_updates benötigt, damit andere Items, die dieses Item als Trigger nutzen, auch getriggert werden, wenn sich innerhalb der 10 Sekunden der Wert des Items nicht verändert hat und erneut 0 zugewiesen wird.

Mit einer Zuweisung von None hat das nichts zu tun.

Im Beispiel davor soll das Item nur als Trigger dienen und der Wert des Items nicht verwendet werden. Das war die ursprüngliche Implementierung in smarthome.py. Dort wurde bei cycle immer 0/False zugewiesen. Das cycle Attribut wurde als reine Trigger Möglichkeit (abgeleitet vom cycle Parameter für Logiken in etc/logic.conf).

Die Möglichkeit einen Wert zu setzen kam erst in SmartHomeNG hinzu.

Btw.: None kann man Items nicht zuweisen. Das handling von None in eval Ausdrücken ist ein Sonderhandling (es verhindert eine Zuweisung), welches nur in der eval Auswertung gibt und bei keiner anderen Zuweisung. Dieses Handling an anderen Stellen zu übernehmen wäre sicherlich sinnvoll.

[Morg]

Die Zuweisung von None war auch nur ein Beispiel/Vorschlag von mir. Habe ich ja schon gesagt, dass davon nicht da stand.

Das enforce_updates steht im Original beim ersten Mal an der Stelle, wo getriggert werden soll, ohne dass der Wert sich ändert. Darum geht es mir doch (siehe Titel...), und das funktioniert eben nicht.

Die Zuweisung von None war ein Vorschlag, wie man das "triggern ohne Änderung" implementieren könnte, ohne den Status quo erwartbar zu verändern. Wer dann nur "cycle: 60" angibt, hat das derzeitige Verhalten (entspr. cycle: 60 = '' oder cycle: 60 = False).

Die "Zuweisung" von None im Sinne von "nichts ändern" ist ja bei eval analog umgesetzt. Darum wäre das aus meiner Sicht eine passende Analoge

[Msinn]

Schau mal in die Ergänzung zu meinem letzen Post. Das None Handling wäre dann ein Thema was größere Änderungen an diversen Attributen zur Folge hätte. Das will gut überlegt sein. Vor einem Refactoring von lib.item würde ich mich nicht trauen das Thema anzugehen. lib.item ist bereits extrem umfangreich (knapp 2.800 Zeilen Code).

[Morg]

Wenn ich über die Möglichkeit nachdenke, ein Item regelmäßig zu triggern, ohne den Wert zu verändern, wäre das mit

eval_trigger: <anderes Item mit cycle>
eval: value if sh...property.last_update_by != 'eval' else None

möglich? Dann dürfte bei Aktualisierung durch eval_trigger keine Änderung erfolgen...?

[ivande]

seit den letzten Updates 1.8 bzw 1.8.1 triggert cycle ohne Wertzuweisungen nicht mehr.

item:
    cycle: 10   #triggert nicht
    enforce_updates: 'true'

schreibe ich hinter die Zeit die Einheit "s" dazu so triggert das Item auch ohne Wertzuweisung.

    cycle: 10[MARKIEREN]s[/MARKIEREN]    #triggert

Danke für dem Hinweis:

LÖSUNG:
Hat sich erledigt. es muss hinter dem Wert für den cycle noch die Einheit geschrieben werden. Mit "cycle: 1s" funtioniert es.

bei cycle mit Wertzuweisung brauche ich hingegen die Einheit nicht dazuschreiben:

    cycle: 10 = 1    #triggert

Update: Versuchsaufbau:

test:
    test_cycle:
        cycle: 300
        enforce_updates: 'true'
    test_cycles:
        cycle: 300s
        enforce_updates: 'true'

cycle.jpg


cycle1.jpg

[Msinn]

Schaue ich mir an