UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Frage] Trigger und Sendeverhalten nach Restart

Informationen und Diskussionen über Logik-Engine und Logik-Editor
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

Trigger und Sendeverhalten nach Restart

#1

Beitrag von Robert_Mini »

Hallo @S. Kolbinger!

Ich möchte deine Erklärung aus diesem Thema (viewtopic.php?f=8&t=2276&p=25354&hilit= ... uhr#p25354) kurz diskutieren.
S. Kolbinger hat geschrieben: So Jul 19, 2020 4:18 pm Die Zeitschaltuhr an sich hat funktioniert, das Problem war die Sendeoption "C" (on change).
Nach dem Reboot hat der "Ausschalt-Timer" getriggert. Der Ausgang war aber nach dem Reboot auf "false" (default nach Neustart).
Da sich der Zustand nicht geändert hat, wurde auch nichts nach aussen gesendet.

Lösungsvarianten:
  1. Persistenz einschalten (Ausgangszustand wird gemerkt)
  2. Sendeoption am Ausgang auf "A" setzen (Ausgangswert wird jedesmal gesendet)
Ich verstehe dieses Verhalten zwar, sehe da aber eine Parallele zum ursprünglichen Verhalten des KNX-Stacks.

Ich hatte heute nämlich ein ähnliches Problem: Restart des logic-Services (warum weiß ich nicht??), und die Beschattung hat gestreikt => Ausgang war durch den Restart auf "false" und hat daher das spätere Umschalten auf "false" nicht gesendet => Persistenz muss aktiviert werden.

Bedeutet aber, dass bei allen rein Event-basierten Logiken, die ebenfalls nur auf "on change" senden, Persistenz erforderlich ist.

Ich weiß nicht, ob das realistisch ist, aber korrekterweise sollten die Ein-/Ausgänge der "nicht persistenten" Logiken nicht mit false (bzw. 0 bei float) sondern n/a initialisiert werden, so dass auch bei Empfang von "false" bzw. Ergebnis "false" getriggert bzw. gesendet wird. Gleiches gilt für float 0.0

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#2

Beitrag von StefanW »

Robert_Mini hat geschrieben: Mi Jul 22, 2020 11:22 pmIch weiß nicht, ob das realistisch ist, aber korrekterweise sollten die Ein-/Ausgänge der "nicht persistenten" Logiken nicht mit false (bzw. 0 bei float) sondern n/a initialisiert werden,
Eine Initialisierung mit "nichts" ist keine Initialisierung. Logiken brauchen einen Startwert. Immer.

Die Entscheidung, welches der Startwert haben soll, haben wir in die Hand des Nutzers gelegt.

1. Entweder der Nutzer gibt einen fixen Startwert vor oder

2. Der Nutzer etzt den betreffenden Eingang auf "inhibit before initialized", dann wird die Logik erst berechnet (das erste mal getriggert) bis ALLE so markierten Eingänge einen Wert von außerhalb erhalten haben.

Auf diese Weise gibt es IMMER klare Verhältnisse. Sei es fest vorgegeben oder die Logik muss darauf warten was passiert. Mit unklaren Verhältnissen "initilaisierung mit nichts" ist gar nichts gewonnen bzw. entspricht dann ohnehin einem impliziten "inhibit before initialized". Ein solches Standardverhalten würde nur dafür sorgen, dass der Nutzer den entsprechenden Haken nicht mehr setzen muss.

lg

Stefan
Zuletzt geändert von StefanW am Do Jul 23, 2020 9:08 am, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#3

Beitrag von Robert_Mini »

Hallo Stefan!

Danke für deine Erläuterung.
Man sieht, es gibt immer noch was zum dazulernen und ich gebe dir hinsichtlich Eingänge absolut recht, da hab ich nicht bis zum Ende gedacht.
StefanW hat geschrieben: Do Jul 23, 2020 9:08 am 2. Der Nutzer etzt den betreffenden Eingang auf "inhibit before initialized", dann wird die Logik erst berechnet (das erste mal getriggert) bis ALLE so markierten Eingänge einen Wert von außerhalb erhalten haben.
Das muss ich doch glatt mal detailliert testen. Meiner Erinnerung nach griff dies nur bis zum trigger des ersten so gesetzten Einganges, das "ALLE einen Werten erhalten" wäre perfekt.

"Vorsichtig" widersprechen muss ich bezüglich Ausgänge. Dort wäre ein n/a bis zum ersten durchrechnen der Logik sehr wohl richtiger, als ein "false", insbesondere im Zusammenspiel mit "sende on change". Ich muss des öfteren Logiken an den Eingängen manuell umsetzen, damit die Logik das false sendet. Heißt im Detail: Ausgang steht nach dem Speichern auf false, Logik wird getriggert und errechnet false, wird aber nicht gesendet, weil gegenüber dem init "false" keine Änderung passiert ist.

Das ist sicher Jammern auf hohem Niveau, aber man schreibt sich so gelegentlich Müll in die Zeitserien usw. => kann man aber durch Abkoppeln etc. vermeiden. Bei größeren Logiken muss man dann auch mehrere Eingänge umsetzen (und nicht vergessen sie zurückzusetzen), damit man eine true-false provoziert. => Beispiel: 8fach UND mit "send on change" => man muss alle 8 Eingänge umsetzen, damit das erste FALSE gesendet wird, und dann wieder zurück.

Persistenz löst das Problem zumindest nach einem Reboot, beim Erstellen und insbesondere Ändern von Logiken aber nicht.

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#4

Beitrag von StefanW »

Robert_Mini hat geschrieben: Do Jul 23, 2020 12:51 pmDas muss ich doch glatt mal detailliert testen. Meiner Erinnerung nach griff dies nur bis zum trigger des ersten so gesetzten Einganges, das "ALLE einen Werten erhalten" wäre perfekt.
Ich habe es so gewünscht, dass für jeden Eingang, für welches DIES als Eigenschaft gesetzt ist, gewartet wird, bevor die Logik das erste Mal getriggered wird.

Beispiel:

- Logikzelle mit fünf Eingängen

- Bei drei dieser Eingänge ist das "Inhibit before Trigger", also das Warten darauf dass der Wert das erstemal korrekt gesetzt wird, gesetzt

- Logik wird gestartet. Erst wenn beim letzten dieser drei Eingänge ein Wert angekommen ist (Reihenfolge egal) wird die Logik durchgerechnet (sofern nicht parallel noch Sperrobjekte aktiv sind) und je nach eingestelltem Triggerverhalten. Weil wenn beim letzten dieser drei so gesetzten Eingänge zudem festgelegt wäre, dass dieser nicht zum Triggern führen soll, dann wird zwar die initiale Triggersperre für diesen Eingang aufgehoben, aber damit noch nicht die Berechnung getriggert.

===> Daher auf Triggerfähigkeit eines Einganges und den Triggersperren achten.

Den Rest lese ich mir am Abend nochmal durch.


lg

Stefan
Zuletzt geändert von StefanW am Do Jul 23, 2020 4:01 pm, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#5

Beitrag von Robert_Mini »

Hallo Stefan!

Hab das grad getestet. In der Tat funktioniert die Startoption inhibit so, dass ALLE Eingänge einen Wert empfangen haben, bevor der Ausgang beschrieben wird.
ABER: Auch hier funkt das "on change" aufgrund des default "false" dazwischen. Testlogik Screenshot unten, AND mit 3 Eingängen auf "i" und "c".

Mit diesem Setup (Ausgang invertiert) schaltet der Ausgang erst auf true, wenn jeder Eingang auch mal true war. Ein false auf alle 3 Eingänge nach dem Speichern triggert den Ausgang nicht auf true! D.h. die Option "on change" ist da stärker als das inhibit, nicht wie du beschrieben hast, dass i das on change beim ersten Aufruf ignoriert.

Wie du es beschrieben hast wäre es perfekt, so wie ich es jetzt getestet habe, ist das aber ein eher ein kleiner Bug.

Das Thema Ausgänge einfach bei Gelegenheit noch in Ruhe lesen. Das ganze eilt nicht.

Anmerkung 2020-07-23 213351.png
lg
Robert
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von Robert_Mini am Fr Jul 24, 2020 4:17 pm, insgesamt 1-mal geändert.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
Antworten

Zurück zu „Logikengine & Logik-Editor“