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.

[mfd]

Ich finde die Variante dem Nutzer eine Auswahlmöglichkeit zu geben nicht verkehrt.

Es kommt immer sehr auf die jeweilige Situation/Logik an, was gerade sinnvoll ist. In manchen Fällen möchte ich auf keinen Fall einen Wert, wenn der nicht vom Bus gesendet wird. In anderen aber unbedingt.

Sicher geht es wie von mumpf beschrieben mit Alter usw. auch zusätzlich noch eleganter.

DirtyHarry bei EDOMI hat man relativ viel Auswahl, was wann mit der betreffenden Gruppenadresse passieren soll. Dabei muss man noch unterscheiden, ob es sich um eine normale GA (von ETS importiert) oder um ein internes Kommunikationsobjekt handelt. Beim internen ist zuätzlich die Remanenz einstellbar.
edomi_ga_extern.jpg edomi_ga_extern_send_read.jpg edomi_ga_intern.jpg

[mno]

Sauberer Neustart ohne Bus-Chaos + lückenlose KNX-Historie mit einem read-only Downtime-Logger

Ich möchte hier mal vorstellen, wie ich zwei Probleme gelöst habe, die vermutlich jeder kennt, der eine eigene Logik-/Visu-Instanz am Bus betreibt:

1. Nach jedem Neustart weiß die Software nicht mehr, in welchem Zustand die Anlage ist — und ein naives „lies einfach alles vom Bus" ist weder schnell noch ungefährlich.
2. Während der Downtime (Deploy, Update, Absturz) gehen Telegramme unwiederbringlich verloren — die Historie hat Löcher, und man weiß nie, was in den 60s passiert ist.

Ausgangslage
Drei KNX-Linien (1.1, 1.2, 2.1), gekoppelt über einen Siemens N146/02 IP-Router (KNXnet/IP-Routing, Multicast). Der Agent selbst verbindet sich per Tunneling. Historisierung läuft in InfluxDB, Visualisierung in Grafana. Ein Neustart des Agents dauert typischerweise 30–60s.

Teil 1: Geschichteter Start statt Telegrammsturm
Der Start ist bewusst in Schichten aufgebaut, damit der Zustand korrekt wiederhergestellt wird, ohne den Bus zu fluten oder - schlimmer - versehentlich Aktorik auszulösen:

Schicht 1 - SQLite-Restore (kein Bus-Zugriff). Der letzte bekannte Wert jeder Gruppenadresse wird aus einer lokalen SQLite-DB in den Speicher geladen. Der Agent „weiß" damit sofort wieder, wie der letzte Stand war — bevor auch nur ein Telegramm gesendet wird. Parallel wird der Influx-Writer mit diesen Werten vorbefüllt (Dedup-Seed), damit die anschließenden Reads keine künstlichen Datenpunkte mit Neustart-Zeitstempel erzeugen.

Schicht 2 - InitSend. Wenige systemkritische GAs bekommen ihren konfigurierten Initialwert aktiv auf den Bus geschrieben - bewusst vor dem Lesen.

Schicht 3 - Startup-Read. Nur die als kritisch markierten Status-GAs (startup_read: true) werden per GroupValueRead abgefragt, mit ~200ms Throttle.

Schicht 3b - Batch-Read im Hintergrund. Alle übrigen GAs mit bekanntem DPT werden in Batches à 15 mit 2s Pause gelesen - priorisiert nach Hauptgruppe (Alarm/Heizung/Tore zuerst, Hue zuletzt). Läuft je nach Anlagengröße 2–3 Minuten und bricht sauber ab, wenn die Verbindung wegfällt. Danach übernimmt ein Periodic-Refresh für Zähler und Sensoren, die nicht zyklisch senden.

Schicht 4 - Warmup. In den ersten 5 Min. nach dem Start werden keine Push-Benachrichtigungen verschickt. Die Logik läuft normal, aber der Startup-Burst erzeugt keinen Alarm-Schwall aufs Handy.

Was bewusst NIE gelesen wird: Schloss-, Riegel-, Tor- und Alarm-GAs sowie die komplette Hauptgruppe „Sperren". Ein GroupValueRead auf ein Befehls-/Aktorobjekt kann über Kopplungen ungewollt etwas auslösen (bei mir z. B. ein Hue-Blinksignal am Hoftor). Der letzte Stand dieser GAs kommt ausschließlich aus Schicht 1. Wichtig: Nur das Lesen wird unterdrückt - bewusstes Schalten ist davon unberührt.

Reconnect / Neustart: Wenn nur der Bus kurz weg war (Tunnel-Abriss), werden nach ~3s ausschließlich die kritischen GAs neu gelesen -kein kompletter Re-Read, kein Telegrammsturm. Und ein geplanter Shutdown setzt vorher ein Flag, damit kein falscher „Bus verloren"-Alarm rausgeht.


Teil 2: Ein unabhängiger read-only Downtime-Logger
Die Schichten stellen den aktuellen Zustand wieder her. Was sie prinzipbedingt nicht können: rekonstruieren, was während der Downtime auf dem Bus passiert ist. Dafür gibt es einen zweiten, komplett unabhängigen Baustein:

Ein eigener kleiner LXC-Container (pi wäre auch möglich) mit einem systemd-Dienst, der per xknx im Routing/Multicast-Modus rein passiv mithört. Er sendet niemals GroupValues - kein Schreibzugriff auf den Bus, keine reservierte physikalische Adresse nötig. Jedes GroupValueWrite/Response landet mit echtem Zeitstempel in einem eigenen Influx-Bucket mit 7-Tage-Retention.

knb.png

Ein paar Details, die sich in der Praxis bewährt haben:

• Konsistente Decodierung: Der Logger nutzt exakt dieselbe DPT-Decodierung wie der Agent. Die GA-DPT-Zuordnung stellt der Agent als statische JSON-Datei bereit -der Logger zieht sie sich einfach dort ab.
• Dead-man's-Switch: Kommt >5 Min. kein Telegramm, gibt es eine Warnung -das erkennt zuverlässig Multicast-/IGMP-Probleme, die sonst erst mal unsichtbar wären.
• Gegenseitige Überwachung: Der Agent überwacht umgekehrt den Heartbeat des Loggers und meldet sich, wenn der Logger stumm ist.

Backfill nach dem Neustart: ~30s nach jedem Agent-Start zieht sich der Agent das Downtime-Fenster (letztes Lebenszeichen bis jetzt) aus dem Logger-Bucket in die Buckets nach - mit den echten Zeitstempeln. Wichtig: Das ist reine Historie, es wird dabei keine Logik und keine Aktorik ausgelöst. Im Dashboard sehe ich pro Neustart, welche Telegramme verpasst wurden und welche Automatiken, Sequenzen, Zeitschaltuhren, Szenen davon betroffen gewesen wären - mit der Option, sie bei Bedarf manuell (freigegebene automatisch) nachzuziehen. Grafana: Downtime sichtbar machen

Das Zusammenspiel aus geschichtetem Start (Zustand) und passivem Zweit-Logger (Historie) hat sich bei mir absolut bewährt: Deploys und Updates sind jetzt völlig entspannt, weil nichts mehr verloren geht und beim Hochfahren nichts Ungewolltes auf dem Bus passiert.

[BadSmiley]

Nach jedem Neustart weiß die Software nicht mehr, in welchem Zustand die Anlage ist — und ein naives „lies einfach alles vom Bus" ist weder schnell noch ungefährlich.

Himmel, wer sowas schreibt, hat die Flags seiner Anlage nicht im Griff.

[gbglace]

Drei KNX-Linien (1.1, 1.2, 2.1), gekoppelt über einen Siemens N146/02 IP-Router (KNXnet/IP-Routing, Multicast).

Spannend wie hst denn diese Topologie hinbekommen, einen Koppler mit drei Linien ohen jedwede Hautplinie.

Wozu solch ein Aufwand?

[abeggled]

Und was hat deine Entwicklung nun mit dem Open Bridge Server zu tun?

[ITler]

Sauberer Neustart ohne Bus-Chaos + lückenlose KNX-Historie mit einem read-only Downtime-Logger

Klingt ein wenig nach einer wahnsinnig aufwendigen Lösung für ein Problem, das hausgemacht ist oder im echten Leben keine Rolle spielt.

Ich sende wichtige Werte einfach zyklisch (Sommer/Winter, Tag/Nacht, Temperatur Soll/Ist,
..) , so pendelt sich die Anlage ganz automatisch vom selber wieder ein.

BTW: Unprovoziert hat sich mein Bus in 10 Jahren nicht resetet