NEU! UPGRADE IP 10 verfügbar!
Optimierte Darstellung von VISU Editor und VISU Client - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/8HzePCm3

Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074

Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117

NEU! Ausführliches Video Tutorial zur IP 10
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs

[FR] Inhibit Start Behaviour: Current Value

Hier bitte Eure Diskussionen und Feature Requests zu neuen Logikmodulen und Funktionen des Logik-Editors
Antworten

Ersteller
bluegaspode
Reactions:
Beiträge: 72
Registriert: Sa Nov 09, 2019 10:09 pm
Hat sich bedankt: 7 Mal
Danksagung erhalten: 31 Mal

Inhibit Start Behaviour: Current Value

#1

Beitrag von bluegaspode »

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

Bild

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
Zuletzt geändert von Robert_Mini am Do Feb 20, 2020 8:55 pm, insgesamt 4-mal geändert.
"TWS 350Q ID:417, VPN geschlossen, Reboot nicht erlaubt"

Matze76
Reactions:
Beiträge: 314
Registriert: Mo Sep 24, 2018 9:59 am
Hat sich bedankt: 283 Mal
Danksagung erhalten: 195 Mal

#2

Beitrag von Matze76 »

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).
Gruß
Matthias

TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache

Ersteller
bluegaspode
Reactions:
Beiträge: 72
Registriert: Sa Nov 09, 2019 10:09 pm
Hat sich bedankt: 7 Mal
Danksagung erhalten: 31 Mal

#3

Beitrag von bluegaspode »

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?
"TWS 350Q ID:417, VPN geschlossen, Reboot nicht erlaubt"

Matze76
Reactions:
Beiträge: 314
Registriert: Mo Sep 24, 2018 9:59 am
Hat sich bedankt: 283 Mal
Danksagung erhalten: 195 Mal

#4

Beitrag von Matze76 »

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

TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache

gbglace
Reactions:
Beiträge: 3611
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1268 Mal
Danksagung erhalten: 1674 Mal

#5

Beitrag von gbglace »

Wobei sich Start-Defaults setzen lassen.

Readrequests vom TWS aus senden ist ja schon öfters als Wunsch gefallen.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

Robert_Mini
Reactions:
Beiträge: 3744
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1171 Mal
Danksagung erhalten: 2076 Mal

#6

Beitrag von Robert_Mini »

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
Zuletzt geändert von Robert_Mini am Di Nov 19, 2019 12:56 pm, insgesamt 1-mal geändert.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Ersteller
bluegaspode
Reactions:
Beiträge: 72
Registriert: Sa Nov 09, 2019 10:09 pm
Hat sich bedankt: 7 Mal
Danksagung erhalten: 31 Mal

#7

Beitrag von bluegaspode »

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.
"TWS 350Q ID:417, VPN geschlossen, Reboot nicht erlaubt"

Robert_Mini
Reactions:
Beiträge: 3744
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1171 Mal
Danksagung erhalten: 2076 Mal

#8

Beitrag von Robert_Mini »

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
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Dragonos2000
Reactions:
Beiträge: 2184
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 482 Mal
Danksagung erhalten: 889 Mal

#9

Beitrag von Dragonos2000 »

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?
Zuletzt geändert von Dragonos2000 am Mo Jan 13, 2020 5:15 pm, insgesamt 2-mal geändert.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

Robert_Mini
Reactions:
Beiträge: 3744
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1171 Mal
Danksagung erhalten: 2076 Mal

#10

Beitrag von Robert_Mini »

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
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
Antworten

Zurück zu „Feature Requests & Diskussionen Timberwolf Logik (Module & Editor)“