VPM & Logik: Unberechenbares Verhalten, verschwundene KO's

[willisurf]

Was mir noch einfällt, hast Du eventuell eine zweite Hardware zum Testen?

[Marino]

Danke für den Tipp. EasyKNX ist möglicherweise einfacher, als das immer in die Visu zu programmieren.

Zweite Hardware: Ja und nein. Ich habe zwei, aber es fehlten noch Teile beim zweiten. Das Nachschicken eilte bisher nicht, daher habe ich momentan nur eine lauffähige Hardware.

[Marino]

Ich wollte mal wieder Feedback geben, auch wenn ich durch Krankheit in letzter Zeit nicht testen oder programmieren konnte.

Ich habe alles raus gelöscht, Projekt komprimiert und alles neu programmiert. Der Präsenz-Eingang ist nun wieder da

Ich habe im VPM "Präsenz und weitere Präsenz" verwendet und damit Presence und TruePresence vom Steinel verbunden. Das Licht ging manchmal nicht an und manchmal einfach aus, obwohl Präsenz oder TruePresence noch anlag (in Visu dargestellt).
Dann habe ich nur "Präsenz" verwendet und direkt mit beiden GA's vom Steinel (Presence und TruePresence) verknüpft. Funktionierte ebenso wenig.

Also nochmal die ODER-Logik, die ja auch nicht richtig funktionierte => Presence oder TruePresence = Ausgang

Wenn ich den Raum betrete, funktioniert es und das Licht geht an. Dann schaltet er ein paar Mal zwischen Presence und TruePresence hin und her und die Logik funktioniert bis auf einmal der Ausgang 0 schaltet, obwohl noch ein Eingang an ist (welcher das ist, spielt keine Rolle) und ab da nicht mehr funktioniert. Die Eingänge schalten weiter abwechselnd 1/0, aber der Ausgang bleibt auf 0. Erst wenn beide Eingänge 0 sind und anschließend einer wieder auf 1 schaltet, schaltet der Ausgang wieder richtig auf 1.
Ob die Logik Eingangssignalen sendet oder bei Änderung des Ausgangs macht keinen Unterschied.

Nun das Wichtige: Ich weiß nicht direkt woran es liegt, aber es scheint wohl nicht am VPM/Logik-Modul zu liegen. Denn mit der Logik eines MDT Glastasters ist das Verhalten exakt gleich. Programmiere ich in Edomi eine Logik und lasse mir diese parallel anzeigen, funktioniert diese exakt so, wie man es erwarten würde.

Manchmal funktioniert die Logik mit mehrfachem Schalten der Logik-Eingänge 10s richtig und auf schaltet der Ausgang aus, obwohl noch ein Eingang an ist.

Wenn ich die Logik am VPM anschließe, ist es logisch, dass das nicht funktioniert. Wem aber 2 Präsenzeingänge am VPM genutzt werden (egal ob triggernd oder schaltend), funktioniert es ja ebenso wenig und ich stehe andauernd im dunkeln.


Flags:
Steinel Ausgänge (Presence & TruePresence): K L Ü
Logik-Eingänge (MDT und Logik-Modul): K S Ü A
Logik-Ausgang (MDT und Logik-Modul): K L Ü
Alle Geräte programmiert. Steinel auch mal entladen und zurück gesetzt.

Das Verhalten kann ich mir nicht erklären, da die Logik ja anfangs funktioniert und dann auf einmal aussetzt.

Naja, so ist der Stand. Irgendwie ein wenig ernüchternd momentan.


Viele Grüße
Nils

[willisurf]

Dann habe ich nur "Präsenz" verwendet und direkt mit beiden GA's vom Steinel (Presence und TruePresence) verknüpft. Funktionierte ebenso wenig.

Das geht tatsächlich nicht, die letzte Botschaft gewinnt.

Am besten machst Du mal Screenshots Deiner Konfiguration und GA Zuordnung.

[Marino]

Das dachte ich mir auch, wollte es aber doch testen. Kommt halt auf die Telegrammreihenfolge an. Bilder mache ich mal, bin aber momentan nicht am PC...


Viele Grüße
Nils

[mumpf]

Hallo Nils,

ich kann nur anbieten, dass wir eine online-Session machen und ich mal mit drauf schaue... Das passt alles nicht so richtig oder ich verstehe es noch nicht wirklich. Ich schick Dir ne PN.

Gruß, Waldemar

[mumpf]

Zur Info an alle: Wir haben in einer Online-Session alle Pukte (er-)klären können,

Verschwundene KO: Das Logik- bzw. Präsenzmodul bietet - wie viele meiner Module - auch interne Verknüpfungen von KO. Dadurch kann man sich viele Telegramme am Bus sparen. Ein Eingang kann nur intern oder extern existieren, wenn er intern verknüpft wird, wird das KO in der ETS ausgeblendet, damit es nicht mehr mit einer GA verknüpft werden kann. Die "verschwundenen" KO waren alles intern verknüpfte Eingänge.

Ich weiß nicht direkt woran es liegt, aber es scheint wohl nicht am VPM/Logik-Modul zu liegen. Denn mit der Logik eines MDT Glastasters ist das Verhalten exakt gleich.

Wie hier Marino schon festgestellt hat, lag das unerwartete Verhalten vom Logikmodul nicht am Logikmodul selbst sondern am Timing vom Steinel TP. Das Logikmodul ist so schnell, dass es auch unerwartete (aber korrekte) Zustände berechnet. Aber das Logikmodul (meins, nicht das vom MDT-Glastaster) bietet (natürlich) auch die Lösung für solche Probleme. Das Problem mal auf ein einfaches Beispiel runtergebrochen:

Das Logikmodul soll ein einfaches OR bilden zwischen den TP-Signalen Presence und TruePresence. Da (laut Beschreibung von Steinel) immer entweder Presence oder TruePresence gesetzt ist, erwartet man, dass ein OR zwischen den beiden Signalen immer TRUE ist. Wenn man sich aber im Gruppenmonitor exakt die Telegramme vom TP anschaut, kommt so was

Presence ON               // initiales einschalten
...
TruePresence ON        // wechsel von Presence auf TruePresence
Presence OFF
...
TruePresence OFF      // wechsel von TruePresence auf Presence
Presence ON
...
TruePresence ON        // wechsel von Presence auf TruePresence
Presence OFF
...
TruePresence OFF      // wechsel von TruePresence auf Presence
Precence ON​

Und jetzt in Verbindung mit einem (sehr schnellen) OR, das nur sendet, wenn sich der Ausgang ändert:

Presence ON
OR ON                        // erwartungskonform
...
TruePresence ON
Presence OFF
...
TruePresence OFF
OR OFF                       // unerwartet, aber hier sind beide Eingänge OFF
Presence ON               
OR ON                         // erwartungskonform
...
TruePresence ON
Presence OFF
...
TruePresence OFF
OR OFF                       // unerwartet, aber hier sind beide Eingänge OFF
Precence ON
OR ON                         // erwartungskonform​

Würde Steinel immer zuerst den Ausgang senden, der TRUE wird und dann den, der FALSE wird, würden diese Zustände nicht auftreten.
Aber wie schon gesagt, es gibt auch im Logikmodul eine Lösung für dieses Problem:
Man schaltet am Ausgang einfach eine Ausschaltverzögerung von 1/10s mit der Eigenschaft "Wenn während der Verzögerung ein EIN empfangen wird, soll das AUS-Singal unterdrückt werden".
Kaum hatten wir das aktiviert, was alles gut.

Ich denke, Marino wird auch noch etwas hier zu schreiben, aus meiner Sicht sind erstmal alle Fragen geklärt und die infrage gestellten Funktionen hatten keine Fehler. Was nicht heißt, dass es nicht Fehler geben kann, es wurden nur keine neuen gefunden.

Gruß, Waldemar

[trollmar]

Meinen Respekt für dein Engagement die Probleme anderer zu lösen .

[Ing-Dom]

Meinen Respekt für dein Engagement die Probleme anderer zu lösen

ja wirklich, so einen guten Support bekommst du ja normal nicht mal für Produkte die man gekauft hat.
Hier bekommst du was geschenkt (die FW) und obendrauf noch 1:1 Support vom Chefentwickler

[TabSel]

Meinen Respekt für dein Engagement die Probleme anderer zu lösen .

Absichtlich vollzitiert, ich schließe mich da an!

[mumpf]

Meinen Respekt für dein Engagement die Probleme anderer zu lösen

Danke euch für die Blumen...

Wobei es nicht so ist, dass ich jetzt die Logiken für alle User schreiben werde, nur weil ich das Logikmodul erstellt habe. Ich fand es interessant wegen der "unerwarteten" Ergebnisse in der Logik.

Ich habe aus diesem Problem die grundsätzliche Frage abgeleitet:

• Sollte eine Logik "zu Ende" laufen, auch wenn sich während des Processing die Eingangssituation ändert
• oder sollte man das Processing abbrechen und neu rechnen

Darüber hab ich jetzt nachgedacht und beschlossen, dass das aktuelle Verfahren mit Ein-/Ausschaltverzögerung besser ist, da man damit selber (über die Dauer der Verzögerung) bestimmen kann, wie lange man auf ein neues Eingangssignal warten will, bevor das Ergebnis ausgegeben wird bzw. ob das Ergebnis trotzdem ausgegeben werden soll.

Man muss es eben nur machen (also sich darüber Gedanken zu machen und es entsprechend einstellen).

Gruß, Waldemar

[Marino]

Nun komme ich auch zum Antworten.

Vielen lieben Dank nochmal an Waldemar, dass Du Dir die Zeit genommen hast und mit mir die auf Fehlersuche gegangen bist.

Zum allgemeinen Ablauf, was wir herausgefunden haben, hast Du ja bereits ausführlich zu geschrieben. Was die Problematik des Timings natürlich noch verschärft hatte, ist die Darstellung in einer Visu. Ich hatte, um es einfach nachvollziehen zu können, die entsprechenden GA's in einer Visu dargestellt, damit ich direkt die Zustände verfolgen konnte. Ansich keine schlechte Idee, aber die Visu verzögerte die Anzeige noch mehr, weshalb es sogar noch schlimmer wirkte, als es eigentlich war.

Die Logik hilft natürlich echt gut weiter, da man durch die Verzögerung das ganze so hin bekommt, wie es auch sein sollte. Das ist mit anderen Logiken in KNX-Modulen halt so nicht möglich. Bisher hatte ich mir darum auch weniger Gedanken gemacht. Ein einfaches logisches ODER, so dachte ich, sollte doch wohl auch so funktionieren, wie erwartet. Da habe ich aber anscheinend zu wenig daran gedacht, wo die Signale her kommen. Vom Steinel TPM.

Ich bin natürlich auch froh, dass in der Software selbst kein Fehler ist. Dafür geht Waldemar in meinen Augen auch zu zu akribisch an die Sache heran und bedenkt sicher schon bei der Entwicklung an so einiges, was viele gar nicht auf dem Zettel haben.

Zusätzlich hierzu konnten wir beide sogar noch etwas lernen und zwar, wie genau man im Gruppenmonitor die Ausgabe direkt auf spezifische GA's filtern kann.

In Zukunft weiß ich sicher eher, wie und wo ich suchen sollte und worauf im Vorfeld schon geachtet werden muss, damit alles fehlerfrei funktioniert.

Vielen lieben Dank also noch einmal, Waldemar! Es ist nicht selbstverständlich, dass man sich dafür Zeit nimmt, um Fehler zu finden und Zusammenhänge zu erklären!

Für mich habe ich gelernt, dass ich nun vor Erstellung der Logiken an einigen Stellen genauer nachschauen muss. Das Soll-Verhalten entspricht halt leider nicht immer dem Ist-Verhalten, vor allem bei Steinel. Meine Steinel erkennen mich seit 1-2 Wochen inzwischen erst mit bis zu 8s Verzögerung. War vorher definitiv anders.

Und natürlich auch vielen Dank an alle anderen, die an dem Projekt mitgewirkt, mir hier geholfen haben und Ing-Dom für die tolle Hardware.


Viele Grüße
Nils

[TabSel]

…wie … man im Gruppenmonitor die Ausgabe direkt auf spezifische GA's filtern kann. …

erzähl!

[Marino]

ETS 5.7.7

• Du gehst in den Gruppenmonitor und dort oben auf "Optionen".
• Nun gehst Du links auf "Bedingungen" und drückst auf "+" und vergibst einen Namen
• Hier wählst Du "ODER" oben aus und hier gibst Du deine GA's an. Bis zu 5 sind möglich
  • Eigenschaft: Zieladresse
  • Operator: ==
  • Wert: Die GA, also z.B. "11/0/48" (ohne " " natürlich)
• Dann zurück zu "Allgemein"
• Bei "Capture Filter Bedingung" wählst Du dann die erstellte Bedingung aus und bestätigst mit "OK"

Drückst Du anschließend Start, siehst Du nur die GA's aus Deiner Bedingung.
WICHTIG: Am Ende nicht vergessen, das wieder auszuschalten! Also als Bedingung "keine" wählen.

ETS 6.0.6:
Sieht genauso aus, also kann das wohl direkt bei beiden Versionen genutzt werden. Wir haben es mit v5.7.7 gemacht.


Kann sicher mal nützlich sein.


Viele Grüße
Nils

[Marino]

Hier einmal stümperhaft mit Bildern.