MDT Logikmodul: 4-Bit-Wert (small) senden

[Cybso]

Moin, ist es irgendwie möglich, mit dem MDT Logikmodul (.02) einen 4-Bit-Wert zum relativen Dimmen zu senden? Ein Byte-Wert scheint vom Aktor (MDT AKD) nicht akzeptiert zu werden.

Ping hjk

[hari2]

Dass der AKD keinen Byte Wert fuer absolutes Dimmen akzeptiert kann ich mir kaum vorstellen. Schau Dir die KOs nochmal ganz genau an.

[vento66]

Er will relativ dimmen...... Schau Dir die Frage noch mal ganz genau an.

[Cybso]

vento66 liegt richtig, ich will quasi Start-Stop für relatives Dimmen implementieren (der 1. Tastendruck startet den Dimmvorgang, der 2. stoppt ihn wieder), aber das scheint nicht umsetzbar zu sein. Dafür bräuchte ich ein Device, welches einen beliebigen DPT 3-Wert auf Kommando senden kann, und das scheint es in meiner Installation nicht zu geben.

Bliebe noch die Option, das per IP und Software zu implementieren, aber elementare Funktionen wie die Lichtsteuerung will ich nicht von einem externen Server abhängig machen.

[hjk]

Ein 4-Bit-Wert wird als normales Byte gesendet. Man kann daher auch einen normalen Bytewert benutzen. Lediglich der Inhalt muss stimmen.
Z.B. rel hoch 100% => 0x09. Du kannst die GAs auch verbinden, wenn du die Warnung der ETS ignorierst. Rel runter ist 0x01 und stopp 0x00.

[Cybso]

Ein 4-Bit-Wert wird als normales Byte gesendet. Man kann daher auch einen normalen Bytewert benutzen. Lediglich der Inhalt muss stimmen.
Z.B. rel hoch 100% => 0x09. Du kannst die GAs auch verbinden, wenn du die Warnung der ETS ignorierst. Rel runter ist 0x01 und stopp 0x00

Hm ich wusste gar nicht, dass man die Warnung ignorieren kann, bei meinem Test hatte die ETS immer gleich den Typ der GA ändern wollen. Deswegen habe ich es mir knxtool getestet, mit "groupswrite" (small = 4 bit) 01 und 09 hat es funktioniert, ein komplettes Byte mit "groupwrite" hatte beim Aktor dagegen keine Wirkung. Aber dann schaue ich mir das morgen noch einmal genauer an. Vielleicht klappt's ja doch, wie ich mir das vorgestellt habe :-)

[gbglace]

Aber schön ist es nicht inkonsistente DPT GA/KO Kombinationen im Projekt zu haben.

[Cybso]

Ein 4-Bit-Wert wird als normales Byte gesendet. Man kann daher auch einen normalen Bytewert benutzen. Lediglich der Inhalt muss stimmen.
Z.B. rel hoch 100% => 0x09. Du kannst die GAs auch verbinden, wenn du die Warnung der ETS ignorierst. Rel runter ist 0x01 und stopp 0x00.

Ich wollte es gerade probieren, aber es kommt keine ignorierbare Warnung, sondern ein Fehler, wenn ich versuche, eine 4-Bit-Adresse an ein 1-Byte-KO zu hängen. Das selbe passiert, wenn ich umgekehrt versuche, eine 1-Byte-Adresse mit dem 4-Bit-KO zum relativen Dimmen zu verbinden.

Wie ist denn der Trick, um eigentlich miteinander inkompatible KOs trotzdem miteinander zu verknüpfen?

Allerdings bin ich mir auch nicht sicher, ob diese Aussage hier überhaupt korrekt ist:

Ein 4-Bit-Wert wird als normales Byte gesendet

Denn ein 4-Bit-Wert ist auf dem Bus 9 Bytes lang und der Wert in den Kopfdaten eingebettet, während ein 8-Bit-Wert als zusätzliches Byte am Ende angehängt wird:

knxtool groupswrite local:/var/lib/knxd/eib 9/0/0 09 -> BC 00 04 48 00 E1 00 89 67
knxtool groupwrite local:/var/lib/knxd/eib 9/0/0 09 -> BC 00 07 48 00 E2 00 80 09 67

Letzteres wird vom AKD-0201.02 komplett ignoriert, egal ob 00, 01, 09 oder ff. Es scheint also nicht nur so zu sein, dass nur der Wert im 8. Byte ausgewertet wird, sondern dass ein längeres Telegram sogar komplett ignoriert wird, denn andernfalls müsste zumindest 00 funktionieren und als "Dimmen Stop" gewertet werden - das ist aber leider auch nicht der Fall.

hjk Wenn ich euch ein Feature vorschlagen darf: die Single-Object-Control bei den Jalousien ist super-intuitiv für den Benutzer. Nicht, weil es nur mit einem Objekt auskommt, sondern weil man nicht mit langen Tastendrücken hantieren muss, um eine bestimmte Position anzufahren. Um das sauber zu implementieren müsste der Dimmer dazu allerdings auch mitteilen können, ob gerade ein Dimmprozess aktiv ist oder nicht, sonst wird das ein ähnlich dreckiges Logik-Gefrickel wie das, was ich hier versucht habe :-)




2021-09-23_09-00.png
2021-09-23_09-03.png

[Beleuchtfix]

SOC kann dir aber das Leben schwer machen, wenn du noch weitere Zentralsteuerung, da musst du sehr aufpassen. Die Bedienung am Schalter ist dafür sehr intuitiv.
Gruß Florian

[Cybso]

SOC kann dir aber das Leben schwer machen, wenn du noch weitere Zentralsteuerung, da musst du sehr aufpassen

Hm in wie fern? Die Zentralsteuerung läuft bei mir über klassische Objekte, und das funktioniert alles sehr gut. Die wird aber auch nur selten manuell ausgelöst, normalerweise macht das ja die Zeitsteuerung.

[hjk]

Funktioniert tatsächlich nicht. Hatte erwartet, dass das geht.

[Cybso]

Funktioniert tatsächlich nicht. Hatte erwartet, dass das geht.

Direkt ein Ticket in der Firmwareentwicklung einstellen

[willisurf]

Um das sauber zu implementieren müsste der Dimmer dazu allerdings auch mitteilen können, ob gerade ein Dimmprozess aktiv ist oder nicht, sonst wird das ein ähnlich dreckiges Logik-Gefrickel wie das, was ich hier versucht habe :-)

Könntest Du kurz erläutern, wie sich das Problem ohne die Rückmeldung „Dimmprozess aktiv“ darstellt?

[Cybso]

Könntest Du kurz erläutern, wie sich das Problem ohne die Rückmeldung „Dimmprozess aktiv“ darstellt?

Das hängt davon ab, wie ein solcher Prozess implementiert wird.

Wenn es nur im Taster implementiert wird:

- Der Taster sendet beim ersten Tastendruck 0x9 um das Licht hoch zu dimmen.
- Beim zweiten Tastendruck sendet er 0x0, um das Dimmen zu stoppen

Wenn das Dimmen nicht gestoppt wurde und bis zum Ende durchlief, ist der zweite Tastendruck jedoch ohne Funktion. Ohne eine Rückmeldung durch den Dimmer wüsste der Taster nicht, dass er nun wieder eine 0x9 senden muss und keine 0x0. In meiner Logik wollte ich das über den Dimmwert (0 bzw 100%) steuern, das funktioniert dann aber auch nur, wenn keine Limits im Aktor definiert sind.

Anders wäre es, wenn die Funktion analog zum Single-Object-Control des Jalousieaktors im AKD implementiert wird. Dann wäre keine Rückmeldung erforderlich, der Taster würde zum Hochdimmen immer eine 0x09 (als Byte) senden, und der Dimmer würde selber merken, dass er diese zweite 0x09 nun als "Stopp" interpretieren müsste. Das wäre tatsächlich die schönere Variante, weil sie nur im Dimmer implementiert werden müsste und auch mit Tastern anderer Hersteller kompatibel wäre, solange sie Werte senden können. Oder man macht es sogar als Bit-Objekte, das müsste dann auch funktionieren, weil es ja keine 0 zum Stoppen mehr bräuchte.