Russound <-> KNX

[2ndsky]

Russound &amp;lt;-&amp;gt; KNX

.. Also je nachdem - wahllos- über RIO (was meine Russound immernoch nicht kann, nur zur Erinnerung) inkosistente Stati auf verschiedenen Endgeräten, das kann man mögen, steht aber nicht auf meiner Featureliste
Es muss immer der aktuelle Status anliegen da es nunmal zus. Apps/Geräte/Keypads gibt.

Drum hab ich ja geschrieben: "wenn man den Russound nur über den Daemon bedient. Ansonsten baut man die Verbindung wieder auf, sobald der Russound sie beendet. Wo ist das Problem?

[Incognito666]

Hallo Makki,

vielen Dank für die unkomplizierte Russound Ansteuerung.
Mein CAS44 läuft damit zwar einwandfrei, aber die Reaktionszeiten sind leider noch inakzeptabel.
Es dauert ca. 1-10 Sekunden bis eine auf den Bus geschickte Aktion (z.B. Lautstärke ändern) auf dem Russound ausgeführt wird.

Gibt es dafür eine Erklärung, oder liegt das an meinem Russound?

Gruß
Matthias

[tofele]

Jetzt habe ich endlich auch mal einen USB/Seriell Adapter besorgt und die Anbindung an meinen C5 probiert, geht aber nicht. Ich krieg den socat nicht zum Laufen. Siehe screenshot im Anhang. Wenn ich auf den Speichern Button drücke passiert nichts ...

Ausserdem probiere ich noch socat direkt zu starten:

root@wiregate625:~# socat /dev/serial-2-4.6,raw,b19200,cs8 udp-datagram:localhost:16011,bind=localhost:16012,reuseaddr
2013/05/16 22:15:27 socat[2440] E tcgetattr(3, 0xbfed60ac): Inappropriate ioctl for device

Was ist falsch? Adapter nicht unterstützt? Brauch ich wirklich einen Moxa? Welchen genau?

Danke
Tom

[JuMi2006]

Ohne Tippfehler würde es vielleicht gehen

Konsole: /dev/serial-2-4.6
Webmin: /dev/ubsserial-2-4.6
Richtig: /dev/usbserial-2-4.6

Der Richtige Name steht unten im Webmin unter "Liste angeschlossener USB-Adapter". Dann wäre eine udev-Regel (google oder Forensuche im WG-Forum) noch sinnvoll.

Grüße

[tofele]

Tja, das kommt davon wenn jemand, der bei der UBS arbeitet am Ende eines anstrengenden Arbeitstages dann abends noch mit USB rumbastelt und den Wald vor lauter Bäumen nicht mehr sieht ... ;-)

Danke für den Tipp!

Ok, socat läuft jetzt, aber der C5 regt sich immer noch nicht. Muss noch mal die GAs checken, wegen 8 Zonen und 30 GAs pro Zone im Daemon und in makki's GA Generator.

[Incognito666]

Hi,

ich hab immer noch das Problem, dass teilweise nur sehr verzögert auf die Änderung einer GA reagiert wird. Manchmal aber auch innerhalb von ms (keine merkbare Verzögerung).
Es ist auch egal, ob ich eine Zone Ein-/Ausschalte, lauter/leiser mache oder sonstwas.

Ich hab eine Debugausgabe eingefügt. Die erste Zeile wird sofort beim Einschalten der Zone über die entsprechende GA ausgegeben. Die darauffolgenden Zeilen bewirken wohl das Einschalten der Zone im Russound und kommen ca. 5 Sekunden später.

russconnectd 0.32[8239]: write ctrl 0 zone 1 func 0 val 0x01
russconnectd 0.32[8239]: russconnectd 0.32 daemon running
russconnectd 0.32[8239]: polling zone 0
russconnectd 0.32[8239]: russ Controller:0 Zone:0 TurnOnVolume:29
 unknown len: 24 0xF0 0x00 0x01 0x7D 0x00 0x00 0x7F 0x00 0x03 0x04 0x04 0x06 0x02 0x04 0x00 0x00 0x00 0x01 0x00 0x01 0x00 0x02 0x1E 0xF7
russconnectd 0.32[8239]: polling zone 1
 unknown len: 24 0xF0 0x00 0x01 0x7D 0x00 0x00 0x7F 0x00 0x03 0x04 0x04 0x00 0x02 0x04 0x00 0x00 0x00 0x01 0x00 0x01 0x00 0x13 0x29 0xF7
russconnectd 0.32[8239]: polling zone 1
 unknown len: 15 0xF0 0x00 0x01 0x7D 0x00 0x00 0x7F 0x06 0x3C 0x00 0x00 0x00 0x05 0x41 0xF7
 unknown len: 24 0xF0 0x00 0x01 0x7D 0x00 0x00 0x7F 0x05 0x02 0x01 0x00 0x02 0x01 0x00 0xF1 0x23 0x00 0x01 0x00 0x01 0x00 0x01 0x25 0xF7
 unknown len: 24 0xF0 0x00 0x00 0x7D 0x00 0x00 0x7F 0x00 0x03 0x04 0x04 0x02 0x02 0x04 0x00 0x00 0x00 0x01 0x00 0x01 0x00 0x01 0x18 0xF7
russconnectd 0.32[8239]: polling zone 2
 unknown len: 24 0xF0 0x00 0x01 0x7D 0x00 0x00 0x7F 0x00 0x03 0x04 0x04 0x02 0x02 0x04 0x00 0x00 0x00 0x01 0x00 0x01 0x00 0x01 0x19 0xF7
russconnectd 0.32[8239]: russ Controller:0 Zone:2 Status:0 src:0 vol:10 bass:14 treb:10 loud:0 bal:10 sys:1 shrsrc:0 party:0,DnD:0
russconnectd 0.32[8239]: polling zone 3
russconnectd 0.32[8239]: russ Controller:0 Zone:3 TurnOnVolume:24
russconnectd 0.32[8239]: russ Controller:0 Zone:3 Status:0 src:0 vol:24 bass:15 treb:10 loud:1 bal:10 sys:1 shrsrc:0 party:0,DnD:0
russconnectd 0.32[8239]: polling zone 4
russconnectd 0.32[8239]: polling zone 5
 unknown len: 24 0xF0 0x7E 0x05 0x70 0x00 0x00 0x7F 0x05 0x02 0x01 0x00 0x02 0x01 0x00 0xF1 0x37 0x00 0x00 0x00 0x01 0x00 0x00 0x2C 0xF7

Wäre über jede Hilfe dankbar!

Gruß
Matthias

[Incognito666]

ich denke ich habe das Problem gefunden:

Die Funktion 'sendrussPolling' wird von zwei Threads aufgerufen: main und knxthread. In Zeile 152 wird der Mutex 'standbylock' angefordert mit try-lock, dieser wird in der Funktion jedoch nie wieder freigegeben.
Die Funktion 'sendrussFunc' fordert in Zeile 196 ebenfalls 'standbylock' an. Wenn aber im 'main' Thread der Mutex angefordert wurde, wird 'standbylock' also nie wieder freigegeben und der Thread 'knxthread' bleibt hängen.
Somit wird zukünftig nur noch das Polling funktionieren, was genau mein Verhalten spiegelt.

Da in Zeile 152 mit einem try-lock gearbeitet wird und der Rückgabewert nie ausgewertet wird, macht die Zeile doch eh keinen Sinn (Egal ob der Lock angefordert werden kann, oder nicht wird weitergemacht). Ich denke da fehlt die Synchronisierung komplett.

Kann sich das bitte jemand anschauen? Makki, du vielleicht ?

150  void *sendrussPolling(unsigned char zone) {
151    syslog(LOG_DEBUG, "polling zone %d",zone);
152    pthread_mutex_trylock(&standbylock);

Danke
Matthias

[Incognito666]

Ich hab die Zeile einfach mal auskommentiert (hatte ja eh keinen tieferen Sinn) und den russconnectd neu kompiliert.
Funktioniert bei mir nun einwandfrei.
Nach meiner Einschätzung müsste der Fehler eigentlich allgemein auch bei anderen auftreten. Daraus schließe ich, entweder niemand verwendet den russconnectd, oder ich hab irgendwas übersehen und das ist jetzt doch speziell für meinen Russound.
Wäre nett, wenn sich dazu diejenigen mal melden könnten bei denen das auch ohne den Fix funktioniert.

Ich habe das fertige Kompilat mal angehängt, falls es jemand braucht.

[makki]

Ich muss das testen aber der Theorie nach liegst du goldrichtig, das ist zu 99% ein ziemlich blöder Bug! (Nur zur Erklärung: Ziel war aber nicht, das der da wieder released wird, sondern eben sobald eine AW eintrifft, weil weiteres pollen solange keinen Sinn macht - nur hab ich da wohl was übersehen..)

Verwendet wirds übrigens AFAIK nur bei einer Handvoll, deshalb habe ich da auch nie die grosse Energie reingesteckt - weil einfach das Feedback fehlte.. Bei mir gehts (warum auch immer - tritt das hier nicht auf)
Den standbylock-Mutex hatte ich nie fertig implementiert (der Hintergrund war ein ganz anderer, wenn eben die Russound aus ist! Und das ist sie bei mir seit vielen Monaten nichtmehr, evtl. deshalb nie aufgefallen - sigh!)

Danke! Ich melde mich dazu die Tage..

Makki

[SvStefan]

Nach meiner Einschätzung müsste der Fehler eigentlich allgemein auch bei anderen auftreten. Daraus schließe ich, entweder niemand verwendet den russconnectd, oder ich hab irgendwas übersehen und das ist jetzt doch speziell für meinen Russound.
Wäre nett, wenn sich dazu diejenigen mal melden könnten bei denen das auch ohne den Fix funktioniert.

Vielen Dank für den Fix! Hab den Daemon bei mir im täglichen Gebrauch und mir sind auch immer wieder Verzögerungen von bis zu 5-10 Sekunden aufgefallen. Die sind jetzt mit dem Fix weg, ein großes Danke!

LG Stefan

[makki]

v 0.34

So, hab da mal aufgeholt & das ins SVN geschoben (NICHT ins WireGate-Repository, es findet also nirgends ein automatisches Update statt!):

- Ein Bugfix mit mehreren Controllern
- Mehr/besseres Debugging um zukünftige besser implementieren zu können
- C5-Support
- Den standbylock wie von Inkognito666/Matthias angemerkt -> entfernt, ist ziemlich sinnlos

Änderungen:
Open Automation / Code / Commit [r2041]

Changelog:
Open Automation / Code / [r2042] /tools/russconnectd/trunk/ChangeLog

Binaries/Release-Source:
Open Automation / Code / [r2042] /tools/russconnectd

Makki

[makki]

Eine Sache die mir - wirklich nach Jahren! gestern das erste mal untergekommen ist - und zwar bei den eigenen beiden CAA6.6
Die zweite hatte sich "einfach abgehängt", also auf nichts mehr reagiert.
Das war kein SW-Fehler (Oszi & LA dran), die war einfach "weg"

-> Quintessenz: Tipp: immer allesamt an einen Aktor (hat man ja eh aufgrund des eher "amerikanischen" Standby-Verbrauchs)
In Projekten immer dafür einen Power-Button einplanen, und alle einweisen. Danach ists wieder gut.
Ich schreibe das, weil ich vorletzte Woche dasselbe mit zwei C5 ohne Aktor dran hatte..

Habe das bisher ehrlich gesagt immer "abgetan" und nachm Power-Cycle gings ja wieder aber diesmal war ich "Live" dabei und konnte nachmessen..

Makki

[SirTom]

Cooles Projekt, danke. Habe 2x C3 oder C5 auf der Liste. Habe gelesen die C5 kann man kaskadieren und die C3 nicht?! Kann das wer bestätigen?

Bedeutet das, dass die Quellen durch geschleift werden?

[tofele]

Genau, die Quellen werden durchgeschleift, aber kaskadiert wird nichts. Der erste C5 hat 6 (bzw. 8 Zonen), der nächste dasselbe nochmal, mit den gleichen Quellen. Habe selber zwei C5.

Tom

[Incognito666]

Hat jemand mal den Standbyverbrauch seines Russounds gemessen? Ich meine den Verbrauch, wenn alle Zonen abgeschaltet sind.

Wie habt ihr das mit dem Schaltkanal gemacht? Ich lasse mir meine Zonen teilweise automatisch einschalten, wenn Musik gespielt wird. Wenn aber der Russound erst eingeschaltet werden muss, dann darf der Zonenbefehl erst abgesetzt werden, wenn der Russound 'hochgefahren' ist. Und da habe ich ja momentan keine Rückmeldung. Wie machst du das Makki?