ElabNET Technik Forum

Angetrieben vom Thread viewtopic.php?f=31&t=1751#p18426 würde ich eine weitere Ebene der Persistenz vorschlagen: Persistenz auf dem KNX-Stack

Hintergrund ist, dass bei einem Neustart alle KNX-Objekte auf dem Initwert (0) stehen und ein Read auch entsprechend beantwortet wird. Besser wäre es, wenn der KNX-Stack (oder alternativ ausgewählte KOs) seinen zuletzt gesendeten Zustände behalten würde.

Vorschlag:
Persistenzfunktion, global für alle KOs des Stacks oder selektiv für einzelne KOs aktivierbar.

Bitte noch ergänzen, auch die empfangenen Werte. Denn der verlinkte Thread stellt die Forderung nach einer Persistenz der zuletzt empfangenen Daten, um diese ggf. bei Readquest beantworten zu können.
Das ist wieder was anderes als reine Ausgangs-KO des TWS.

Deswegen hatte ich es hier eigentlich als "Zustand" beschrieben. Für mein Verständnis ist es dann unerheblich "woher" dieser Zustand kommt (also ob intern von einer Logik auf den Stack geschrieben, oder von extern vom Bus auf den Stack geschrieben).

Dragonos2000 hat geschrieben: ↑Mo Dez 16, 2019 4:54 pmFür mein Verständnis ist es dann unerheblich "woher" dieser Zustand kommt (also ob intern von einer Logik auf den Stack geschrieben, oder von extern vom Bus auf den Stack geschrieben).

Da muss man nochmal scharf darüber nachdenken.

Ich denke es wäre durchaus erheblich, "woher" der letzte Zustand kommt.

Nehmen wir folgendes an:

- KNX Sensor sendet Wert an eine GA an den Bus
- TWS hat ein Objekt darauf, das mit der GA verknüpft ist, nimmt also den Wert vom Bus und speichert diesen intern in seinem Objekt-Register
- Bumm- Spannungsausfall, alles platt
- Nach Spannungswiederkehr fährt alles hoch, der KNX Sensor wie der TWS.
- Jetzt kommt von irgendwoher ein Read-Request auf den Bus für die betreffende GA

==> Nun Antworten ALLE Devices welche diese GA mit einem Ihrer Objekte verknüpft haben und deren "Read"-Flag gesetzt ist (wobei durchaus dann auch andere GA antworten, sofern wenn die per Read-Request gefragte GA zwar mit einem Objekt verknüpft ist, aber diese GA nicht gleichzeitig die "Sending GA" für das Objekt ist").

d.h. das kann also knifflig werden. Weil je nach Flag und der Assozierung der GAs zu den Objekten in den Devices, kommen womöglich mehrere Responses an. Will man da auch noch womöglich einen "alten" Wert haben der im TWS zwischengespeichert ist und der vom vor dem Stromausfall stammt (der auch tagelang gedauert haben kann)?

Was ich besser finde:

- Gebt den TWS-Objekten, die von anderen KNX-Devices stammen das "Read-on-Init" Flag, dann holt sich der KNX-Stack automatisch beim Neustart die aktuellen Werte.
- Setzt das READ-Flag dort auf off, weil es soll nur das Device antworten, dass auch für den Wert verantwortlich ist (also der KNX Sensor)

Mit zwischengespeicherten Werten unabhängig von deren Alter sollte man nicht arbeiten. Wenn doch, dann müsste man noch ein konfigurierbares Cache-Alter zum konfigurieren haben. Nur wer blickt dass dann alles noch?

lg

Stefan

Hallo Stefan! Jochen!

Den Ansatz mit L-Flag finde ich gut, read-on-init kenn ich nicht.

Es sollte je GA nur 1 L-Flag geben, alles andere ist Murks.
Ich hatte eine zeitlang zuvirle L-Flags in der TWS Applikation. Da passiert genau das, was Stefan beschrieben hat: der Aktor antwortet mit 1, der TWS mit 0 (weil seit Reboot kein Telegramm kam) und schon zeigt die Visu mit 0 den falschen Status.

Somit wäre der Ansatz, dass Objekte mit gesetztem L-Flag den persistenten Wert gesetzt bekommen, ein sehr guter, einfacher, praxisnaher Ansatz.
Damit sind Logikeingänge (zb Visu-Schalter) und Logikergebnisse von der Visu richtig lesbar.

Lg
Robert

Ja ohne Maske im KNX Objekteditor wo man dann genau je Objekt definiert welches gepuffert werden soll und welches auf Read antworten soll und welches bei einem durch TWS initiierten Rundruf auch senden soll wird das nicht gehen.

Und Kunden die keine wirkliche Ahnung haben aber im Strom von will alles haben leben und überall nen Haken setzen, können da ganz verrückte Sachen mit machen.

Denn man muss einmal darauf achten wer sonst im Projekt noch alles ein L-Flag hat. Bzw. Welche KO werden in einer Logik mit ggf genau entgegengesetzten Persistenz Regeln genutzt und durch diese übergelagerte Funktion dann ggf wieder kaputt gehen.

Anders allerdings wenn man dem TWS in hier ja oft anzutreffender Großzügigkeit eh allen GA 1:1 ein KNX KO spendiert hat, könnte man in dem Vertrauen, dass der TWS das stabilste Gerät im Bus ist mit einem solchen Feature auch einfach alle anderen Geräte ohne L-Flag programmieren und hätte im TWS den busweiten Status-Speicher für alles.

Sicher ein einmaliges Feature, in der vollen Konsequenz aber sicher nicht für Anfänger zu beherrschen.

Das mit den Logikeingängen und Logikausgängen würde ich hier in der Beschreibung noch raus lassen, denn die haben ja erstmal nichts damit zu tun was auf der KNX Objektebene passiert.

Und noch ein Punkt das Timing beim Hersteller chfahren des Busses / TWS.
Je nach Größe des Stromausfalls kann der Bus ja schneller wieder da sein als der TWS, dann hast ne Situation, das einige Geräte zwar kein L Flag haben weil man ja den TWS als zentralen Status Speicher definiert hat, bei denen aber in den Parametern Sendeoptionen bei Busspannungswiederkejr gesetzt sind. Das kann dann auch wieder mit einem später in Erscheinung getretenen TWS kollidieren, wenn der ggf noch die Option hat bei Restarts schicke Mal alle GA aus dem Speicher in den Bus. Kann gut gehen um sowas wie Logiken und Visu einheitlich zu initialisieren kann aber auch schiefgehen.

Ich habe die Diskussion abgetrennt:
viewtopic.php?f=31&t=1776

@Dragonos2000: würde vorschlagen, dass wir den FR zu gegebener Zeit anpassen.

Robert