OpenKNX-VirtualPresence - entsperren klappt nicht zuverlässig

[traxanos]

Wenn die 5 gar nicht bearbeitet werden würde, da die 64 zu schnell käme, könnte ich der Logik folgen, aber genau das habe ich ja dadurch ausgeschlossen, dass dasselbe Gerät die Logik sendet. Es muss also erst die 5 ankommen, da es sonst keine 64 gibt.

Dazu noch eine Ergänzung: Es kann sein das ein Kanal die Verarbeitung gestartet hat, aber ein anderer Kanal noch nicht. Der KNX Stack muss sehr häufig aufgerufen werden damit u.a. die ACKs gesendet werden können. Daher wird immer wieder geschaut ob die Verarbeitung pausiert werden muss, damit der KNX Stack & Co aufgerufen wird. Es kann also sein das ein Kanal die Daten verarbeitet hat dann der KNX Stack aufgerufen wird. Dabei kann der Wert überschrieben werden. Der nächste Kanal ist sieht dann nur noch den neuen Wert.

Ob das bei dir der Fall war - keine Ahnung. Will nur erläutern was knappes Timing für Probleme machen kann.

[Sven1234]

Verstehe ich schon, nur weshalb man das zulässt und den einmal gelesenen Wert nicht außerhalb des volatilen Bereichs zwischenspeichert für jeden aktiven Kanal, kann ich nicht nachvollziehen. Das hieße ja, dass man sich nicht darauf verlassen kann, dass ein Logikgerät mit mehr als einem Kanal zuverlässig arbeitet.

Szenen, die über Logikausgänge kommen, kann man verzögern, aber zum einen können diverse Verzögerungen sich so überschneiden, dass doch wieder zwei glwichzeit kommen und zum anderen gibt es eben Menschen, die Knöpfe drücken und da KNX für große Installationen gedacht ist, gibt es viele Knöpfe und viele Menschen.

Mir fehlt da die Robustheit in der Konzeption.

[traxanos]

in 99,999% der fälle gibt es keine problem. das ist ein sehr seltener spezifischer fall. der in der praxis normal keine relevanz hat. das muss nichtmal dein problem sein. es sollte nur dafür sensibilisieren das es auch sein könnte.

[mumpf]

Dass das eine Funktion statt eines Fehlers sein soll, bzw. so arbeitet wie entworfen, fällt mir schwer zu verstehen.

Hier habe ich nicht verstanden, was Du als Funktion siehst bzw. was wir als "designed" statt fehlerhaft hinstellen.

Ich beziehe mich jetzt mal nur auf den Satz:

Diese Szene schaltet alle Lichter aus. Die "Lösung" war, dass ich die Logik mit einer Verzögerung senden lasse. Seitdem klappt es einwandfrei, allerdings ist die Verzögerung ärgerlich, da man keine direkte Rückmeldung beim Betätigen des Tasters bekommt (Licht aus).

Es kommt also die Szene 5 an dem Eingangs-KO für das Logikmodul und den Eingangs-KO vom PM (Szenensteuerung) an. Jedes KO, dass ein Telegramm empfängt, sendet ein Event an das verarbeitende Modul. Beide Module (PM und Logik) bekommen also eine Info, dass da was abzuarbeiten ist.
Hier gibt es genau 2 Möglichkeiten, wie es ablaufen kann:

1. In der Verarbeitungs-Queue ist gerade der PM dran, der liest die Szene 5 und entsperrt den Kanal und gibt danach Rechenzeit ab, dann kommt die Logik, liest die Szene 5, schickt Szene 64 raus, wodurch natürlich auch PM und Logik nochmal getriggert werden (ist ja die gleiche GA), aber beide reagieren ja nicht auf die Szene 64 - alles ist gut.
2. In der Verarbeitungs-Queue ist gerade die Logik dran, die liest die Szene 5 und sendet die Szene 64. Hier wird die Szene 5 am KO vom PM mit der 64 überschrieben*, noch bevor der PM eine Chance hatte, sein Event zu verarbeiten. Wenn der PM danach dran ist, sieht er nur die Szene 64 und reagiert nicht drauf.

*) Ein Gerät, dass sendet, kann nicht gleichzeitig empfangen. Wenn der KNX-Stack im Gerät also beim senden feststellt, dass die selbe GA mit mehreren KO verbunden ist (diese also eine Gruppe bilden), wird immer beim senden von einem KO der Gruppe intern jedes andere KO der Gruppe dem gleichen Wert beschrieben, so als ob ein entsprechendes Telegramm empfangen worden wäre. Sonst könnte man nie ein Gerät haben, dass die gleiche GA am Eingang- und Ausgang hat (in der grauen Urzeit vom KNX war das auch mal so).

Im Fall 2 hat man keine Chance, irgendwas zu verbessern, dass ist tief im Stack verwurzelt und auch korrekt so. Würdest Du so komplexe Sachen mit produktiven Geräten bauen können, hättest Du dort die selben Probleme (oder noch mehr, je nachdem, wie stark solche komplexen Szenarien vom Hersteller untersucht werden).

nur weshalb man das zulässt und den einmal gelesenen Wert nicht außerhalb des volatilen Bereichs zwischenspeichert für jeden aktiven Kanal, kann ich nicht nachvollziehen.

Zum einen würde das den doppelten Verbrauch vom Arbeitsspeicher bedeuten, das ist in einem Microcontroller nicht zu vernachlässigen. Und in Deinem Fall würde das auch nicht helfen. Denn wenn die Logik zuerst dran kommt und den neuen Wert schreibt, würde der neue Wert auch in den Zwischenspeicher übernommen werden (und auch übernommen werden müssen) - es ist der neue Wert, und natürlich muss der jetzt gelten. Und falls Du jetzt kommst mit "man kann ja erst den alten Wert verarbeiten und dann erst den neuen nehmen", dann spiel das mit 3, 4, 5 (im Extremfall n) Werten durch, dann siehst Du selber, dass das keine Lösung ist.

Ja, aber in diesem Fall wird die 5 ja vom Gerät "akzeptiert", denn es passiert etwas, die Logik löst aus.

Genau, das Gerät macht was an einem KO, das heißt noch lange nicht, dass ein anderes KO genau so verarbeitet wird. Sobald Du einen neuen Wert schreibst, gilt dieser. Letztendlich ist das auch Dein Problem: Du überschreibst einen Wert und beschwerst Dich, dass der neue Wert genommen wird. Das ist genau so, als ob Du in einem Programm ein A=5 hast, dann A=64 setzt, aber erstmal bei den nächsten paar Programmzeilen willst, dass noch A=5 gelten soll. Aus hier ist die Lösung, A=64 später im Programm zu setzen.

Wenn man mit Verzögerungen arbeiten muss, dann wäre es doch hilfreich, wenn man auch bei den VPM-Ausgängen eine Verzögerung einstellen könnte, zumindest zwischen Ausgang 1 und 2. Oder übersehe ich diese Möglichkeit in der 3.6.2?

Nein, ich werde Fehlmodellierungen sicherlich nicht auch noch unterstützen. Du willst 2 Telegramme haben, auf der selben GA, und um es noch schlimmer zu machen, sind das auch noch Szenen. Szenen bewirken normalerweise viele Statusmeldungen, die die Buslast erhöhen, so dass ein Senden von 2 Szenen nacheinander potentiell nichtdeterministisch werden kann.
Der ganz richtige Weg (im KNX-Sinne) wäre, eine dritte Szene zu machen (die die Funktionen der ersten beiden vereint) und nur diese zu senden. Der zweitbeste Weg ist, dies mit Verzögerungen über einen Logikkanal zu lösen, damit die Geräte Zeit haben, beide Szenen nacheinander zu verarbeiten. Und nur so kann man sicherstellen, dass beide Szenen auch in korrekter Reihenfolge am Ziel ankommen (sonst: 1. Szene bekommt ein NACK. Bis sie wiederholt wird, wurde die 2. Szene korrekt empfangen, dann erst die Wiederholung der Szene 1 - dann sind sie "falsch rum").
Die 2 Ausgänge beim PM gibt es, damit man 2 verschiedene Telegramme mit verschiedenen DPT senden kann, ohne gleich auf Szenen ausweichen zu müssen.

Mir fehlt da die Robustheit in der Konzeption.

Uhhhh, heißes Eisen - damit triffst Du einen Nerv bei mir. Denn wenn ich (und ein Großteil der Teammember) etwas versuche in den Tagen und Nächten, die ich mit Verhaltenstests verbringe, dann ist es ein robustes und deterministisches Verhalten zu erreichen. Dass das nicht immer klappt, weil ich eben auch Fehler mache, ist unbenommen. Aber "Fehlende Robustheit in der Konzeption" ist schon ein Schlag ins Gesicht.

Abschließend kann ich nur sagen: Wenn Dir die Konzepte von OpenKNX nicht reichen, dann sind unsere Geräte vielleicht nichts für Dich. Das ist durchaus valide und wir zwingen die Geräte ja keinem auf. Du kannst natürlich auch den KNX-Stack nehmen, ihn verbessern und in einer "robusteren" Version in Deinen Geräten nutzen oder - noch viel besser - die verbesserte Version dann allen zur Verfügung stehen.

Trotzdem bin ich mir relativ sicher, dass Du Dein Problem oben (2 Werte auf einer GA) auch mit einem neuen Stack nicht ohne Verzögerungen zu einem deterministischen Verhalten führen wirst, denn 2 Werte auf einer GA sind ein konzeptionelles Problem.

Gruß, Waldemar

[Sven1234]

Nur kurz, ausführlicher morgen. Ich meinte eher KNX, als eure Arbeit bzgl. Robustheit. Zumindest hatte ich es so verstanden, als wäre das ein KNX Konzept und nicht spezifisch für euer Projekt. Sprich, beim MDT Logikmodul hätte ich dasselbe Problem, wenn Logiken Szenen an das MDT Logikmodul senden. Das konnte ich mir nicht vorstellen, habe es aber auch noch nicht ausprobiert.

Und ehrlich gesagt verstehe ich es glaube ich immer noch nicht, da ihr es für so unproblematisch haltet, also muss ich irgendwo ein Brett vor dem Kopf haben. Den technischen Ausführungen kann ich folgen, bei den konzeptionellen noch nicht.

[traxanos]

Naja man muss halt unterscheiden das wir halt sehr viele eigenständige Funktionen auf einem Gerät laufen lassen und das ganze viel wilder treiben und damit mehr machen können. Andere Gerät haben ggf das Problem in der Form nicht. Wobei ich meine ein ähnliches Problem mit MDT Jal-Aktoren schonmal hier im Forum gelesen zu haben.

Aber KNX ist über 20 Jahre alt. Damals gab es noch keine leistungsstarke HW wie heute. KNX ist robust für das wie es konzipiert wurde. Ich glaube immer noch du gehst die Sache viel zu kompliziert an. Ich glaube du siehst den Wald vor lauter Bäumen nicht. Ggf machst du mal einen eigenen Thread auf und schreibst was du genau vor hast etc. Und ggf kann man dir dann einen Tipp geben wie man was machen sollte.