Einzelnen Beitrag anzeigen
  #8  
Alt 03.01.2013, 00:01
Alex Alex ist offline
Benutzer
 
Registriert seit: 19.11.2008
Ort: Gaggenau
Beiträge: 22
Alex ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Hi Niko

Zitat von 2ndsky Beitrag anzeigen
Okay, Problem verstanden. Kann der Tastsensor auch Byte Werte im 2 Kanal Betrieb versenden? Denn du müsstest sonst ja nur bei kurzem Tastendruck den entsprechenden Bytewert im richtigen Format versenden. Sprich den Wert 1 dezimal für VolumeDown und den Wert 9 dezimal für VolumeUp als ein Byte Wert.
Das ist ja eine verwegene / trickreiche Idee :-)

Ja, der Tastsensor kann im 2-Kanal-Betrieb tatsächlich auch fest eingetragene 1-Byte-Werte verschicken. Den Kommunikationsobjekten kann ich als Typ in der ETS allerdings nur DPT-5 (und einige andere), jedoch kein DPT-3 zuweisen bzw. entsprechende DPT-3-GAs verknüpfen.

Verwende ich eine solche DPT-5-GA in SmartHome.py ('type = foo, knx_dpt = 3'), funktioniert die Bedienung, wie von mir gewünscht.

An dieser Lösung finde ich aber zumindest unschön, dass aus Sicht der ETS (und aller anderen Anwendungen, die ich im KNX-Umfeld habe und die die ETS-Daten verwenden) diese GA als DPT-5.x angesehen wird und dieselbe GA in SmartHome.py als DPT-3 interpretiert wird und man aus Sicht der anderen Anwendungen wissen muss, dass diese GA als DPT-3 interpretiert wird und als Werte 9 und 1 zu schreiben ist. (Ist so eine Vorgehensweise üblich/weit verbreitet?) Klar funktioniert diese Konstruktion, da DPT-3 und 5 letztlich dieselbe Telegrammgröße besitzen und mit dem Wissen, wie DPT-3 codiert ist, ergibt sich auch der Wert, der in DPT-5 zu schreiben ist. Aber ist das auch wartbar/verständlich?

Was mich auch nicht so recht überzeugen möchte, dass Lautstärke einen Schritt erhöhen/verringern nur über das "volumerelative" zu erreichen sein soll, ist folgendes: Als Typ für "volumerelative" muss "foo" parametriert werden und zum Auslösen einer relativen Lautstärkeänderung aus einer Logik heraus muss eine Liste [1,1] oder [0,1] an das Item übergeben werden: "sh.eg.az.audio.riorelativevolume([x, 1]" (mit x = 0 oder 1). Das ist nach meinem Empfinden doch sehr KNX-Datentypen-lastig für das Russound-Plugin.

Hmm, so ich Dich von der 'Sinnhaftigkeit' meines Erweiterungswunsches (drei Zeilen) nicht überzeugen konnte, werde ich noch ein wenig in mich gehen und mir dann überlegen, welchen Weg ich weiter verfolgen werde...

Ich danke Dir auf jeden Fall, für diesen weiteren Lösungsvorschlag.

Klar kannst du mir den Code per Mail ...schicken.
Ok, dann werde ich bis zum WE den Code noch etwas aufbereiten und kommentieren und Dir dann zuschicken...

Viele Grüße,
Alex
Bei Google nach dem markiertem Wort suchen Bei Wikipedia nach dem markiertem Wort suchen Im Forum nach dem markiertem Wort suchen
Mit Zitat antworten