DIY Multiroom Projekt

unimatrix · 17 Oktober 2016, 11:35:05

Hallo,

Update 26.01.2017: Die Ideen und Diskussionen aus diesem Thread sind inzwischen in den 2 neuen Modulen OpenMultiroom und Snapcast aufgegangen. Dieser Thread ist als Archiv zu verstehen und somit jetzt geschlossen. Feedback usw. sollte in den Threads der beiden Module stattfinden:

Snapcast: https://forum.fhem.de/index.php/topic,62389.0.html
OpenMultiroom: https://forum.fhem.de/index.php/topic,65785.0.html

-----

nach langer Marktrecherche bin ich für mich zu dem Ergebnis gekommen, dass keine sinnvolle Multiroom Audiolösung auf dem Markt existiert, die meinen Ansprüchen gerecht wird. Daher habe ich ein DIY Projekt angefangen und auch schon in der 1. Phase umgesetzt. Für die weitere Entwicklung suche ich Anregungen und ggf. auch Hilfe in der Umsetzung.

So sieht mein Setup aus:

ich habe einen zentralen Server mit Ubuntu. Es spielt keine Rolle, ob dies "nur" ein PI oder ein echter Server ist. Dieser beinhaltet auch die Musiksammlung (wobei es egal ist wo die ist)
ich möchte Musik in mehreren Räumen im Haus wiedergeben. Das sind meistens MP3s die ich auf dem Server habe. Aber auch Streams z.B. Radiostreams.
Ich habe mehrere Familienmitgliedern die ihre eigenen Playlists verwalten möchten
Die Steuerung erfolgt primär nicht über eine App, Tables, Webif, etc. sondern über X10 Fernbedienungen. Diese gibts für sehr wenig Geld z.B. bei Pollin und mit einem X10 Empfänger habe ich in meinem Haus (was über 3 Etagen geht) überall Empfang. Der X10 empfänger ist einfacherweise am Server per USB angeschlossen.
Die Räume sind teilweise angrenzend, daher muss ein synchrones Playback der gleichen Quelle in mehreren Räumen gleichzeitig möglich sein, bzw. ist es auch schon. Es muss aber genau so gut möglich sein, jeden Raum individuell zu bespielen, und auch das ist schon so.

Im Detail funktioniert es zur Zeit wie folgt:

In jedem Raum steht ein Rechner mit Linux. Das ist meistens ein Pi, ich habe aber auch noch eine alte Dockstar im Einsatz. Im Wohnzimmer steht ein HTPC mit VDR der ebenfalls dazu zählt.
Die Verteilung der Audiosignale läuft über pulseaudio. Auf dem Server und allen Clients läuft pulseaudio im system-Modus. Für jeden Client wird auf dem Server ein tunnel-sink angelegt. Im Falle von einer Wiedergabe in mehreren Räumen gleichzeitig wird dazu noch ein combined-Sink angelegt.
Die eigentliche Wiedergabe läuft über MPD. Hier möchte ich später auf die neue Python version von MPD umsteigen, da diese z.B. auch Spotify und vieles mehr unterstützt. Für jeden konfigurierten Client läuft auf dem Server eine MPD Instanz.
Die Musiksammlung insgesamt wird bei mir mit Subsonic verwaltet. Subsonic hat eine vernünftige Weboberfläche zum Verwalten von Playlisten und es gibt gute Apps für Android und für Iphone. Unabhängig von diesem Projekt nutze ich auf Android die App DSub um Musik z.B. im Auto zu hören. Meine Kinder können sich mit ihrem eigenen Subsonic Account per Webinterface eigene Playlisten machen oder die gemeinsamen Playlisten nutzen.
Mit einem regelmäßig laufenden kleinen Perl Script werden aus den Subsonic Playlisten MPD Playlisten erzeugt. Dabei werden die persönlichen Accounts berücksichtigt (und die Playlisten den passenden Räumen, z.B. Kinderzimmer zugeordnet) Die einzelnen MPD Instanzen kennen also jeweils ein unterschiedliches Subset an Playlisten. Das habe ich so realisiert, dass ich die Playlisten bei der Konvertierung mit einem Prefix benenne.
Die einzelnen Clients sind nicht alle always on (einige schon). Hier nutze ich fhem, um diese per Funksteckdose einzuschalten und auszuschalten (per shutdown und verzögertem Ausschalten der Steckdose). Bei den Always On Clients habe ich zumindest die Lautsprecher, die ja eine eigene Stromversorgung haben per fhem steckdose schaltbar gemacht, damit diese nur laufen wenn Musik gespielt wird.
Ich habe eine Perlapplikation entwickelt, die als Dienst auf dem Linuxserver läuft und im wesentlichen folgende Aufgaben übernimmt:

Er öffnet einen Socket, auf dem die Signale von irexec dann eingehen. Dies kann z.B. sein ,,play wohnzimmer". Im Wohnzimmer hat also jemand auf play gedrückt.
Es sendet je nach empfangenden kommande auch Befehle an FHEM um z.B. einen Client einzuschalten. Wie im beispiel oben, im Wohnzimmer drückt jemand Play auf der Fernbedienung. Falls dieser Client noch nicht an ist, wird er jetzt eingeschaltet und das play Command in eine Queue gestellt mit einem Timeout.
Es scannt die ganze Zeit das Netz ab und schaut, welche Clients online sind und welche nicht. Dazu wird im ersten Schritt Ping genutzt und im zweiten Schritt der Pulseaudio-Client ,,pactl"
Es legt bei Erscheinen von neuen Clients im Netz (als Resultat davon, dass die jemand eingeschaltet hat) einen entsprechenden Pulseaudio-Sink auf dem Server an. Es weist dann diese neuen Sink als output der passenden MPD Instanz zu. Der Client wird somit als online markiert.
Er führt alle weiteren Kommandos aus, die auf den Fernbedienungen gedrückt werden. Play startet dann den MPD Playback, entsprechend gibt es alle üblichen Kommandos für Pause, Next, Prev, Fast Forward usw. (Fast Forward ist hier so realisiert, dass einen festen Prozentsatz der Länge des MP3s gesprungen wird)

Über spezielle Kommandos (bei mir auf den Fernbedienungen auf den Farbtasten) kann sich ein Raum an einen bereits laufenden Raum ,,anhängen". Wiederholtes Drücken auf den ,,Attach" Knopf hängt den Client zyklisch an die anderen zurzeit eingeschalteten Räume an. Ist kein anderer eingeschaltet, passiert nichts. Der Dienst legt dazu einen Pulseaudio combind Sink an, pausiert die MPD Wiedergabe, schaltet den MPD Output auf den neuen Sink, und startet sie wieder (das passiert so schnell, dass es nicht hörbar ist). Der dann angehängte Raum läuft vollkommen audiosynchron zum bereits laufenden. Per weiterem Farbkommando ,,control" kann ein anderer Raum in diesem Kontext dann auch gesteuert werden. Man kann also im 1. Kinderzimmer entscheiden, dass man jetzt auch das hören will, was im 2. Kinderzimmer läut, und dann auch direkt das 2. Kinderzimmer steuern. Dies kann ggf. durch Rechte eingeschränkt werden.

Auf den X10 Ferbedienungen gibt neben Knöpfen für Next und Prev noch ein paar für Channel Up und Down. Dieses habe ich für den Playlistwechsel verwendet. Hier kann man durch die Playlisten durchschalten.
Die Lautstärketasten bewirken über den Dienst, dass die Pulseaudio Client Lautstärke per pactl auf den Clients tatsächlich verändert wird. Da die numerischen Werte 0-100% bei den an den Pis angeschlossenen USB-Soundkarten alles andere als linear sind, ist in der Config für jeden Client eine Linearisierungs-Lookup Tabelle hinterlegt, die 10 Lautstärkestufen feste %-Werte zuweist.

Da Pulseaudio keine vernünftige APi hat (soweit ich weiss), rufe ich jeweils das pactl Tool auf und parse die Ausgabe mit regulären Ausdrücken. Das ist teilweise doof, da auch die Lokalisierung greift.
Für die Kommandos Next, PlaylistNext, VolUp, und FastForward kann durch die vorherige Eingabe von 1-n Ziffern ein Ziel vorgegeben werden. So führt die Eingabe von 1,5,Next dazu, dass MPD auf Track nummer 15 springt. Der Server merkt sich hierbei die Ziffern mit einem gewissen Timeout.

Da die ganze Bedienung ohne Display erfolgt, habe ich eine audiomäßige Rückmeldung implementiert. Hierbei nutze ich Signaltöne und von meinen Kindern aufgesprochene Sprachschnipsel. Beispiel Zifferneingabe: Die erkannte Zahl wird bei jeder Ziffer ausgegeben. Die Ziffernfolge 1,4,7 folgt nacheinander zu der Sprachausgabe: 1, 14, 147. Zahlen bis 60 liegen als MP3 vor, Zahlen darüber werden aus entsprechenden MP3s zusammengeschnitten wenn sie gebraucht werden.

Über die Konfiguration wird pro Raum festgelegt ein Zeitprofil mit Maximallautstärke vorgegeben. Lautstärke 0 in diesem Kontext heisst, dass der Raum nicht angeht. Hierdurch wird realisiert, dass sich die Musik bzw. Hörspiele in den Kinerzimmern zur Einschlafzeit zunächst von der Lautstärke begrenzt und zu festen Zeiten ganz abschaltet. Die Tagesprofile sind hier in die Kategorien Standard, beforefree, free und beforeschool unterteilt. Beforefree ist normalerweise Freitags (also ein Schultag, aber am nächsten Tag ist frei). Beforeschool wäre ein Sonn- oder Feiertag (es ist frei, aber am nächsten morgen muss man früh aufstehen). Ferien werden berücksichtigt (aus FHEM ausgelesen per Google Kalender)
Die Zeitprofile habe ich genau so umgesetzt wie die Heizzeiten bei Homematic, da ich dafür schon sowieso einen Parser entwickelt hatte.

Beim Umschalten zwischen Playlisten speichere ich den Playstate von MPD ab, so dass man beim zurückschalten an die gleiche Position kommt wo man sie verlassen hat. Gleiches beim Ausschalten usw.

Soviel zum Ist-Stand.

Letztlich möchte ich ein FHEM Modul über das alles abläuft, und auch der Zustand in entsprechenden Readings von den Räumen sichtbar ist. Ich nehme an man hat ein Client Modul und ein Server Modul und dann mehrere Instanzen vom Client Modul. Im nächsten Schritt kommt die Smartvisu Anbindung. Dazu müssen dann Widgets verändert und erstellt werden um z.B. die Funktion ,,Anhängen an einen anderen Raum" grafisch irgendwie abzubilden.

Um dahin zu kommen muss ich das bestehende wohl ziemlich umschreiben. Das ganze läuft, ist aber schwierig zu debuggen, da ich unter anderem Perl::Async nutze wegen der ganzen blocking Sachen (pactl, ping, mpd etc das sind alles blocking calls)

Bisher habe ich nur eine rudimentäre Übersicht über den Zustand des Systems per printf und Data::Dumper Ausgaben. Ein Webinterface fehlt völlig.
Da meine Kinder größer werden soll die Steuerung dann auch über Smartvisu per Smartphone möglich sein.

Am liebsten hätte ich eine sauberere Pulseaudio Anbindung aber hier scheine ich ein Exot zu sein, der sich eine normale API wünscht die man z.B. von perl ansprechen kann.

Für den Spezialfall dass ich den einen Raum auch als HTPC nutze, auf dem VDR zum Fernsehen und KODI für Filme etc. läuft brauche ich noch eine bessere Lösung. Die neueste VDR Version funktioniert mit Pulseaudio. Ich würde mich gerne auch an den Fernsehton in anderen Räumen anhängen können (Szenario: Bundesliga, etc). Ich möchte auch den VDR und Kodi mehr über FHEM steuern. Das ist dann so eine Art Entweder-Oder Sache. Auf dem HTPC kann entweder Musik laufen, der VDR fürs Fernsehen, oder KODI. Ich brauche noch ein FHEM Modul dass das irgendwie regelt, beim Umschalten auf KODI muss auch pulseaudio deaktiviert werden da damit kein DTS-HD Passthrough möglich ist.

Dann stehen noch andere KLenigkeiten auf der Liste. Pausieren bei eigehenden Anrufen (client- und telefonnummernabhängig) Signalisierung von anderen Dingen auf eingeschalteten Clients (Türklingel, Wäsche fertig, etc.) Am liebsten hätte ich auch die Möglichkeit für spontane Durchsagen ,,Kommt alle zum Essen" oder so. (Ja unser Haus ist etwas groß)
Ich sollte noch sagen, dass ich alle Geräte per Gigabit LAN angebunden habe. Die Datenrate ist klein, aber bei WLAN kann es Latenzprobleme geben. Dazu habe ich wenig Erfahrungswerte, da ich WLAN nur für Smartphones und Tablets einsetze.

Ich schreibe das hier alles, weil ich mir Kommentare und Anregungen erwünsche bzw. erhoffe. Ggf. hat der ein oder andere schon mal etwas ähnliches angefangen. Ich tue mich schwer mit einer sauberen Programmierung, mein Code ist sehr undurchsichtig. Speziell das Handling von asynchronen und blocking Sachen bereitet mir Schwierigkeiten.
Als erstes wäre es interessant zu erfahren, ob mein Setup schon so speziell ist, dass kein anderer damit was anfangen kann. Offenbar sind so Sachen wie Squeezeboxen sehr verbreitet. Sie bieten aber meiner Ansicht nach viele Nachteile. Die bei mir verwendete Hardware ist günstiger als alle fertigen Lösungen. Eine Squeezebox wäre erst dann schön, wenn man sie komplett mit einer Custom Firmware ausstatten könnte.

drdownload · 17 Oktober 2016, 16:30:48

Hi,

genau das wäre auch mein Plan gewesen, den ich schon schon einem Jahr hin- und her schiebe und immer wieder Teile realisiere um sie dann wieder zu killen.

Btw. wenn mit Python MPD auf mopidy anspielst, das kann weder sinnvoll mehrere Instanzen noch multiple Outputs.

Bin noch im Büro und daher nur drübergeflogen.

unimatrix · 17 Oktober 2016, 18:10:03

ok find ich gut dass ich nicht der einzige bin der sich sowas krankes ausdenkt. ja mopidy meine ich habe es mir aber noch nicht genau genug angesehen. hmm na gut möglicherweise dann doch nicht.

Meinen Code kommentiere ich gerade rudimentär und stelle ihn dann mal ein. Also heute noch.

Bei meinem Codereview gerade hab ich festgestellt dass ich pactl noch blocking aufrufe. Das läuft normal schnell aber wenn ein Host nicht erreichbar ist dann hängt es 2 Sekunden. Das ist schlecht. Ich habe keine Ahnung wie man das ganze korrekt implementiert, um nichts blockendes zu haben und dann mit Callbacks oder so zu arbeiten. In meinem SCript habe ich ja Die Async Lib aber das macht ja keinen Sinn wenn es ein FHEM Modul ist. Vll muss es ja auch keins werden sondern es bleibt ein eigener Dienst den man dann mit FHEM steuern könnte.

unimatrix · 17 Oktober 2016, 18:50:03

hier mal die aktuelle Implementierung. Ich habe meine persoenliche Config komplett drin. Aber das sollte unkritisch sein. So bekommt ihr eine Vorstellung von meinem Haus und davon wann meine Kinder ins Bett muessen

Den Code habe ich heute erstmalig rudimentaer kommentiert. Bei einigen Sachen weiss ich nicht mehr wie das eig. funktioniert. Das ganze ist bei mir aber seit 18 Monaten in fast taeglicher Benutzung.

https://github.com/unimatrix27/mpd_multiroom

drdownload · 17 Oktober 2016, 20:17:00

Nachdem nach meiner Meinung auch Pulseaudio-Sinks die einzig sinnvolle MR-Steuerung ermöglichen habe ich schon überlegt ob ich mit web.py oder dgl. ein simples Webservice baue um die Sinks ordentlich steuern zu können (ähnlich http://mateusz.viste.fr/attic/pawebgui/ ). Haupthindernis bei meiner Umsetzung war bis jetzt, dass sich in immer mehr Räumen Android-Devices sammeln (Mediaplayer und Tablets) und ich die gerne integrieren würde, aber da noch nicht weitergekommen bin.

Habe immer wieder Mini-Setups mit 2 RPis und einem Openwrt Mini_Router mit Pulseaudio die ich von einem Arch-Desktop aus ansteuere, aber so richtig integriert bin ich noch nicht

Zu unentschlossen was die Zieltechnologie betrifft (lande auch immer wieder bei LMS/Squeezeserver) Fernsehen ist bei mir nicht VDR sondern tvheadend und die Mediacenter haben alle Kodi als Frontend. Zusätzlich läuft emby als Mediaserver

Akuteller Plan wäre: im oberen Stockwerk wo die Schlafzimmer sind am Server 4 USB-Soundkarten anzuhängen und direkt in die Zimmer zu fahren vom Gang aus.

Future Projekte: Ein Radio mit Tablet zur Steuerung für meine Kinder bauen, Die CD-Sammlung mit RFID-Tags ausstatten um sie ohne Einlegen abzuspielen

unimatrix · 17 Oktober 2016, 21:15:33

Danke fuer das Feedback. Inwieweit hindern dich die Android Devices? Oder soll auf denen auch Sound ausgegeben werden? Als Steuerung will ich ja eh auf Smartvisu mit einem eigenen Widget, das sollte dann sowieso primär auf Android benutzt werden.

Es hilft mir zu wissen was andere für HW-Konfigurationen und Vorstellungen haben damit ich meinen Code einem Refacturing unterziehen kann so dass das dann generalistischer anwendbar ist. Das mit den USB Soundkarten klingt irgendwie...."nicht richtig"

...zumal man ja da auch das handling managen muss von wegen ein Stream oder verschiedene Streams

Was meinst du mit dem Future Project "radio mit tablet zur Steuerung" ? RFID ist lustig. Ich habe meinen Kindern mal "Magic Codes" gegeben um auf neue Hoerspiele zugreifen zu koennen...tja da schaut die Familie doof wenn es nur Codes zu Weihnachten gibt.

drdownload · 18 Oktober 2016, 06:47:09

Nachdem ich geizig bin würde ich natürlich gerne die Android-Devices gleich als Sinks verwenden

Meine Zonen (und was vorhanden ist)
Küche (Android-Tablet)
Wohnzimmer (Android Mediaplayer am AV-Verstärker)
Terrasse (USB-Audio an OpenWRT (hat aber noch nie wirklich funktioniert) am AV-Verstärker, 2. Kanal)
Gästezimmer (Android Mediaplayer an Soundbar)
Kinderzimmer soll für Kinder bedienbares Radio bekommen
Badezimmer sollte auch Musik bekommen (event. nur über Handy steuern)
Schlafzimmer same (FireTV-Stick mit Kodi am Fernseher)

Stream-Management

Wie gesagt, ich spiele schon länger rum, aber hatte noch nie ein sinnvolles Ergebnis, daher muss nicht alles richtig sein

Am Server für jede Zone eine MPD-Instanz mit einem Output und dann über pacmd ggf die sinks mergen oder trennen.

Projekte

Einen Ghettoblaster für die Kinder bauen mit eingebautem Tablet
RFID Reader zum Abspielen von Playlisten (http://www.rg42.org/wiki/rfid/mprfid)

unimatrix · 18 Oktober 2016, 10:23:53

mir ist keine Loesung bekannt um Pulseaudio auf Android zu "leiten". Hast du da was probiert? Man kann sicher RTP Streams abspielen und das Abspielen koennte man ueber FHEM / AMAD2 automatisieren. Ich hatte allerdings schonmal eine Lösung mit RPT und Multicast in meiner Vorversion und das hat total viel Bandbreite gebraucht, die Tunnel Sinks brauchen offenbar viel weniger. Das wird dann mit WLAN vll. schwierig. Außerdem wäre dann kein Sync sauber möglich.

Offenbar hat mal Arun Raghaven (einer der PA Entwickler) PA auf Android portiert aber das ist schon lange her, ich habe ihn mal angeschrieben...

Zählt für dich eine X10 Funkfernbedienung ohne Display als Radio für Kinder bedienbar? Also meine Kinder machen das und kommen gut klar (wenn sie einen Knopf drücken kommt ja Feedback per Audio, ist also interaktiv)

Ich werde jetzt mal ein FHEM Modul basteln was die Sinks dynamisch anlegt. Das sollte ich eigentlich hinbekommen. Bzw 2 Module. Ein Modul PA_Server und ein Modul PA_Client. Einem CLient wird per attr konfiguriert zu welchem Server er gehoert. Der Server ueberwacht dass PA ueberhaupt erstmal laeuft und schaut fuer jeden Client, ob er online ist, und wenn ja, legt er fuer jeden einen Sink an auf dem Server. Dann stelle ich mir das so vor dass man per "set <client> combine [<client2>]" einen Client an einen 2. Client anflanschen kann. Dadurch wird der Sink fuer den Client 2 ersetzt durch einen combine Sink der auf die tunnel-sinks von Client 1 und Client 2 geht.

Die MPD Instanzen sollen je nur noch einen Output haben und zwar jeweils einen eigenen Null-Sink. Dann kann man den Rest per move-sink-input machen. Dadurch kommt es zu keinem unerwarteten Verhalten wenn Clients einfach so offline gehen usw.

ich hoffe dieser Ansatz macht irgendwie Sinn...

Was du unter Stream Management schreibst geht mit meinem Code schon jetzt alles.

drdownload · 18 Oktober 2016, 13:26:14

Hi,

für Android hätte ich folgende App als Kandidaten noch gefunden aber selbst noch nicht getestet https://play.google.com/store/apps/details?id=com.kaytat.simpleprotocolplayer

unimatrix · 18 Oktober 2016, 14:13:04

danke schaue ich mir dann sicher mal an.

drdownload · 18 Oktober 2016, 18:10:00

Hi, ich bin jetzt mal früher zuhause und endlich dazugekommen genau durchzulesen + auf github das perl skript anzusehen, erstmal: Gratulation, das ist eine wirklich tolle Lösung die du da gebaut hast und dass du dir auch noch die Arbeit antust es zu refactoren um es tiefer in FHEM einzubauen.

Ich bin leider überhaupt nicht so der Perlmensch (Python, C# und PHP sind eher meins) - ich brauche immer 2h bis selbst 20 Zeilen myutils laufen

Meine Kinder sind erst 4 und 7 und bis jetzt ist ihre Musikauswahl CDs und Hörbücher von ihrem iPod, daher mein Gedanke das über ein Tablet zu steuern für die 2, mit dem iPod gehen sie schon super um.

Meine Bedienung für die "Normalverbraucher" ist auf Basis von Smartvisu.

Nachdem noch einige RPi1 rumliegen wäre es sicher auch möglich überall (zB mit 2 Soundkarten beim AV-Verstärker) einen richtigen Linux-Client zu haben (meine Geräte sind normalerweise Arch basieren außer dem Server (OMV/Debian)

unimatrix · 18 Oktober 2016, 19:38:56

Danke für das Feedback. Ja man muss aufpassen dass die Kinder nicht erwachsen sind, bis man die Software fertig entwickelt hat

(meine sind jetzt 9 und 12)

Grund für die FHEM Portierung ist ja die Hoffnung, das modularer machen zu können. Ein MPD Modul gibts schon. Das müsste ich leicht erweitern. Für die Visualisierung etc. könnte man viel vorhandenes Nutzen und es wäre eine integrierte Lösung. Ich hatte das damals in so einer Marathon Aktion innerhalb eines Wochenendes gebastelt und dann später nur noch kleine Bugs beseitigt.

Die erste Rohfassung meines FHEM Modules läuft schonmal. Dauert aber noch da alles non-blocking sein muss.

Die Lösung mit meiner Fernbedienung hat den Vorteil, dass die Kinder im Bett liegen und durch reines Ertasten das Ding steuern können. Hab da relativ viel Zeit investiert um die ganzen Pings, Blings, Zong, Dadaa, Dudeldidu usw Geräusche zu konfigurieren. Aber die Kinder hatten viel Spaß beim erstellen der MP3s. Denn da es ja keine Trackanzeige gibt habe ich so Sachen wie 150 Folgen Benjamin Blümchen ebenfalls modifiziert. Denn die fangen ja alle mit der gleichen Titelmusik an. Ich habe alle diese Hörspiel MP3s mit einer Titelansage versehen die am Anfang eingespielt wird. Alles von Kindern aufgesprochen.

FranzB94 · 19 Oktober 2016, 09:44:02

Hi unimatrix!

Zitat von: unimatrix am 18 Oktober 2016, 19:38:56
...Grund für die FHEM Portierung ist ja die Hoffnung, das modularer machen zu können. Ein MPD Modul gibts schon. Das müsste ich leicht erweitern. Für die Visualisierung etc. könnte man viel vorhandenes Nutzen und es wäre eine integrierte Lösung...

Erfahrungsgemäß kommt ja bei solchen "Prosa-Threads", wie es dieser bisher ist, nicht viel raus. Aber ich will mich auch mit dem Multiroom-Thema beschäftigen und deshalb lese ich hier mit.
Da du nun das MPD-Modul erwähnst, wird das Thema aus meiner Sicht interessant. Für die unterschiedlichste Multimedia-Hardware gibt es ja bereits fhem-Module. Den Sinn des MPD-Moduls hatte ich darin gesehen, diese Hardware zu steuern. Das Modul findet zwar unterschiedlichste Renderer, aber die Steuerung der Geräte funktioniert nur teilweise. Offenbar werden die XML-Dateien der Geräte nicht oder nur teilweise berücksichtigt?
Leider verstehe ich von der Programmierung noch viel zu wenig, bin aber sehr an diesem Thema interessiert und würde mich gern beteiligen.
Da du ja eine viel größere praktische Erfahrung mit dem Theme hast, wünsche ich dir viel erfolg. Hoffentlich kann ich praktisch auch estwas zur Realisierung beitragen.

Franz

drdownload · 19 Oktober 2016, 10:04:01

@Franz,

ich glaube du verwechselst da das MPD Modul mit DLNA/UPNP wo man immer die XMLs braucht.

Außerdem hat unimatrix schon eine lauffähige Version die er freundlicherweise für alle in FHEM Module umgestalten will.

@unimatrix

Fällt dir auch eine Lösung für Text-To-Speak ein?

unimatrix · 19 Oktober 2016, 10:36:50

TTS gibts ja offenbar schon was, was aber nur online geht. Ansonsten mp3 generieren und abspielen. Wollte ich noch mit einbauen weil ja nicht jeder voraufgenommene Dinge haben wird.

DLNA kenne ich mich überhaupt nicht mit aus und finde ich für meine Ansprüche uninteressant. Den Code vom MPD Module habe ich mir schon sehr genau angeschaut. Da kann man einfahc ein paar neue Befehle einbauen ohne dass es die Kompatibilität zur jetzigen Version stört.

Habe seit gestern Abend erste lauffähige FHEM Module aber die meiste Arbeit steckt noch in dem ganzen Handling von Ausnahmebedingungen z.B. wenn Geräte einfach abgeschaltet werden usw.

Wo ich sicher später Hilfe gebrauchen kann ist bei der Visualisierung. Ich bin vollkommen unkreativ. Da könnte man sich ein total cooles Widget für SmartVISU machen. Die bestehenden Widgets bieten dazu nicht alle notwendigen Funktionen.