Zelkin hat geschrieben: ↑Mi Aug 31, 2022 8:25 pm
Also den Wert schreiben (wird durch ein Script in Abhängigkeit der duechschnittstemp der letzten Woche erledigt) und davon ausgehen dass der Wert immer passt...... Würde hier grundsätzlich sogar gehen!
Ja, richtig.
Was anderes ist es, wenn Du der Kommunikation nicht traust, z.B. weil die Verbindung wacklig ist. Dann musst Du regelmäßig den Eigentümer des Zustands abfragen (ein Event) und damit den redundanten Wert aktuell halten - denn sonst "ist die Gefahr hoch, dass sich diese widersprechen. Das muss zwingend vermieden werden!"
Zelkin hat geschrieben: ↑Mi Aug 31, 2022 8:25 pm
Dann gehen wir einen Schritt weiter, Betriebsmodi
Das Event ist z. B. Haus ist verlassen (Knopf an der tür oder aus der visu am Handy weil man den Knopf vergessen hat oder durch Erkennung dass die Handys aus dem Haus sind)
Nun ist standby zu beschreiben mit true damit wechseln die beiden anderen auf false..... Event ist klar zustand ist dann standby
Um diesen auslesen zu können muss ich aber alle 3 abfragen da der visu NUR die true schaltungen bekannt sind (iss ja nur publish) steht mir diese info nicht zur Verfügung
Sehr schönes Beispiel!
Stell Dir vor jede betroffene Stelle muss nun selber auf die Event hören ob nun jemand das Haus verlässt oder wieder kommt. Sollte auch nur eine Stelle davon aus irgend welchen Gründen eines dieser Telegramme nicht mitbekommen hast Du plötzlich einen inkonsistenten Zustand zwischen diesen Systemen
Die Lösung kann daher nur eine (zentrale) Logik sein, die diese Events auswertet und daraus den allgemein gültigen Zustand "Betriebsmodus" bildet. Diesen Betriebsmodus haben alle anderen Geräte nun zu verwenden.
Diese Logik kann übrigens gar nichts "abfragen", die kann nur live mitrechnen wenn das Event "Knopf an der Tür" passiert.
Andernfalls würdest Du halt viele "Klein-Logiken" brauchen die dieses Event auswerten und der "großen Logik" mitteilen was hier als letztes (= ein Zustand) gesendet wurde. Aber welchen Unterschied machen viele kleine zu einer großen Logik?
Ich finde da einen ordentlich programmierten Zustandsautomaten die elegantere und saubere Lösung.
Du wirst aber natürlich über Probleme stolpern für die es keinen "natürlichen" Eigentümer dieses Zustands gibt (wie z.B. dem Binär-Eingang zum Thema offener Türe). Bei mir ist so ein Fall die Information "Erzwinge Wochenende". Da habe ich mir nicht die Mühe gemacht eine Kalender-Einbindung zu bauen (das wäre eine elegante Möglichkeit dafür um Feiertage und Urlaubstage zu kennen), sondern ich habe einen Visu-Button der einfach "Erzwinge Wochenende" ein- bzw. ausschaltet (ändert z.B. wann in der Früh im Schlafzimmer der Rollladen hoch fährt). Da brauche ich nun einen Eigentümer dieses Status. Und dieser Eigentümer ist dann halt die Logik-Engine selbst. Die muss dann aber auch dafür sorgen, dass diese Info immer zur Verfügung steht - auch nach einem Stromausfall.
=> Genau deshalb hatte ich damals für das Wiregate das StateSave-Plugin geschrieben:
https://knx-user-forum.de/forum/öffentl ... #post16344
Inzwischen nutze ich Node-RED dafür, was bei mir dann so aussieht:
(Die drei KNX Blöcke sind für Schreiben bzw. Lesen und dann Antworten; noch besser wären getrennte GAs für Schreiben und Rückmelden, darauf konnte ich im konkreten Fall aber verzichten)
Zelkin hat geschrieben: ↑Mi Aug 31, 2022 8:25 pm
Einzig gültige Quelle sind die 3 ko des heizungsaktor..... Um eine Änderung des zustands herbeizuführen muss bei einem Event eine der ko's verändert werden wobei die anderen in dem Moment reagieren
Nö. Das Heizungsaktor-KO zeigt nur den Zustand
genau dieses Heizungsaktors an.
Du kannst natürlich eine "Zentral alles abwesend" GA einführen, auf die jeder Heizungsaktor noch hört (hörende GA ist ja jede weitere GA nach der ersten auf einem KO). Aber dann hast Du immer noch 3 Zustände und nicht nur einen.
Und wie soll die Visu-Seite dafür aussehen? "Status: unbekannt, da 2 sagen nicht anwesend, aber 1 sagt doch anwesend"?!
Um nun diesen einen Master zu bekommen kannst Du eine Logik nutzen und basierend auf diesem Status dann die einzelnen Heizungsaktoren schalten. Oder einen Heizungsaktor als Master der Anwesenheit definieren und alle anderen dürfen nur noch darauf hören und niemals schreiben.
Und da man auch das Thema Stromausfall und Wiederstart danach berücksichtigen sollte würde ich persönlich zur Logik mit einem Stromausfall gesicherten Wert setzen und nicht auf die einzelnen Aktoren. Die wissen in der Regel den Status danach nicht mehr. (Oder schreiben ihr Flash kaput, wenn die jeden Statuswechsel dort abspeichern müssen)
Zelkin hat geschrieben: ↑Mi Aug 31, 2022 8:25 pm
Die Probleme zu identifizieren und Alternativen zu suchen um Kompatibilität herzustellen ist doch sinnvoller als zu sagen nimm was anderes.
Nur Systeme die die notwendige Funktion bereitstellen können die notwendige Funktion bereitstellen. Die anderen eben nicht. Egal wie lange Du suchst.
Von den Systemen, die die Funktion bereitstellen, kannst Du dann frei nach Lust und Laune aussuchen. Mir ist Deine Wahl dabei ziemlich egal, die muss ja für Dich passen und nicht für mich.
Es gibt einige hier im Forum die sehr gut mit den TWS Logiken können, die wiederum für mich persönlich nicht passen. Das ist aber auch vollkommen egal, weder haben die anderen noch habe ich allgemeingültig recht. Jedem das, was für ihn am besten funktioniert.