Telegrammvervielfältigung

[hatamoto]

Hallo,

folgende Ausgangslage:
fhem,knxd, TUL-Stick und MDT IP Router

knxd läuft und ist in fhem eingebunden.
Ich habe wahlweise den TUL-Stick und den MDT Router verbunden.
Das Senden/Empfangen von fhem auf den KNX-Bus und umgekehrt funktioniert soweit auch.

Mir ist jedoch im Gruppenmonitor aufgefallen, dass Telegramme von fhem vervielfältigt werden.
Beim ein- und ausschalten eines Aktors macht das erstmal nicht aus.

Jedoch sind die Rollladenaktoren (ebenfalls von MDT) so konfiguriert, dass durch das nochmalige Drücken/Senden gestoppt wird (Single Object Control).
Dies hat nun zur Folge, dass ich die Rollläden nicht von fhem aus ansteuern kann (zumindest nicht auf/ab), da jeder Fahrbefehl durch das Folgetelegramm wieder gestoppt wird.

Wie muss ich knxd korrekt konfigurieren, um diese Doppelung zu verhindern?

Vielen Dank
Chris

[Smurf]

Wie muss ich knxd korrekt konfigurieren, um diese Doppelung zu verhindern?

Gar nicht. KNXD verdoppelt keine Pakete. Das muss an irgendwas Anderem liegen.

Du kannst doppelte Pakete grundsätzlich nicht verhindern, weil immer mal eine Quittungsnachricht kaputtgehen oder zu spät kommen kann.

Abgesehen davon kennt das KNX-Protokoll grundsätzlich keine Umschaltbefehle. Es gibt nur AN oder AUS, der Absender muss auf den Status des Empfängers lauschen und daraufhin beim nächsten Schalten das andere Paket schicken. Wenn der MDT tatsächlich auf einen AN-Befehl abwechselnd mit "losfahren" und "stoppen" reagiert, ohne sich auch nur im Entferntesten dafür zu interessieren ob dazwischen ein AUS kommt, dann ist das ein Fehler im MDT.

Mal ganz naiv gefragt: wozu braucht man so einen Blödsinn überhaupt? In meiner Welt heißt "AN" dass der Rollo losfährt und AUS dass er anhält. Alles Andere ist Quatsch. Um das umzustellen, muss man natürlich den Rollotaster entsprechend umprogrammieren, so dass er tatsächlich als Umschalttaster arbeitet und nicht als Schalter – wenn man wirklich nicht will dass der Rollo nur solange fährt, wie man die Taste drückt.

[Gast1961]

In meiner Welt heißt "AN" dass der Rollo losfährt und AUS dass er anhält. Alles Andere ist Quatsch.

Das entspricht aber nicht der Festlegung in KNX.

[Smurf]

Sondern?

Ernsthaft: nenne mir einen Datentyp auf dem Bus, dessen Zweck es ist, einen Zustand zu toggeln. Überraschung: es gibt keinen. Aus Gründen.

[MatthiasS]

meiner Welt heißt "AN" dass der Rollo losfährt und AUS dass er anhält. Alles Andere ist Quatsch.

In meiner Welt fährt der Rollo mit 1 = AN nach unten, mit 0 = Aus nach oben. Alles andere ist Quatsch.
Für Stop gibt es ein zweites Objekt.

[Smurf]

Es ist für das Prinzip egal, ob es ein Objekt für Rauf und eines für Runter gibt, oder eines für die Richtung und eines ob Fahren oder nicht. Es ist auch egal ob das Rollo beim Einstellen der Richtung zusätzlich losfährt oder nicht, und es ist auch egal ob im Stoptelegramm AN oder AUS drinstehen muss und/oder ob das Stopobjekt auch Weiterfahren beinhaltet.

Aber: es kann nicht sein, dass der Rollo beim erneuten Senden eines Telegramms mit identischem Inhalt, egal welches, was Anderes tut als beim Empfang des ersten. (Solange dazwischen keine anderen Telegramme auf dem Bus waren, d.h. start/stop/start kann im Single Object Control-Modus impliziten Richtungswechsel bedeuten.) Das ist meine Aussage. Nicht mehr und nicht weniger.

[MatthiasS]

Das ist allerdings richtig.

[Gast1961]

Aber: es kann nicht sein, dass der Rollo beim erneuten Senden eines Telegramms mit identischem Inhalt, egal welches, was Anderes tut als beim Empfang des ersten.

Meiner Interpretation nach macht das in der Ausgangsfrage genannte "Single Object Control" bei diesem Aktor genau das.

Schau mal hier auf Seite 35:
https://www.mdt.de/download/MDT_THB_...ieaktor_02.pdf

singleobject.jpg

[hjk]

Das ist eine Sonderfunktion, die genau das macht. Natürlich dürfen keine Telegrammwiederholungen kommen. Die müssen weg oder die Sonderfunktion muss abgestellt werden. In der Standardeinstellung ist diese Funktion nicht aktiv.
Mit der Sonderfunktion ist es möglich mit einem Taster einen Rollladen (Taste kurz) und eine Gruppe (Taste lang 1-2s) zu steuern.
Macht man aber nur, wenn man keine andere Lösung hat.

[hatamoto]

Vielen Dank für die Rückmeldungen.
Grundsätzlich habt Ihr auch alle Recht.

Aus meiner Sicht macht diese Funktion total sinn.
Ich habe einen Taster mit Auf und Ab.
Durch einmaliges Drücken fährt der Rollladen los, bis zum Endpunkt (quasi "fire and forget"). Ich muss also nicht da bleiben und die Taste halten.
Möchte ich nun die Fahrt stoppen, drücke ich nochmals und der Rollladen ist aus.

Natürlich gibt es ein extra Stop Objekt, jedoch brauche ich dafür ja auch eine weitere Taste.

Oder habe ich hier grundsätzlich einen Denkfehler?


Unabhängig davon, ist jedoch die Frage, woher die zusätzlichen Telegramme auf dem Bus kommen?
Ich muss zugeben, dass ich knxd noch immer nicht richtig verstanden habe.

Gerade ist mir aufgefallen, dass ich von fhem aus zwar schalten kann, jedoch bekomme ich keine Statuswerte vom Bus zurück?
Bin etwas ratlos...

[squeezer]

Natürlich gibt es ein extra Stop Objekt, jedoch brauche ich dafür ja auch eine weitere Taste.

Habe nirgendwo wirklich gelesen welchen Taster oder Binär Eingang Du verwendest.... denn darauf kommt es an.

Beispielsweise können die MDT Binäreingange, gerne auch UP, als Rollladen Eingang! für einen Taster parametriert werden. Womit dann für Lange Events ein weiteres KO getriggert wird.

Ohne es 100% zu wissen, sollten jedoch lange Events zur Steuerung eines zweitens KOs auch andere Hersteller beherrschen...

[Smurf]

Du kannst die fire-and-forget-Funktion auch ohne diesen Unfug nachbauen. Du programmierst die Taster als Umschalter, empfängst die Schaltbefehle nur(!) in FHEM, und sendest dazu passende Richtung- und StartStop-Nachrichten an den Aktor. Umgekehrt musst du natürlich die Statusmeldungen des Aktors in Nachrichten an die beiden Statusobjekte der Tasten umsetzen, damit die beim nächsten Drücken den richtigen, d.h. entgegengesetzten, Befehl schicken.

Ja, das ist ein bisschen nervig, aber wenn dein Aktor keine alternative Steuerung mit auf/stop und zu/stop-Objekten anbietet, und dein Taster sich nicht darauf einlässt die beiden Tasten zu einer "Standard"-Rollosteuerung zu kombinieren, geht es halt nicht anders.

Ja, irgendjemand dupliziert diese Befehle und es ist nicht der knxd. Dessen Job ist es, seine Schnittstellen sauber auseinanderzuhalten und Nachrichten von A an BCDE weiterzureichen, aber garantiert nicht wieder zurück an A zu schicken. Um dein Problem zu finden, musst du das Logging im knxd einschalten, und zwar für jeden Kanal separat, d.h. zum Beispiel

knxd -e BLA -E FASEL -c -B log -T -B log -R -DS -B log -b ipt:10.11.12.13 -B log -u /tmp/knx

Du wirst aber mit deiner jetztigen Methode langfristig nicht glücklich werden. Erstens weil du bei Übertragungsfehlern nie weißt was Sache ist, zweitens weil solche Krücken bei fortschreitender Automatisierung weitere Krücken nach sich ziehen.

[Gast1961]

Aus meiner Sicht macht diese Funktion total sinn.
Ich habe einen Taster mit Auf und Ab.
Durch einmaliges Drücken fährt der Rollladen los, bis zum Endpunkt (quasi "fire and forget"). Ich muss also nicht da bleiben und die Taste halten.
Möchte ich nun die Fahrt stoppen, drücke ich nochmals und der Rollladen ist aus.

Du beschreibst aber das normale Standardverhalten eines KNX Tasters, der Rolläden ansteuert. Der kann das auch ohne ""single object control", welches dir Probleme macht. Hast du das vielleicht falsch verstanden?

Normal und problemlos wäre es, wenn man den Taster auf Rolladenbetrieb stellt und die nötigen zwei (!) KO mit dem Aktor verbindet. Der Taster weiß selbst, wie es das Stop auf das zweite KO senden muß. Für den Anwender ergibt sich genau das von dir gewünschte Verhalten: Nochmal drücken stoppt. Ganz ohne Tricks.

[Smurf]

wenn man den Taster auf Rolladenbetrieb stellt

So er das mit den zwei Tasten wie gewünscht kann. Bei manchen Tastern schließen sich Extrafunktion-mit-lang-drücken und Rollobetrieb gegenseitig aus. Dann hilft wirklich nur die FHEM-Methode. (Oder Home Assistant oder OpenHAB oder ein bisschen Code mit pyknyx oder oder oder.)

[squeezer]

Dann hilft wirklich nur die FHEM-Methode. (Oder Home Assistant oder OpenHAB oder ein bisschen Code mit pyknyx oder oder oder.)

...oder ein neuer Taster