Russound C3/C5 RIO over TCP Plugin
 

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!

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.

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.

Hallo Niko

Nicht mehr :-)
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:
logic.conf:

logics/rio_volrel_az.py:
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:
Damit käme ich komplett ohne Einträge in logic.conf und logic/*.py-Scripte aus und könnte einfach pro Zone folgendes schreiben:
Was meinst Du dazu?

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

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.

Hallo Nico

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.

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 ;))

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

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.

Hi Niko

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.

Ok, dann werde ich bis zum WE den Code noch etwas aufbereiten und kommentieren und Dir dann zuschicken...

Viele Grüße,
Alex

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.

Hi Niko

Prima, das freut mich!

Gute Nacht und vielen Dank nochmals,
Alex