[Featurewunsch] - √ - Startphase: Instabile Werte während des ersten Auslesens der Werte (Featurewuns

[Robert]

Hi!

Generell wüsste ich mir schon zu helfen, aber mich würden eure Ideen interessieren:

Ich habe in Logiken und Evals natürlicherweise mehrere Items, von denen ein Ausgangswert abhängt. Wenn dann bei beispielsweise einem "negierten Und" erst der eine Wert mit "True" gelesen wird, wird erstmal das Value "True". Direkt danach kommt das andere Item mit "True", Value "False". Wenn das jetzt nur ins Log geht oder weiterverarbeitet wird ist das nur ungeschickt, aber bei mir hängen da auch Relais dran die dann munter klick-klack spielen.

Vom Prinzip her kein Ding: Ein "zentrales" Item, was (evtl. sogar per "timer/autotimer" nach 10 Sekunden auf True gesetzt wird. Alle fraglichen Logiken/Evals werden davon getriggert. Solange dieses Item nicht True, wird kein neuer Wert zugewiesen.

Oder (und das habe ich jetzt nicht getestet), man versucht rauszubekommen, ob die Werte aller involvierter Items neu geschrieben wurden. Das gelingt aber denke ich nur sicher, wenn enforce_updates aktiviert, da man sonst die "0" nicht mitbekommt. Wäre natürlich eigentlich schöner, da kein extra Item und so unabhängig von der Leseverzögerung wirklich dann ausgewertet wird, wenn alle Karten auf dem Tisch liegen.

Wäre evtl. für die Item ein Attribut denkbar, dass die Anzahl der Schreiboperationen mitzählt (Oder halt nur ein Bool)?

Grüße
Robert

[callidomus]

Hallo Robert,

ich verstehe den Featurewunsch nicht ganz.
Wieso verwendest Du nicht einfache cache = True für die relevanten Items?
Alternativ kannst Du, wenn die Items RRD oder SQLite verwenden, diese mit init initialisieren. Also z.B. sqlite = init

Alternativ dazu: Die Logiken werden momentan erst 4 Sekunden nach dem Start gestartet, oder wenn sich die Werte ändern auch vorher.
Das Verhalten könnte ich aber verändern. Also z.B. den Plugins erst einmal die Möglichkeit geben die Werte zu aktualisieren und erst danach die Logiken 'scharf' schalten.

Bis bald

Marcus

[Robert]

Hi Marcus,

danke für die Tipps.

In der Tat denke/dachte ich vielleicht auch in die falsche Richtung. Ich benutze für den KNX ja fast überall (außer logischerweise bei Triggern etc.) knx_init. Andere Werte, wie Onewire, Wechselrichter, Wärmepumpe etc. werden in der Folge von den jeweiligen Plugins "frisch" abgerufen/geliefert. Noch eine weitere Caching-Ebene in sh.py zu nutzen hatte ich da nicht betrachtet, da eigentlich bei einem funktionierenden Gesamtsystem alle Werte eben nach sagen wir spätestens 30sec vorliegen sollten. Unter dieser Annahme müsste man halt prüfen, ob die Werte schon "gesetzt" wurden.

Der Cache, sofern bei einem direkten Neustart von sh.py verwendet, wird sehr wahrscheinlich korrekt sein. Anders ist es, wenn da mal ein halber Tag zwischen vergangen wäre. Für meine Anwendung wäre das aber wohl egal (dann wurde beim Start halt die Außenleuchte doch mal für 20sec angehen, bis "Taghell" gemeldet wurde). Im anderen Fall (ohne Cache), würde die Leuchte/Logik halt nix tun bis alle Daten "frisch" auf dem Tisch liegen.

Werde es mal mit cache = true versuchen. Denke das passt!

Ein festes Intervall wäre eben hingegen unglücklich, da so was dann entweder unnötig verzögert, oder eben doch noch zu früh kommt.

Gäbe es eine Möglichkeit, die Zeit seit dem letzten Wechsel (age()) mit dem Alter von sh.py zu vergleichen, könnte man da auch was machen... Was kommt denn direkt beim Start bei "age()" raus? Könnte man da nicht den 01.01.1970 eintragen? Oder wenn Sekunden dann "max_int"? Und dann eine Abfrage "if (self._enforce_updates or Age == max_int): ..."?

Nebenfrage in Unkenntnis: Würde eigentlich momentan eine Logic getriggert, die von einem Item getriggert wird wenn dieses Item kein enforce_updates gesetzt hat und z.B. vom knx_cache eine "0" kommt? Das würde sonst ja auch so sicher gestellt.

Grüße
Robert

[Dragonos2000]

Hallo Robert,

vielleicht mal so als Ansatz, da ich auch schon auf ähnlichem rumgedacht habe. Da bei mir aber nichts sofort weitergearbeitet wird, hab' ich das Thema für mich erstmal zurückgestellt:

Momentan habe ich ein Init-Script (crontab = init), das beim Start von SH diverse Standardwerte setzt (Sommer/Winter, DMX Channels = 0, Automatik an, etc.).
Was ich mir als "Init 2.0" mal überlegt hatte war, alle weiteren Logiken erst am Ende des Init Scripts zu enablen, so dass nichts vorzeitig gestartet wird. Das will ich dann auch mit einer Datumsprüfung kombinieren, damit nicht irgendwelche Schedules gesetzt werden, bevor die Zeit synchronisiert wurde (hab keine RTC auf dem Pi und die Prüfung momentan im Start-Script von SH eingebaut).

In der 0.9er SH Version gibt's ja entsprechende Scheduler Funktionen, die das hergeben müssten.

Gruss
Jochen.

[Robert]

Nebenfrage in Unkenntnis: Würde eigentlich momentan eine Logic getriggert, die von einem Item getriggert wird wenn dieses Item kein enforce_updates gesetzt hat und z.B. vom knx_cache eine "0" kommt? Das würde sonst ja auch so sicher gestellt.

Die Antwort lautet: NEIN

Imho ist das ein Bug. Evtl. kann man das ja wirklich über das Erstellungsdatum regeln - dann hätte man eben auch was um festzustellen ob das Item schon mal initialisiert wurde. Evtl. könnte man im Fall von "cache = init" oder den Datenbankabfragen auch die korrekten Zeitstempel (welche dann naturgemäß vor dem Start der sh.py-Instanz liegen müssen) setzen?

Witzloser Minimal-Test der das bestätigt was auch der Code von item.py nahelegt:

item.conf

[zero_item]
  type = bool
  #enforce_updates = true

logic.conf

[test]
    name = 'test_zero_item'
    filename = test_zero_item.py
    watch_item = zero_item
[test2]
    name = 'test_zero_item2'
    filename = test_zero_item2.py
    cycle = 10

test_zero_item.conf

logger.debug('###################################################')
logger.debug('{}: trigger={}'.format(logic.name, trigger))
logger.debug('###################################################') 

test_zero_item2.conf

sh.zero_item(0, logic.name) 

Ohne enforce_updates wird die erste Logik gar nicht aufgerufen.

[callidomus]

Hi Robert,

Nebenfrage in Unkenntnis: Würde eigentlich momentan eine Logic getriggert, die von einem Item getriggert wird wenn dieses Item kein enforce_updates gesetzt hat und z.B. vom knx_cache eine "0" kommt? Das würde sonst ja auch so sicher gestellt.

wenn der Wert des Items != 0 ist, wird die Logik getriggert.
Wenn Du dem Bool-Item keinen Startwert gibts über: value = 1, cache = yes, oder sqlite = init, dann wird False (0) angenommen.

Ich sehe es nicht als Bug an.

Bis bald

Marcus

[Robert]

Hi Marcus,

bei einem "num" ist es ja einfach, in dem ich den Wert anfangs auf einen im Normalbetrieb nicht vorkommenden Wert setze ("value = -1"). So wird dann beim ersten "Update" eine Logik sicher ausgeführt.

Bei einem "bool" geht das aber nicht. Egal ob ich mit "value = 1/0" initialisiere oder den Cache benutze, ich kann ohne weitere Maßnahmen das Triggern der Logik nicht sicherstellen.

Warum nicht einfach in der "enforce_update"-Abfrage noch zusätzlich " || self.changed_by == "init" als weitere Ausnahmebedingung aufnehmen?

Grüße
Robert