OBS - ein neuer Player in der Serverlandschaft?

[jensgulow]

Prinzipiell zu den Funktionsblöcken:

Sicherlich wäre es gut den Ausgängen einen Initialwert zuweisen zu können. Damit stellt man sicher, dass bei Änderungen und neu speichern nicht ausversehen ein ungewünschter Zustand über lange Zeit bestehen bleibt.

Beispiel wäre für mich wenn ich in einer visu per Knopfdruck mitteile, ob jemand im Haus ist (Präsenz=true). Davon ist die Auslösung anderer Logiken abhängig, weil die nur Sinn ergeben wenn jemand zu Hause ist.
Schlecht wäre, wenn (warum auch immer) der Wert mit false initialisiert würde oder undefiniert bleibt bis eine Eingabe erfolgt. Hier wäre ein vorgegebener Initialisierungswert doch nützlich.

[abeggled]

Vom Grundprinzip sollte dies nicht nötigt sein, denn das Objektsystem kennt den aktuellen Wert immer. Beim speichern eines Logikblattes mit einem Objekt-Lesen Funktionsblocks, sollte der Wert immer aus dem Objektsystem gelesen werden, daher sollte dies gelöst sein.
Falls dies nicht der Fall sein sollte, wäre es ein Bug der zu beheben wäre.

[mfd]

Vom Grundprinzip sollte dies nicht nötigt sein, denn das Objektsystem kennt den aktuellen Wert immer.

Gibt es nicht immer Ausnahmen?
Oder anders gefragt, was ist, wenn es (noch) keinen aktuellen Wert gibt?

[abeggled]

Oder anders gefragt, was ist, wenn es (noch) keinen aktuellen Wert gibt?

Ja, das ist genau einmal, beim erstellen des Objekts. Ich gehe davon aus, dass ein Objekt immer in irgend einer Form befüllt wird, allenfalls auch manuell und erst dann Logiken mit diesem Objekt erstellt werden. Zudem hast du bei einem Initialwert jeweils das Thema, was ist jetzt das kleinere Übel true oder false? Den stimmen tun möglicherweise beide nicht.

[mumpf]

Zudem hast du bei einem Initialwert jeweils das Thema, was ist jetzt das kleinere Übel true oder false? Den stimmen tun möglicherweise beide nicht.

Ich hab das Ganze auch schon mal beim OpenKNX-Logikmodul durchdacht. Die Idee mit "Das Objekt kennt seinen Wert" finde ich gut, das gilt aber nur für einen direkten Neustart (und selbst da ist es nur Prinzip Hoffnung, da genau während des Neustarts eine Wertänderung verpasst werden kann).
Ich bin auf keine bessere Idee gekommen als dem User die Möglichkeit zu geben, was er will (nimm gespeicherten Wert oder lies einen Wert vom Bus) und intern mit 3-State-Logik zu arbeiten: Undefiniert ist ein valider Zustand, der true oder false sein kann.
Denn selbst wenn man vom Bus liest, muss ja keine Antwort kommen. Jeder Ausgang einer Logik ist bei mir undefiniert, bis die Logik einmalig erfolgreich durchlaufen wurde. Und jeder Eingang so lange undefiniert, wie er keinen gültigen Wert erhalten hat. Soll die Logik erst ausgewertet werden, wenn alle Eingänge gültig sind, ist das Processing klar. Wenn sie aber bereits ausgewertet werden soll, auch wenn noch ungültige Eingänge existieren, werden diese so behandelt, als ob diese Eingänge nicht da sind. Ein 4-fach UND wird dann zu einem 2-fach UND (weil 2 Eingänge ungültig sind). Damit sind die Eingänge semantisch ein TRUE. Wäre es ein OR, wären die Eingänge semantisch ein FALSE - sie können also wirklich beides sein (Schrödinger lässt grüßen ).
Ich hab im Logikmodul eher keine Objektpersistenz, aber ich halte es für falsch, grundsätzlich davon auszugehen, dass der letzte Objektwert nach einem Neustart noch seine Gültigkeit hat. Ich würde mir bei so einem Ansatz die Möglichkeit der Definition vom "Wertalter" wünschen. Der Wert wird immer mit einem Timestamp persistiert (macht ihr wahrscheinlich sowieso). Wenn beim Neustart der Wert älter ist, als ein vorgegebenes Alter, dann wird er verworfen und neu gelesen und gilt bis zur Antwort als undefiniert.
Beispiel: "Schlafmodus" wird vom User irgendwann abends per Taster gesetzt und morgens anhand von verschiedenen Bedingungen (manuell, Sonnenstand, Stundenplan der Schule, Wochenenderkennung) abgeschaltet. Also einerseits ein sehr flexibler, andererseits aber sehr lange anhaltender Zustand. Normalerweise für min. 6h gültig. Mach ich gerade einen Neustart während abends der Schlafmodus gesetzt wird, verpasst mein Server das. Und geht weiter vom Tagmodus aus -> Frust auf Userseite (Frau/Kinder). Der nächste gültige Wert (Tag) würde erst am nächsten Morgen kommen. Wenn aber der gespeicherte Wert weiß, er ist "Tag", aber 10h alt und Altersgrenze ist 6h, wird nach dem Neustart der aktuelle Wert gelesen. Ist es jetzt Nacht, wird das Alter auf 0 gesetzt und alles ist gut. Ist der Wert noch immer Tag, bleibt auch das Alter erhalten.
Das mit Alter ist eine Verallgemeinerung der bestehenden Konzepte:

• Nie lesen - euer Ansatz, immer den persistierten Wert zu nehmen (Alter = unendlich)
• Immer lesen - Viele Visus machen das, HA auch (Alter = 0). Führt aber immer zu hoher Buslast.

Natürlich sollte das mit dem Alter optional sein und der Default könnte hier auf unendlich (= aktuelles Verhalten) stehen.

Jetzt hab ich wieder viel mehr geschrieben als ich eigentlich wollte .

Gruß, Waldemar

[DirtyHarry]

Ich schreib meine Gedanken dazu einfach mal rein, was ihr draus macht ist eure Sache:

. Wenn sie aber bereits ausgewertet werden soll, auch wenn noch ungültige Eingänge existieren, werden diese so behandelt, als ob diese Eingänge nicht da sind. Ein 4-fach UND wird dann zu einem 2-fach UND (weil 2 Eingänge ungültig sind).

Gerade bei einem UND-Gatter darf das aber nur optional sein. Bei einem ODER-Gatter ist das nicht ganz so ausschlagegebend, spätestens wenn ein Eingang Wahr ist, kann weiter gearbeitet werden.

Unabhängig davon ist der Eingang eines Funktionsblocks (also z.B. ein ODER-Gatter) auf dem Logikblatt etwas anders zu sehen als ein ODER-Gatter in einem KNX-Baustein.
Bei den meisten KNX-Logik-Bausteinen ist ein Eingang des ODER-Gatters gleichbedeutetend mit dem KO, an dem die GA verknüpft wird. Dementsprechend muss auch hier definiert werden, wie bei undefiniertem Zustand reagiert werden soll (Lesen, Fixwert, evtl. undefiniert).
Das ODER-Gatter hier hat jedoch keinen direkten Zugang zu einem Wert, es bekommt ihn immer von einem anderen Baustein. Der Eingang auf das Logikblatt (der Baustein "Objekt lesen") wäre dann der Punkt, an dem die Entscheidung getroffen werden muss, wie bei undefiniertem Zustand reagiert werden soll.
So ähnlich ist es auch beim ABB ABL/S2.1 gelöst.

Beim Gira-Homeserver ist das eigentlich fast nur über die Fixwerte an den Logikbausteinen gelöst. Undefiniert gibt es nicht. An der GA wird wiederum definiert, ob sie beim Start gelesen werden soll. Ein "keine Antwort, dann nehme diesen Wert" ist da gar nicht vorgesehen. Teilweise macht es das schwierig, die Logik nach einem Neustart in den Zustand zu bringen, der vorher war.
Edomi müsste, wenn ich mich richtig erinnere, ja ähnlich ticken...

Andere Server blockieren das ganze Logikblatt, solange ein Eingang undefiniert ist. Das kann ganz schön nervig sein...

• Nie lesen - euer Ansatz, immer den persistierten Wert zu nehmen (Alter = unendlich)
• Immer lesen - Viele Visus machen das, HA auch (Alter = 0). Führt aber immer zu hoher Buslast.

Wenn man davon ausgeht, dass der Logikserver IMMER läuft und Verbindung zum Bus hat, mag "Nie lesen" ja funktionieren.


Jede der Varianten hat seine Vor- und Nachteile und man darf dann eventuelle Seiteneffekte nicht vergessen (was passiert z.B. wenn ich bei mehreren Eingängen mit der selben GA das Lesen aktiviere).






Btw:
Die Sortierung der DPTs
grafik.png
finde ich etwas suboptimal.