Ankündigung

Einklappen

Sammelbestellung ETS6 Vollversionen aktiv!

Sammelbestellung für ETS6 Vollversionen (Prof., Home, Lite) mit 40% Rabatt aktiv! Infos im Forum!
Mehr anzeigen
Weniger anzeigen

OBS - ein neuer Player in der Serverlandschaft?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    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.
    Viele Grüße Jens

    Kommentar


      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.
      Gruss Daniel

      Kommentar


        Zitat von abeggled Beitrag anzeigen
        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?

        Gruß -mfd-
        KNX-UF-IconSet since 2011

        Kommentar


          Zitat von mfd Beitrag anzeigen
          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.
          Gruss Daniel

          Kommentar


            Zitat von abeggled Beitrag anzeigen
            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


            OpenKNX www.openknx.de

            Kommentar

            Lädt...
            X