Erweiterung für Persistenz: Senden nach Reboot

[SchlaubySchlu]

Hallo Robert,

prinzipiell ist mir das schon klar, nur kann ich mit dem Satz "Ein- und Ausgang muss mit dem selben KNX-Objekt verknüpft sein bzw. kann man auch LE-Objekt-Ausgang mit dem LE-Objekt Eingang verbinden. " nichts anfangen.
Welches KNX-Objekt soll das sein? Irgend eins oder ein bestimmtest?
"Dein"/Das KNX-Objekt, ich nenne es einfach einmal TWS-Restart?

Danke!

Gruß
Ralf

[blaubaerli]

Hallo Ralf,

anbei mal die relevante Grafik aus dem ersten Post mit zusätzlichen Markierungen:

29-12-_2020_17-14-29.jpg

Die Markierungen links zeigen auf die Eingänge und die Rechts auf die Ausgänge und die mit der jeweils identischen Nummer in der Markierung referenzieren auch genau das identischen KNX-Objekt des Wolfes. Also sowohl auf Eingang 1 liegt das K-174, als auch auf dem Ausgang 1. Auf Eingang 2 dann das K-134 und auf Ausgang 2 ebenfalls. Usw...

Hat das die Frage klären können?

Beste Grüße
Jens

[SchlaubySchlu]

Halo Jens,

der Baustein 2 ist klar.
Mir geht es um den Baustein 1, der ja sozusagen den Trigger erstellt für den Baustein 2, wenn ich das richtig verstanden habe.
Und beim Baustein 2 ist mir eben nicht klar, welches KNX-Objekt ich da verknüpfen soll, weil meiner Meinung nach ja kein Objekt benötigt wird wenn der Trigger durch einen neustart des TWS ausgelöst werden sollte. Deshalb die Frage ob es sich bei dem KNX-Objekt um ein Statusobjekt handelt an dem man sehen kann das der TWS einen neustart gemacht hat.

Gruß
Ralf

[blaubaerli]

Hi Ralf,

grundsätzlich muss zur Funktion des Gesamtkonstrukts nur der Ausgang der ersten Logik mit dem Trigger der zweiten Logik verbunden werden. Robert hat zusätzlich am Ausgang der ersten Logik zu Protokoll- und Diagnosezwecken noch das Objekt K-1902 verbunden. Das hat hier aber keinen zwingend funktionalen Hintergrund.

Du kannst den Ausgang einer beliebigen Logik unmittelbar einem Eingang einer anderen Logik zuweisen und musst das nicht über ein separates KNX-Objekt führen.

Beste Grüße
Jens

[Robert_Mini]

Hallo zusammen!

Da muss ich widersprechen!
Der Ausgang muss tatsächlich mit dem Eingang verbunden werden. Wobei man das natürlich intern lösen könnte:

Code: Alles auswählen

Latch","$State_Out","$State","$KonstTrue",0],

vor dem Clocksignal einfügen.

Hinweis: Auch wenn es naheliegend wäre, darf man das $State, das im Clocksignal verwendet wird, nicht im Multiplexer verwenden.

Lg
Robert

[blaubaerli]

Hallo Robert,

das verstehe ich hier nicht:

Da muss ich widersprechen!
Der Ausgang muss tatsächlich mit dem Eingang verbunden werden.

Ich habe doch nirgendwo behauptet, dass das nicht gemacht werden muss.

Das hatte ich doch hier explizit erwähnt:

grundsätzlich muss zur Funktion des Gesamtkonstrukts nur der Ausgang der ersten Logik mit dem Trigger der zweiten Logik verbunden werden.

Oder reden wir aneinander vorbei?

Beste Grüße
Jens

[Robert_Mini]

Ja. So wie ich meine Logik gerade verstehe, muss der Ausgang Logik 1 mit Eingang Logik 1 verbunden sein, da sonst $State nie True wird und das Clocksignal dann weiterläuft....
Das ist im Beispiel in #1 das Objekt K-1902

Lg
Robert

[blaubaerli]

Argh.....

Sorry ich hatte nur die Verbindungen von Logik 1 zu 2 im Blick.

In meiner Kopie gibts das Ding auch....

Ich bitte die Verwirrung zu entschuldigen

Beste Grüße
Jens

[blaubaerli]

Hi @Robert_Mini,

nachdem ich mich hier letztens schon blamiert habe.... habe ich doch noch mal ne Frage.....

Wie verhält sich bei dir deine "Persistenzlogik", wenn du einen weiteren Wert zur Persistierung zufügen möchtest.

Ich habe bei mir gestern mal genau den Fall gehabt und hatte dabei "komische Effekte" die mir ein mulmiges Gefühl bereitet haben.

Wegen des Triggers habe ich ja auf der Eingangsseite mal genau ein Objekt mehr als auf der Ausgangsseite. Der Trigger hing unten als letztes dran.

Von wegen der Optik kam ich dann auf die glorreiche Idee das neue Eingangsobjekt nicht unter dem bisherigen Trigger, sondern darüber einzufügen und das neue Ausgangsobjekt einfach unten drunter.

Der Name des Triggereingangs veränderte sich nicht.

Dann Logik abgespeichert. Und meine Verküpfungen waren "gewürfelt" zumindest die für den Trigger. Der Doktormodus war dann auch wieder aus. Nachdem ich ihn wieder aktiviert habe und meinen Trigger nochmal manuell ausgelöst hatte, hatte ich mir gewünscht, dass die eigentlich ja persistierten Werte im Dok-Modus wieder angezeigt werden. Das war aber schlicht nicht der Fall. Alles auf "0".

Ich habe das nun noch nicht wieder im Detail analysiert. Wie gehst du damit um und wie sind da deine Erfahrungen?

Beste Grüße
Jens

[Robert_Mini]

Hy Jens!

Nix blamiert!!!

Das mit dem durcheinanderwürfeln sollte eigentlich nicht mehr passieren (das Thema Var-Name nicht Teil eines anderen). Teste ich nochmal an dieser Logik.

Dass die Werte trotz Persistenz beim Speichern verloren gehen ist "normal" und ich kann damit gut leben.
Ich habe das Thema Persistenz aber modularisiert, d.h. mehrere der Module Typ2 für zB Beschattung, Pool, etc. mit 4-8 Werten. Damit sind Änderungen relativ einfach gemacht, die Werte für die aktuell geänderte Logik schnell per Dokmode nachgetragen.

Lg
Robert