Russound C3/C5 RIO over TCP Plugin

[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

Zitat von DK178 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

Zitat von 2ndsky 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.

Zitat von DK178 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.

Zitat von 2ndsky 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 ;-)

Zitat von 2ndsky 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

[2ndsky]

Zitat von DK178 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.

An und für sich ist es kein Problem den Wertebereich darauf einzuschränken. Die Umrechnung habe ich nur deshalb gemacht, damit man es bei der Verwendung eines Sliders in der Visu oder Dimmtelegramme eines Tasters einfacher hat. Da ich diese Einstellungen aber gar nicht verwende (einmal über die Russound App eingestellt und gut ist) kann ich dazu nichts sagen. Wenn ihr beide also der Meinung seid, ein Wertebereich mit den Werten des Russounds wäre passender, dann änder ich das.

Zitat von Alex 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.

Kurz und knapp... ich habe den DPT gewählt, der beim Testen funktioniert hat. Ich hatte keine Lust lange die Spezifikationen der DPTs zu wälzen. Wenn ich in sh.py DPT 5 verwende war der Wertebereich von -128..127 (oder wars -127..128?) und bei DPT 5.001, also 5001 in sh.py war er von 0..255. Daher ist das Plugin wie es ist. Ich schreibe das gerne um, wenn ihr mir sagt, welche Variante ihr für sinnvoll haltet. Möglich wäre:

- Wertebereich auf Russound abgestimmt
- Wertebereich auf KNX abgestimmt

Bei ersterem ist es mir so ziemlich egal, welcher DPT verwendet wird, ich ignoriere einfach alle Werte die außerhalb der Russound Specs sind. Im zweiten Fall sollten sich die Verwender bitte darauf einigen welcher DPT und wie die Umrechnung genau aussehen soll.

Wenn wir das haben, baue ich das gerne um.

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

Gerne, freut mich wenn es funktioniert und dir Freude bereitet!

[2ndsky]

Alex hat mir in der Zwischenzeit seine Anregungen per Mail geschickt und ich habe sie eingearbeitet. Außerdem habe ich noch die ein oder andere Erweiterung eingebaut:

- alle numerischen Werte werden nun auf die von RIO akzeptierten Werte begrenzt (Balance, Treble, Bass, TurnOnVolume, Volume)
- der Name einer Zone wird ausgelesen, Itemconfig: rus_path = c.z.name (wobei c = Controller ID und z = Zone ID), type sollte string sein
- alle Russound Kommandos, die das Plugin nicht kennt, werden per KeyRelease Nachricht versendet. Damit kann man z.B. die RIO Key Codes für das weiterschalten des Tuners implementieren. Wenn also der rus_path = 1.2.ChannelUp lautet, wird bei jeder Änderung dieses sh.py Items (wenn enforce_updates = true gesetzt ist muss sich der Wert nichtmal ändern) für die Zone 2 des Controllers 1 ein KeyRelease mit dem Key Code "ChannelUp" gesendet.
- Quellen können auf Änderungen überwacht werden. Es gibt ein neues Item Attribut "rus_src" dem man eine Nummer der zu überwachenden Quelle setzen kann wie z.B. rus_src = 1 zum Überwachen es ersten Eingangs. Empfängt das Plugin nun eine Notification, das sich was geändert hat, wird versucht, die Änderung auf Kindelemente des Items zu mappen. Ändert sich z.B. der Channel von Quelle 1 wird geschaut, ob es ein Item mit rus_src = 1 gibt und wenn ja, ob dieses Item ein Kind namens "Channel" hat. Ist dies der Fall wird der empfangene String Wert unverblümt in dieses Kind geschrieben.

ACHTUNG: habe den aktuellen Stand unterwegs geändert und konnte diesen noch nicht testen, daher nur die Git Version auschecken, wenn man weiß was man tut

[2ndsky]

Ich hab noch ein paar Bugs und Typos gefixt und die aktuelle Github Version bei mir getestet. Beim Auslesen des Namens einer Zone muss darauf geachtet werden, dass das Item selber nicht "name" heißst. Also falsch:

[audio]
    [[zone1]]
        [[[name]]]
            type=str
            rus_path=1.1.name

Da "name" bereits eine Eigenschaft eines Items ist. Richtig z.B.:

[audio]
    [[zone1]]
        [[[zonename]]]
            type=str
            rus_path=1.1.name

Das senden von KeyReleas sollte prinzipiell funktionieren. Getestet habe ich bisher nur "mute" das bisher speziell behandelt wurde und nun über die universal Funktion gesendet wird. Da das funktioniert sollte auch "channelup" etc. gehen.

Das Auslesen einer Quelle funktioniert so noch nicht wie ich mir das vorgestellt habe, daher ist das momentan wieder auskommentiert. Ich habe zwei mögliche Lösungsansätze und spreche gerade noch mit Marcus durch, was sinnvoller ist.

EDIT: habe zwischenzeitlich mit Marcus gesprochen und wir sind so verblieben, dass diese Funktion erstmal noch nicht ins Plugin kommt sondern erst später, wenn die Visu damit auch umgehen kann.

[tofele]

Niko

Wenn ich mich nicht irre hast Du ja den TS3 plus im Einsatz. Wie hast Du diesen denn konfiguriert für die Ansteuerung einer Zone (z.B. ein/aus, source select, volume up/down, mit langen/kurzen Tastendrucken)? Ich habe zwar (noch) nicht smarthome.py im Einsatz (sondern z.Z. noch den russconnectd von makki) aber die Konfig des Tasters sollte ja davon unabhängig sein. Irgendwie bekomme ich das nicht ganz hin ...

Danke
Tom

[2ndsky]

Hi Tom,

Source select kommt bei uns sehr selten vor (seit einem halben Jahr zwei mal) und das mach ich derzeit noch per Russound App. Ansonsten habe ich eine Wippe konfiguriert mit Volume Up/Down bei kurzem Tastendruck. Ein langer Tastendruck schaltet die Zone AUS (oder der PM wenn niemand mehr anwesend ist). AN geht automatisch wenn man Volume Up sendet. Mehr brauchen wir derzeit nicht.