Russound C3/C5 RIO over TCP Plugin

[2ndsky]

Hallo Kollegen,

vor einer Woche habe ich ein neues Plugin ins Git Repo gepushed mit dem man Russound C3 und C5 (evtl. auch andere) mittels RIO über TCP steuern kann. ACHTUNG: Das Plugin ist bisher nur im Repo und noch nicht in der aktuellen Version. Wer es also nutzen möchte muss das Repo mittels git clonen.

Bisher lassen sich damit die Einstellungen jeder Zone steuern:

• Zone an-/ausschalten
• Lautstärke
• Bass
• Höhen
• Balance
• Lautstärke beim Einschalten
• Loudness
• Quellenwahl
• Stummschaltung
• Party Mode
• Do not disturb

Das steuern des internen Tuners steht noch auf meiner TODO Liste.

Das Problem bei der Steuerung über TCP, der Russound unterbricht die Verbindung wenn mehr als 2 Stunden keine Kommunikation statt gefunden hat und alle Zonen aus sind. Diese Unterbrechung wird von smarthome.py detektiert und die Verbindung neu aufgebaut. Diese hält dann weitere 2 Stunden usw. usf. Ich hatte das jetzt eine Woche im Testlauf und hat wunderbar funktioniert. Es gab keinerlei spürbare Verzögerungen beim Ein-/Ausschalten oder bei der Lautstärke usw.

Die Konfiguration erfolgt im smarthome.py typischen Stil und kann hier eingesehen werden: SmartHome.py - Russound Plugin
Es gibt zwar keinen schönen Zonengenerator der die Konfig und ETS Gruppenadressen anlegt (sollte aber auch kein Problem sein das zu hacken), allerdings reicht es, die Konfiguration für eine Zone anzulegen (sowohl in smarthome.py als auch in der ETS) und dann nur noch für die weiteren Zonen zu kopieren. Vorteil hierbei, man muss sich nicht an ein vorgegebenes Schema halten sondern kann die Adressen vergeben wie man lustig ist.

Über Kommentare und Feedback würde ich mich freuen.
Und nun viel Spass damit!

[2ndsky]

Hier mal ein kleines Update. Heute habe ich das "Dimmen" der Lautstärke hinzugefügt. Dadurch kann man jetzt eine Wippe eines Tastsensors als "Dimmer" konfigurieren. Mit kurzem Tastendruck Zone ein- und ausschalten und bei längerem Druck die Lautstärke erhöhen bzw. verringern.

Einfach das Schalten auf den "rus_path=c.z.power" legen und die GA für's relative Dimmen auf "rus_path=c.z.relativevolume" (c durch Controllernummer und z durch Zonennummer ersetzen). Nähres auf der smarthome.py Projektpage.

[2ndsky]

Hier mal ein kleiner Statusbericht. Ich bin zwar glaub der einzige hier, der das Plugin wirklich einsetzt, aber dennoch. Anfangs hatte ich Probleme, wenn über einen Zeitraum von etwa acht Stunden keine Zone aktiviert wurde. Da hat sich der Russound komplett aufgehängt und man konnte ihn nur noch aus- und wieder anschalten. Ich habe dann die neuste Firmware aufgespielt (6.irgendwas). Seit dem schnurrt das Kätzchen brav und hängt sich nicht mehr auf.

Ansonsten läuft das ganze wirklich super zufriedenstellend. In einer Testzone (Technik und Abstellraum) habe ich die Musikwiedergabe mit dem BWM verknüpft. Die Wiedergabe beginnt sofort beim Betreten, es gibt keinerlei Verzögerung. Im Elternbad liegt die Wiedergabe auf einem Tastsensor mit AN und AUS sowie Lautstärke verändern bei langem Tastendruck. Das klappt auch super. Weder bei AN/AUS noch beim Ändern der Lautstärke gibt es einen spürbaren Lag. Änderungen die über die Russound App auf dem iPhone gemacht werden, werden sofort von smarthome.py registriert. Alles in allem läuft das wirklich sehr flüssig und ganz ohne jeglichen Moxa oder RS232 Gedöns.

Falls jemand von euch das Plugin verwendet, würde ich mich über einen kurzen Erfahrungsbericht freuen.

[Alex]

Hallo Niko

Hier mal ein kleiner Statusbericht. Ich bin zwar glaub der einzige hier, der das Plugin wirklich einsetzt, ...

Nicht mehr :-)

Falls jemand von euch das Plugin verwendet, würde ich mich über einen kurzen Erfahrungsbericht freuen.

Da ich ein paar (zu unterschiedlichen Zeitpunkten in den letzten Jahren entstandene) Provisorien beseitigen und 'unter ein gemeinsames Dach' bringen möchte, beschäftige ich mich seit wenigen Tagen mit SmartHome.py. Eines dieser Provisorien war ein von mir auf die Schnelle zusammen gehacktes C++-Progrämmchen, welches eine Abbildung RIO <-> KNX macht (ähnlich Makkis russconnectd für RNet <-> KNX).

Also habe ich dieser Tage SmartHome.py installiert und mit Deinem russound-Plugin experimentiert und bin begeistert! Wie Du oben geschrieben hast: Einschalten der Zonen per KNX-PM oder Taster, wie auch weitere Funktionen wie Mute, Lautstärkeänderungen, wechseln der Quelle, etc., funktionieren einwandfrei und ohne spürbaren Verzögerungen.

Vielen Dank also, für das tolle Plugin!

Welche Werte für das von Dir kürzlich eingeführte "relativevolume" zu verwenden sind, habe ich allerdings auf der Home-Page SmartHome.py - Russound Plugin nicht beschrieben gefunden. Erst das Stichwort "Dimmer" weiter oben, haben mich auf die Spur geführt, wie "relativevolume" wohl anzuwenden (foo, dpt 3) ist.

Leider sind meine Taster anders belegt: Um die Lautstärke relativ um einen Schritt zu ändern, würde ich gerne ein DPT 1 (bool) verwenden. Ich würde also gerne bei jedem KNX-Telegramm mit Wert X ein RIO Kommando "KeyPress VolumeUp" und bei jedem Wert !X ein "KeyPress VolumeDown" verschicken.

Ob die Belegung (also die KNX-Werte) nach DPT 1.007 "DPT_Step" mit 0 = Decrease und 1 = Increase oder nach DPT 1.008 "DPT_UpDown" mit 0 = Up und 1 = Down (leider genau gegensätzlich) erfolgt, wäre mir egal.

Natürlich könnte ich dies auch mit zwei Items pro Zone und ein wenig Logik hinbekommen:

Items:

['eg']
   ['az']
     ['audio']
       [[[['knxrelativevolume']]]]
         type            = bool
         enforce_updates = On
         knx_dpt         = 1
         knx_listen      = 10/1/22

       [[[['riorelativevolume']]]]
         type            = foo
         enforce_updates = On
         rus_path        = 1.1.relativevolume

logic.conf:

[RioVolRelAZ]
  filename   = rio_volrel_az.py
  watch_item = eg.az.audio.knxrelativevolume

logics/rio_volrel_az.py:

#!/usr/bin/env python

if not sh.eg.az.audio.knxrelativevolume():
       sh.eg.az.audio.riorelativevolume([1, 1])

if     sh.eg.az.audio.knxrelativevolume():
       sh.eg.az.audio.riorelativevolume([0, 1])

Daran gefällt mir aber nicht so recht, dass ich für die relative Lautstärke-Steuerung für 8 Zonen dann 2*8 Items, 8 Logic-Einträge und 8 Logic-Scripte benötige.

Hieltest Du es für sinnvoll/möglich, das Russound-Plugin so zu erweiteren, dass es ein neues Attribut (nennen wir es mal 'relativevolumebool') gibt, das direkt mit einem KNX-DPT1 verküpft werden kann und bei KNX Wert 1 "KeyPress VolumeUp" und bei jedem Wert 0 ein "KeyPress VolumeDown" verschickt (oder eben umgekehrt)?

Die Änderungen im Plugin-Source wären wohl eher gering, vielleicht etwa so:

diff --git a/plugins/russound/__init__.py b/plugins/russound/__init__.py
index 0fd16fb..ec490bc 100755
--- a/plugins/russound/__init__.py
+++ b/plugins/russound/__init__.py
@@ -74,7 +74,7 @@ class Russound(lib.my_asynchat.AsynChat):
                 logger.warning("No parameter specified for zone {0} on controller {1} in config of item {2}".format(z,c,item))
                 return None
 
-            if param == 'relativevolume':
+            if param == 'relativevolume' or param == 'relativevolumebool':
                 item._enforce_updates = True
 
             item.conf['rus_path'] = path
@@ -118,6 +118,8 @@ class Russound(lib.my_asynchat.AsynChat):
                 self.send_event(c, z, 'SelectSource', item())
             elif cmd == 'mute':
                 self.send_event(c, z, 'KeyRelease', 'Mute')
+            elif cmd == 'relativevolumebool':
+                self.send_event(c, z, 'KeyPress', 'VolumeDown' if item() else 'VolumeUp')
             elif cmd == 'relativevolume' and item()[1] != 0:
                 if item()[0] == 1:
                     self.send_event(c, z, 'KeyPress', 'VolumeUp')

Damit käme ich komplett ohne Einträge in logic.conf und logic/*.py-Scripte aus und könnte einfach pro Zone folgendes schreiben:

['eg']
  [['az']]
    [[['audio']]]
      [[[['relativevolume']]]]
        type            = bool
        enforce_updates = On
        knx_dpt         = 1
        knx_listen      = 10/1/22
        rus_path        = 1.1.relativevolumebool

Was meinst Du dazu?

Das steuern des internen Tuners steht noch auf meiner TODO Liste.

Hast Du in der Richtung schon etwas gemacht?

Wobei mich mehr als die Steuerung des Tuners der Empfang der Status-Nachrichten von den Quellen interessieren würde - insbesondere vom internen Tuner (also "WATCH S[1] ON'). Die anderen Quellen liefern bei mir sowieso nur die beiden Attribute "NAME" und "TYPE" (logisch, wenn an diesen Quellen nur Line-In Signale verwendet werden und nicht etwa andere Russound-Geräte).

Zugegebenermaßen habe ich in diese Richtung ein wenig in Deinem Plugin herumgebastelt und es funktioniert auch schon ganz ordentlich. Ich hadere allerdings noch ein wenig mit der Zeichencodierung der empfangenen Texte in "radioText" (und auch mit den Namen der Zonen). Ich sollte mich also wohl eher mal hinsetzen und mir ein wenig Python-Grundlagenwissen aneignen, bevor ich hierzu vorzeigbaren Code produzieren kann...

Viele Grüße,
Alex

[2ndsky]

Hallo Alex,

freut mich, dass das Plugin bei dir so gut funktioniert.

Wegen der relativen Lautstärke würden mich deine Tastervinteressieren. Der Umbau wäre zwar kein Problem, aber so wie es jetzt gemacht wird ist es dasselbe Verhalten wie beim Dimmen von Leuchten. Das sollte eigentlich jeder Taster können.

Bei der Steuerung des Tuners bin ich noch nicht weiter, da ich es eigentlich nicht brauche (wir hören nur einen Sender). Kann mir das aber gerne nächste Woche ansehen, da habe ich Urlaub und meine bessere Hälfte muss arbeiten
Wenn du bereits funktionierenden Code hast, poste diesen doch bitte, dann muss ich nicht bei Null anfangen.

[Alex]

Hallo Nico

Wegen der relativen Lautstärke würden mich deine Tastervinteressieren. Der Umbau wäre zwar kein Problem, aber so wie es jetzt gemacht wird ist es dasselbe Verhalten wie beim Dimmen von Leuchten. Das sollte eigentlich jeder Taster können.

Bei den Tastern handelt es sich um Jung RCD3096 und natürlich könnte bei diesen eine Wippe auch als Dimmer konfiguriert werden.

Ich bevorzuge aber folgende Bedienung der Tasten: Die 'naheliegende' - also häufiger benötigte - Funktion möchte ich mit einem kurzen Tastendruck erreichen und die nicht ganz so häufig benötigte Funktion mit einem langen Tastendruck.

'Häufig' möchte ich die Lautstärke ändern, 'selten' händisch ein-/ausschalten (hierfür ist der BM bzw. die Szenen zuständig) oder die Quelle wechseln.

Also sieht mein Anwendungsszenario so aus:

• kurzer Druck oben: Lautstärke eine Stufe höher
• kurzer Druck unten: Lautstärke eine Stufe geringer
• langer Druck oben: ein-/ausschalten
• langer Druck unten: zur nächsten Quelle umschalten (round robin)

Daher habe ich die Tastenwippe so konfigiert: Oben und unten "als separate Tasten", jeweils mit "2-Kanal-Bedienung":

• oben/kurz verschickt die "Volume-Relative"-GA mit 1-Bit Wert EIN (*)
• oben/lang verschickt die "Power-Switch"-GA mit Umschaltfunktion
• unten/kurz verschickt die "Volume-Relative"-GA mit 1-Bit Wert AUS
• unten/lang verschickt eine "Toggle-Source"-GA mit 1-Bit Wert EIN woraufhin eine kleine Logik (derzeit im EibPC) die Zone des Raums auf die nächste Quelle schaltet (indem eben wiederum ein KNX-Telegramm für die Zone mit der zu aktivierenden Quelle verschickt wird)

(* = der C5 schaltet eine Zone auch ein, wenn er ein VolumeUp erhält, d.h. auch über einen kurzen Tastendruck oben würde die Zone eingeschaltet)

So, wie ich das sehe, würde ich eine solche Tastenbelegung nicht mit einer als "Dimmer" konfigurierten Wippe hinbekommen.

Insofern wäre es schon toll, wenn Du eine relative Lautstärkeänderung auch mit einem 1-Bit-Wert (DPT1) ermöglichen würdest.

Bei der Steuerung des Tuners bin ich noch nicht weiter, da ich es eigentlich nicht brauche (wir hören nur einen Sender).

Wenn ich denn mal Radio laufen habe, ist es häufig auch nur ein Sender. Daher ist mir das Steuern des Tuners nicht so wichtig (das bekomme ich anderweitig hin).

Interessanter finde ich das Empfangen des Radio-Textes, den ich gerne in den Displays der RTR (oder einer Visu) anzeigen würde: programServiceName, channel, radioText, etc.

(Noch häufiger höre ich allerdings MP3s über einen mpd an Quelle 2, dafür fehlt mir aber noch ein Plugin, um vom mpd den Song/Artist zu bekommen )

Kann mir das aber gerne nächste Woche ansehen, da habe ich Urlaub und meine bessere Hälfte muss arbeiten
Wenn du bereits funktionierenden Code hast, poste diesen doch bitte, dann muss ich nicht bei Null anfangen.

Wäre es Dir auch recht, wenn wir uns zunächst einmal per PN oder E-Mail über den Code austauschen würden? Da ich, was Python angeht, noch kompletter Neuling bin und ich noch zwei Probleme sehe (was die Zeichencodierung angeht), würde ich noch nicht vollständig gegengecheckten Source nur ungern öffentlich posten.

Viele Grüße, Alex

[2ndsky]

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.

Klar kannst du mir den Code per Mail an info 'at' nw-software 'dot' com schicken.

[Alex]

Hi Niko

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

[2ndsky]

Hallo Alex,

du hast schon recht. Das mit den ETS Datentypen finde ich zwar nicht unbedingt ungewöhnlich (habe ich auch bei so manchen Applikationen großer Hersteller, das da die DPTs nicht passen oder händisch nachjustiert werden müssen), dennoch macht eib Bool evtl. mehr Sinn. Meinen Fall mit Dimmer könnte ich dann vielleicht mit der sh.py eval Funktion von DPT 3 in DPT 1 umrechnen. Ich schau mir das nächste Woche an und melde gebe dir dann bescheid. Solange kannst du es zumindest mal mit dem Workaround über DPT 5 verwenden.

[Alex]

Hi Niko

du hast schon recht... dennoch macht eib Bool evtl. mehr Sinn... Ich schau mir das nächste Woche an und melde gebe dir dann bescheid.

Prima, das freut mich!

Gute Nacht und vielen Dank nochmals,
Alex

[DK178]

Hallo Niko,

damit es ein paar mehr werden habe ich mich auch mal an dein Plugin gewagt. Funktioniert soweit schon ganz gut, ich kann den Russound einschalten. Allerdings würde ich gerne weiterhin die Cometvisu nutzen dass setzt aber voraus dass ich KNX-Telegramme zur Steuerung sende. Für das einschalten funktioniert das schon ganz gut. Ich verstehe aber leider nicht, welche DPT ich bei den anderen befehlen wie Lautstärke einsetzten muss. Kannst du mir da mal auf die Sprünge helfen?

Anbei noch ein Stück meiner items Konfiguration zum Verständnis:

[['Zone8']]
        [[['audio']]]
            type=bool
            enforce_updates = On
            knx_listen = 10/2/50
            knx_reply = 10/2/70
            knx_dpt = 1                        #funktioniert
            rus_path=1.8.status
            [[[['currentsource']]]]
                type=num
                enforce_updates = On
                knx_listen = 10/2/51
                knx_reply = 10/2/71
                knx_dpt = ???                  # was muss da hin
                rus_path=1.8.currentsource

Wie wird folgendes übersetzt?

• status = bool -> DPT = 1
• volume = num [0..255] -> DPT = ???
• bass = num [-128..127] -> DPT = ???
• treble = num [-128..127] -> DPT = ???
• balance = num [-128..127] -> DPT = ???
• turnonvolume = num [0..255] -> DPT = ???
• source = num -> DPT = ???
• mute = bool -> DPT = 1
• loudness = bool -> DPT = 1
• partymode = string [ON/OFF/MASTER] -> DPT = ???
• donotdisturb = type must be string -> DPT = ??? und was für nen String wird erwartet

Gruß,
David

[Alex]

Hallo David

Hallo Niko,

Ich bin zwar nicht Niko, da ich mich aber derzeit auch mit dem RIO-Plugin beschäftige, versuche ich mich mal mit einem Kommentar: So, wie ich das Typ-Handling in Python/SmartHome.py bisher verstanden habe, würde bei den numerischen Attributen vermutlich jeweils ein DPT passen, der den entsprechenden Wertebereich abdecken kann. Sollte ein DPT mit einem größeren Wertebereich verwendet werden, als die Definition des Attributs vorsieht, musst Du halt darauf achten, nur gültige Werte über die GA zu schicken.

Wie wird folgendes übersetzt?
...

• volume = num [0..255] -> DPT = ???
• turnonvolume = num [0..255] -> DPT = ???

Der Wertebereich legt ein DPT-5 (8-Bit vorzeichenlos) nahe.

• bass = num [-128..127] -> DPT = ???
• treble = num [-128..127] -> DPT = ???
• balance = num [-128..127] -> DPT = ???

Hier suggeriert der Wertebereich IMHO einen DPT-6 (8-Bit vorzeichenbehaftet).

Niko, ich bin an dieser Stelle jedoch etwas unsicher, ob die Abbildung des Wertebereichs [-128..127] auf den Wertebereich [-10..10], den der C5 per RIO erwartet/liefert, korrekt ist.

Aus dem Plugin: RIO-Wert [-10..10] -> Wert laut Plugin-Doku [-128..127]:

    def _decode(self, cmd, value):
        cmd = cmd.lower()

        if cmd == 'bass' or cmd == 'treble' or cmd == 'balance':
            return int(round(float(value) * (128.0 / 10.0)))

Würde der C5 per RIO einen Wert von 10 an das Plugin liefern, so ergäbe sich für das Item m.E. ein Wert von 10 * 128 / 10 = 128 -> Ausserhalb des Wertebereichs.

Das Gegenstück sieht so aus:

    def update_item(self, item, caller=None, source=None):
    ...
            if cmd == 'bass':
                self.send_set(c, z, cmd, int(round(float(item()) / (128.0 / 10.0))))
            elif cmd == 'treble':
                self.send_set(c, z, cmd, int(round(float(item()) / (128.0 / 10.0))))
            elif cmd == 'balance':
                self.send_set(c, z, cmd, int(round(float(item()) / (128.0 / 10.0))))

Wäre es nicht besser, die 128 jeweils durch 127 zu ersetzen und als Wertebereich Item: [-127..127] für RIO: [-10..10] zu definieren?

(Tatsächlich hielte ich einen Attribut-Wertebereich -10..10 oder -100..100 sogar für 'schöner'.)

<Einschub> Ich vermute ausserdem ein Problem in der Kodierung/Dekodierung von DPT-6/DPT-8-Werten / KNX-Telegrammen, weswegen ich bereits eine E-Mail an Marcus geschrieben habe.</Einschub>

• source = num -> DPT = ???

Hier verwende ich ebenfalls ein DPT 5.

• partymode = string [ON/OFF/MASTER] -> DPT = ???
• donotdisturb = type must be string -> DPT = ??? und was für nen String wird erwartet

Verwende ich beides nicht.

HTH, Alex

[2ndsky]

Hallo,

numerische Werte die nur positiv sind (wie z.B. Volume und Source) sollten als DPT 5001 verwenden, Werte die auch negativ sein können (Bass etc.) sollten DPT 5 verwenden. "donotdisturb" ist glaub mittlerweile ein Bool, also type = bool und DPT 1 und bei "partymode" wird einfach der String weitergesendet, also sollte es "ON", "OFF" oder "MASTER" sein.

Muss aber gestehen, dass das alles nicht wirklich getestet ist, da ich das nicht in KNX integriert benutze (bisher nur Zone AUS/AN und Lautstärke). Die Einwände von Alex sind gut, werde das bei Gelegenheit überarbeiten.

Das noch undokumentierte Feature "relativevolume" wurde nun in DPT1 geändert. Bei Wert 1 wird einmal VolumeUp bei 0 einmal VolumeDown gesendet. "enforce_updates" muss gesetzt sein, damit es funktioniert.

[DK178]

Hallo Niko,

mit deiner und Alex hilfe habe ich die meisten Funktionen am laufen. Allerdings fällt es mir schwer Bass, Treble and Balance vernünftig zu setzen. Ich würde da auch klar einen Wertebereich -10..10 favorisieren. Das ist dann geanu was der C5 erwartet. Bei einer Bereichsüberschreitung würde ich einfach den Wert ignorieren.

Gruß,
David

[Alex]

Hallo Niko

Hallo,

numerische Werte die nur positiv sind (wie z.B. Volume und Source) sollten als DPT 5001 verwenden,

Hmm, DPT 5.001 (0..100%) - also im items.conf als knx_dpt = 5001" konfiguriert - würde ich tatsächlich auch für naheliegender halten.

Aber: nach meinem Verständnis - das natürlich auch falsch sein kann - wird in DPT-5.001-KNX-Telegrammen der Wertebereich 0..100% auf die 0x00..0xFF des unsigned 8-Bit abgebildet (ansonsten könnte DPT-5.001 nicht eine Genauigkeit von ~0.4% liefern).

Konfiguriere ich in items.conf "knx_dpt = 5001", dann macht Smarthome.py genau diese Abbildung - wie erwartet - und liefert einen Int-Wert von 0..100 (%).

def en5001(value):
    return [0, int(int(value) * 255 / 100) & 0xff]


def de5001(payload):
    if len(payload) != 1:
        return None
    return struct.unpack('>B', payload)[0] * 100 / 255

Allerdings machst Du im Russound-Plugin nochmals eine Abbildung von 0..255 auf den RIO-Wertebereich von 0..50:

    def update_item(self, item, caller=None, source=None):
...
            elif cmd == 'turnonvolume':
                self.send_set(c, z, cmd, int(round(float(item()) / (255.0 / 50.0))))
...
    def _decode_zone(self, cmd, value):
...
        elif cmd == 'turnonvolume' or cmd == 'volume':
            return int(round(float(value) * (255.0 / 50.0)))

Hier im Russound-Plugin müsste nach meinem Verständnis, wenn Du DPT-5.001 (bzw. "knx_dpt = 5001") in der items.conf konfiguriert haben möchtest, eine Abbildung von 0..100 auf die RIO-Werte 0..50 statt finden.

Deswegen funktioniert meine Aussage mit "knx_dpt= 5" (da hier SmartHome.py eben 0..255 liefert) mit dem Russound-Plugin, wohingegen "knx_dpt = 5001" eben nicht über den vollen Wertebereich funktioniert.

Werte die auch negativ sein können (Bass etc.) sollten DPT 5 verwenden.

Echt jetzt? DPT-5 ist doch laut ETS "8-Bit vorzeichenlos", bzw. laut Telegramm-Doku "8-Bit Unsigned Value".
Für den von Dir in der Doku festgelegten Wertebereich für "bass", "treble" und "balance" von "[-128..127]" käme doch m.E. eher DPT-6 (8-Bit vorzeichenbehaftet) bzw. genauer 6.001 ("Prozent (-128..127%)") in Frage, d.h. in items.conf "dpt = 6" und KNX-Seitig DPT-6.001.

Allerdings fällt es mir schwer Bass, Treble and Balance vernünftig zu setzen. Ich würde da auch klar einen Wertebereich -10..10 favorisieren. Das ist dann geanu was der C5 erwartet. Bei einer Bereichsüberschreitung würde ich einfach den Wert ignorieren.

Das fände ich zugegebenermassen auch besser.
Meine Begründung hierfür wäre u.A. wie folgt: Wird der RIO-Wertebereich -10..10 auf -127..128 (bzw. wenn's schon sein muss auf -127..127) abgebildet, so haben wir KNX-seitig bzw. SmartHome.py-seitig ein relativ großes Intervall, auf welches ein RIO-Wert abgebildet wird (nämlich ungefähr 12).

Könnte ich nun in einer Visu einen Slider zum Einstellen der Lautstärke bzw. für Bass/Treble/Balance bewegen (dieser Slider hätte den KNX-Wertebereich -127..127) und dieser Slider würde während der Finger-Bewegung jeden geänderten Int-Wert (aus -127..127) verschicken wollen, so kämen in einem 12-Integer-Werte breiten Slider-Bereich stets dieselben RIO-Werte heraus. Wenn nun über RIO vom C3/C5 die Rückmeldung über den geänderten Wert eintrifft, würde der Slider seine Position aktualisieren und würde m.E. unerwartete Sprünge machen. Hmm, ich hoffe, ich konnte halbwegs verständlich machen, was ich damit meine...

Bei der Lautstärke dürfte der Effekt nicht ganz so heftig sein, da hier der RIO-Wertebereich 0..50 auf 0..100% abgebildet wird, d.h. die Intervallgröße nur 2 beträgt.

Muss aber gestehen, dass das alles nicht wirklich getestet ist, da ich das nicht in KNX integriert benutze

Nun, ich teste das derzeit intensiv und zwar KNX-seitig mit ein paar Tastern und mit einer selbstgestrickten Visu, die ausschließlich mit dem eibd kommuniziert und als Gegenkontrolle mit einer weiteren kleinen Applikation, welche ausschließlich RIO spricht. So kann ich von beiden Seiten (KNX und RIO) Zustände ändern und beobachten, was auf der jeweils anderen Seite ankommt ;-)

Die Einwände von Alex sind gut, werde das bei Gelegenheit überarbeiten.

Das ist nett von Dir.

Das noch undokumentierte Feature "relativevolume" wurde nun in DPT1 geändert. Bei Wert 1 wird einmal VolumeUp bei 0 einmal VolumeDown gesendet. "enforce_updates" muss gesetzt sein, damit es funktioniert.

Super! Habe gerade mein SmartHome.py aktualisiert, getestet und bin begeistert - vielen Dank, für diese Änderung.

Viele Grüße,
Alex