ElabNET Technik Forum

EDIT (Robert_Mini):
Das bleibt als finaler FR nach der Diskussion unten übrig:

bluegaspode hat geschrieben: ↑Di Nov 19, 2019 2:20 pm Hi @Robert_Mini
ich kann damit leben, wenn dieser Feature Request reduziert ist auf:
"Beim Neustart eines Logik-Bausteins nimm die bekannten/vorhandenen Werte des DOS als Input-Parameter" (ohne expliziten Read-Request)

-------------

Bei den Inhibit (und anderen Input-) Parametern von Logiken gibt es derzeit nur die Auswahl zwischen
- festem Wert
. Wert nach nächster Änderung



Bei Parametern die sich selten ändern ("Weihnachtszeit", "Urlaubsmodus", ...) ist das problematisch.
Ein fester Wert passt nicht, denn in 50% der Fälle ist es der falsche. 3 Monate zu warten, bis der Wert mal wieder auf den Bus geschickt wird, ist auch nicht sinnvoll.
Nach Neustart des Timberwolf Servers alle Status-Toggle manuell durchtoggeln ist auch keine Option.

Der Timberwolf hat für die meisten Werte vermutlich den aktuellen Wert im Cache.
Oder kann ihn sich vom Bus besorgen.

Ich wünsche mir:
- das die Option "Wert nach nächster Änderung" mindestens den im Timberwolf gecachten Wert verwendet. Sonst ist das stoppen/neustarten von Logiken problematisch.
- ergänzend/optional: dass bei Neustart des Timberwolf, bestimmte Werte aktiv vom Bus abgefragt werden. Bei Edomi kann man das z.B. je KNX-Adresse konfigurieren.

Als Referenz hier sonst der Leidensweg eines Users, der das Verhalten, dass nicht mit dem aktuellen Wert gearbeitet ist, von keinem anderen Server gewöhnt ist. Bei Neustarten und Umkonfigurieren von Logiken kann das sehr viel Zeit kosten:
viewtopic.php?f=24&t=1654

Nach Neustart des Timberwolf Servers alle Status-Toggle manuell durchtoggeln ist auch keine Option.

Muss man auch nicht: Wenn eine Logik nach einem Neustart des Timberwolf mit den bekannten Werten weiterarbeiten soll, einfach die Persistenz aktivieren (= den Button mit dem Unendlichkeits-Zeichen drücken).

OK - das hilft bei Neustart.

Habe jetzt mal die Persistenz aktiviert.
Das eigentlich Problem löst es aber nicht: wenn ich eine Logik neu speichere (z.B. Änderung einer Trigger-Zeit) startet die Logik mit uninitialisierten Default-Werten, nicht mit den Persistenz-Werten?

Ja, das stimmt. Die Persistenz greift aktuell nur für den Neustart der Logikengine bzw. des TWS.

Wobei sich Start-Defaults setzen lassen.

Readrequests vom TWS aus senden ist ja schon öfters als Wunsch gefallen.

Hab das Thema hierher in FR Unterforum verschoben, damit man auch voten kann.

Wobei ich das NICHT als read-request alleine sehe.
Das Startverhalten nach dem Speichern stört mich persönlich auch. Kleine Änderung und das 10x bedeutet 10x zb 5 Eingänge im Dokmode anpassen...

Dazu würde es reichen, beim Speichern den letzten Wert am Objekt (wie unter Objecteditor zu sehen!!!) zu laden.
Einfach wie von @bluegaspode beschrieben eine 3. Option "current value" mit max. Alter in Tagen als Parameter.

Das braucht kein knxread vom Bus und löst gemeinsam mit der vorhandenen Persistenz 99% der Probleme.

Der FR für das aktive Lesen ist IMHO ein verwandtes, aber getrenntes Thema und auch Top10 FR: viewtopic.php?f=9&t=1139
Das sollte ein eigener Baustein sein, der mittels Trigger ein read auslöst und asynchron zum LE auf eine Antwort wartet und dann sendet. Das kann in Ausnahmefällen ein zyklisches Lesen eines Reglerstatus o.ä. sein oder eben nach dem Neustart für einzelne KNX Objekte, die nur bei Änderung senden.

Wär für mich dann ähnlich Astrobaustein, der gelegentlich sendet und damit die eigentlichen Logiken triggert. Damit muss auch keine Logik pausieren/warten und der LE bleibt rein eventgesteuert!

Lg
Robert

Hi @Robert_Mini

ich kann damit leben, wenn dieser Feature Request reduziert ist auf:
"Beim Neustart eines Logik-Bausteins nimm die bekannten/vorhandenen Werte des DOS als Input-Parameter" (ohne expliziten Read-Request)

Logiken starte ich in der Entwicklung sehr oft neu.
Den Timberwolf neustarten, so dass er alle seine Werte vergisst, passiert dagegen so gut wie nie.

Und da das Abfragen von Werten vom Bus separater FR ist, ist dieser Aspekt ja ohnehin gecovert. Damit kann man dann regeln, dass in den Wichtigen Objekten auch die aktuellen Werte des Systems stehen, selbst nach einem TWS Neustart.

bluegaspode hat geschrieben: ↑So Nov 17, 2019 8:34 pm Ich wünsche mir:
- das die Option "Wert nach nächster Änderung" mindestens den im Timberwolf gecachten Wert verwendet. Sonst ist das stoppen/neustarten von Logiken problematisch.
- ergänzend/optional: dass bei Neustart des Timberwolf, bestimmte Werte aktiv vom Bus abgefragt werden. Bei Edomi kann man das z.B. je KNX-Adresse konfigurieren.

Ich hab mich gerade gewundert, dass dieser FR noch keine Votings hat!

Das Starten der Logik mit dem letzten Wert, der am Bus zu sehen war (=wie im Object Editor angezeigt), fände ich auch sehr hilfreich! So schnell man mit dem Editieren und Aktivieren in Echtzeit ist, mit dem mehrfachen Neusetzen der Eingänge geht dann ein Teil der gewonnenen Zeit sinnlos verloren.

@bluegaspode
Zum 2. Punkt: Das ist bereits heute möglich und funktioniert perfekt! Leider ist das nur sehr wenigen bekannt!
Einfach in der ETS am TWS Objekt das I-Flag setzen!
Dann wird nach dem Reboot automatisch ein Read-Request abgesetzt => Macht nur Sinn, wenn das L-Flag nicht am TWS Objekt hängt, sondern an einem Aktorkanal o.ä.

lg
Robert

Zur optionalen Anforderung:
Der Thread/FR ging an mit komplett vorbei. Das gehört so ein bisschen zum "KNX-Stack Persistenz" Thread bzw. könnte eine Lösungsalternative sein. Problem ist ja, dass der Stack bei einem Neustart alle KOs mit "0" initalisiert und entsprechend Reads so beantwortet (sofern der TWS "führend" sein soll). Die Persistenz der Logik hilft hier nicht weiter, da die eine Ebene drüber angesiedelt ist. Insofern wird von der Architektur her an dieser Stelle des TLE vermutlich auch nicht viel gehen, wie wir das im anderen Thread auch schon diskutiert hatten.
Ist KNX spezifisch und eher da unterzubringen.

Anregung an die Entwicklung: Einstellung im Objekt-Editor, der ja bereits Technologie spezifisch implementiert ist?

Die Themen sind zwar verwandt, aber hier geht es um primär noch um das Startverhalten beim Speichern der Logik.
Das ist zwar verwandt mit dem Verhalten nach Stromausfall/Reboot-Thema, aber dann doch ein zusätzliches Thema.

lg
Robert