Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Nun, das geht aber ich muss leider davon abraten!
(so hoffe ich, die BS im Orginal kann man ja mal komplett in die Tonne treten, hmmm, ..) - nur wenn die Sache dann nach ein paar Wochen ne Latenz von 30s++ bekommt wird der WAF halt stark gefährdet..
Das konnte mir bisher weder Bubu noch Lala erklären (Insider ) woran das liegt..
Ich finde es halt absolut inakzeptabel, wenn eine Lautstärke-Änderung 30s dauert aber vielleicht bin ich da nur zu empfindlich
Ich verwende die von Makki bereitgestellten Dateien. Und mit dem Quadclient und der Gira App klappt alles wunderbar - insbesondere vernünftige Antwortzeiten.
Irgendwo hier hängen auch die von mir geänderten HS-BS an, gerne verwenden - hab sie aber nie in DL gestellt weil es zwar besser - aber längst nicht perfekt ist..
Vielleicht mag von Euch jemand das Thema bei Gira ansprechen/auffrischen oder kennt sogar jemanden bei Dacom?
Ich kann das gerne tun. Allerdings, das sage ich euch gleich, eine Lösung ist da nicht zu erhoffen. Und das liegt nicht an Gira. Mehr sage ich dazu definitiv nicht.
Nun, um das Thema für mich abzuschliessen: ich habs aufgegeben..
Irgendwann hängt da was, auch mit UDP (allerdings mit FW 2.5 bin ich da ausgestiegen);
das läuft jetzt ganz prächtig woanders, siehe letzter Post hier - auf was anderem mit einer Latenz von <50ms zwischen KNX und Russound - jede einzelne Sekunde 356x24
wobei ich noch ergänzen muss, ich habe mit Moxa bislang noch keine Probleme gehabt, ich hab die Dinger in verschiedenen Versionen laufen, auch 2.10.
Probleme mit Verzögerungen habe/hatte ich nur, wenn ich über TCP und LAN arbeite.
Ich bin nur Endkunde, kein Profi/Programmierer/Elektriker/Installateur. Und ich habe ehrlich gesagt auch zu wenig Ahnung um die vermutliche Ursache genauer zu definieren. Ich sehe nur, daß ich offenbar nicht alleine bin und in anderem Thread darüber gesprochen wird, wie man die Steuerung selbst macht. Da sind auch sehr viele Leute an der Diskussion beteiligt, woran man sieht, daß es hier nicht um einen Einzelfall geht.
Daher auch meine Frage, was denn außer dem Moxa/Russound noch über solche IP-Telegramme gesteuert wird!? Oder betrifft das Problem ausschließlich die IP-Telegramme an Moxa-RS232 an Russound, während andere IP-Telegramme problemlos gehen?
Vielleicht mag von Euch jemand das Thema bei Gira ansprechen/auffrischen oder kennt sogar jemanden bei Dacom?
Gruß,
Thorsten
Tja, selbst wenn Gira davon weiß (wovon ich ausgehe) ist halt die Frage ob die es ändern wollen und wie lange das dauert. Der von Gira bevorzugte und propagierte Weg fürs Multiroom ist in Verbindung mit Revox. Ich glaube nicht das Gira an einer Russound Anbindung wahnsinnig interessiert ist.
Bis heute (2.4 bis 2.8) besteht das Problem wohl noch immer, daß der HS ein Problem mit IP-Telegrammen hat.
Nach meinem Update auf 2.8 funktioniert meine Russound-Steuerung über Moxa NPort RS232 immer nur ein paar Tage lang und wird dann entweder extrem zäh (Minuten-langes warten bis er reagiert) oder hängt komplett. Seitdem starte ich alle paar Tage den HS neu.
Tritt das Problem denn nur bei IP-Telegrammen an den Moxa auf oder gibt es noch andere Geräte die via IP-Telegramm ihre Steuerbefehle bekommen und die ebenfalls hängen?
Hat schon irgendwer mal Gira/Dacom informiert? Es ist zwar kaum zu glauben, daß die Macke dort noch nicht gemeldet wurde, aber es ist genauso unglaublich, daß der Fehler immer weiter durch die Versionen mitgeschleppt wird. Es dürfte doch sicher jeder 2te oder 3te HS-Nutzer auch einen Russound über Moxa angeschlossen haben, d.h. ein Großteil der Kundschaft hat das Problem. Das kann Gira/Dacom doch nicht egal sein!?
Wie ich sehe, gibt es hier einen Thread wie man den Russound einfach direkt ansteuert, ohne HS. So ein Workaround ist gut und schön, packt das Problem aber nicht an der Wurzel.
Gruß,
Thorsten
Rein theoretisch () ginge es hier weiter.. Wollte den Thread nicht verseuchen
Versprechen will ich nichts, kann auch 2014 werden, mehr als genug Frust-Blutdruck habe ich da aber..
Nur soviel: das Ding wäre in der halben Zeit geschrieben, wie das stark suboptimale Zeugs im HS funktionierend zu bekommen.. Hab das ja schon 2x hinter mir..
Ich für meinen Teil würde mit so einer Funktionalität zurecht kommen. Im Moment mache ich das wesentliche schon über GA's. Ein/Aus, Lautstärke und ein Sourcewechsel kommen in der Regel über Tastsensoren. Wenn ich Balance etc verändern will mach ich's über die Visu vom HS.
Ich betreibe 6 Zonen, drei Quellen und in denen auch nur den Audioanteil.
Das abschalten ist es nicht, ich knipse meine auch weg, habs aber auch schon ohne probiert. Queues können eigentlich nicht vollaufen mit UDP
Naja, wiegesagt, ich weiss es auch nicht..
Rein rhetorische Frage: mal angenommen man könnte das - in einfach(!) - als kleinen Linux-daemon machen, also nur in Quick&fix Russ<->KNX, in einem angegebenen, festen GA-Bereich 6-12 Zonen mit den wichtigen Werten (ohne Keypads; mit Volume, EinschaltVolume, Bass,Treble,Balance,Loudness,Source)
Wär das was?
@Makki: In der Version 2.6 hatte ich sowohl mit den DACOM wie auch mit Deinen Bausteinen getestet und jeweils untragbares Verhalten. In meinem 2.3er Projekt verwende ich DACOM Module.
Zur Info: Ich schalte den Russound in der Nacht ab. Oftmals war nach dem Einschalten am morgen dieser untragbare Zustand. Es war aber nie so dass es nicht ging. Das Verhalten besserte sich nicht im laufenden Betrieb (Gedanke: Voller Puffer o.ä. wird nach dem Start mal abgearbeitet sein).
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: