FHEMWiki - Benutzerbeiträge [de]

Benutzer Diskussion:Drhirn

2017-01-29T12:25:14Z

Unimatrix27: Neuer Abschnitt /* OpenMultiroom */

== Willkommen! ==
{| width="100%" cellspacing="0" cellpadding="6" style="line-height: 20px; background: #E0E0E0; border: 2px solid #1874CD;"
|-
| colspan="4" style="background:#1874CD;" |<big><span style="color: #FAFAFA">'''Hallo Drhirn,''' willkommen im FHEM Wiki!</span></big>
|-
| colspan="4" | Danke für dein Interesse an unserem Projekt, ich freue mich schon auf deine weiteren Beiträge. Die folgenden Seiten sollten dir die ersten Schritte erleichtern, bitte nimm dir daher etwas Zeit, sie zu lesen.

----
'''FHEM-spezifische Informationen'''

|-
| width="8%" |  
| width="38%" | '''[[Systemübersicht]]'''<br />''FHEM Systemübersicht''
| width="8%" |  
| width="38%" | '''[[FHEMWiki:Über FHEMWiki]]'''<br />''Informationen über dieses Wiki''

|-
| colspan="4" |
----
'''Generelle Informationen über (Media)Wikis'''
|-
| width="8%" | [[Datei:Crystal Clear app kedit.svg|rechts|30px|link=Hilfe:Bearbeiten]]
| width="38%" | '''[[Hilfe:Bearbeiten]]'''<br />''Zugang zu allen wichtigen Informationen.''
| width="8%" | [[Datei:X-office-presentation.svg|rechts|30px|link=Wikipedia:Tutorial]]
| width="38%" | '''[http://de.wikipedia.org/wiki/Wikipedia:Tutorial Wikipedia:Tutorial]'''<br />''Schritt-für-Schritt-Anleitung für Einsteiger.''
|-
| [[Datei:Applications-system.svg|rechts|30px|link=Wikipedia:Grundprinzipien]]
| '''[http://de.wikipedia.org/wiki/Wikipedia:Grundprinzipien Wikipedia:Grundprinzipien]'''<br />''Die grundlegende Philosophie unseres Projekts.''
| [[Datei:MentorenProgrammLogo-7.svg|rechts|60px|link=Wikipedia:Mentorenprogramm]]
| '''[http://de.wikipedia.org/wiki/Wikipedia:Mentorenprogramm Wikipedia:Mentorenprogramm]'''<br />''Persönliche Einführung in die Beteiligung bei Wikipedia.''
|-
| colspan="4" |
----
Bitte beachte, [http://de.wikipedia.org/wiki/Wikipedia:Was_Wikipedia_nicht_ist was Wikipedia nicht ist], und "unterschreibe" deine Diskussionsbeiträge durch Eingabe von <code>--<nowiki>~~~~</nowiki></code> oder durch Drücken der Schaltfläche [[Datei:button_sig.png|Signaturknopf|20px|link=Hilfe:Signatur]] über dem Bearbeitungsfeld. Artikel werden jedoch nicht unterschrieben, und wofür die Zusammenfassungszeile da ist, erfährst du unter [http://de.wikipedia.org/wiki/Hilfe:Zusammenfassung_und_Quellen Zusammenfassung und Quellen]. <br /><br />
[[Datei:Nuvola apps ksirc.png|25px|link=Benutzer Diskussion:Ph1959de]]    '''Hast du Fragen an mich?''' Schreib mir auf [[Benutzer Diskussion:Ph1959de|<u>meiner</u> Diskussionsseite]]! Viele Grüße, [[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 21:08, 21. Sep. 2015 (CEST)
|}

== Wiki-Artikel und commandref ==

Hallo!

Im Artikel [[Jabber]] hast Du die deutsche commandref 1:1 in einen Wiki-Artikel überführt. Das ist mMn nicht der Sinn des Wikis. Das Wiki soll die commandref ergänzen und weitergehend erläutern, aber nicht kopieren. Solche Dopplungen machen die Pflege arbeitsaufwendig: bspw. müsste jede Änderung in der commandref übernommen werden (wer macht das?) und der Mehrwert zur ist nicht vorhanden. Genau aus diesem Grund gibt es auch die Infobox-Modul, die auf den passenden commandref-Abschnitt verweist. Eine Übernahme ist somit nicht notwendig. Es wäre schön, wenn Du Dir dazu noch einmal Gedanken machen könntest. Vielen Dank.

Auch wenn jetzt nur die Kritik geschrieben steht, ist das Wichtigste: Danke für Deine fleißige Mitarbeit. :-)

Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 14:08, 11. Jan. 2017 (CET)

:Ja, du hast vollkommen Recht. Hab auch schon fast vermutet, dass da Kritik kommt. Ich lebe in der Hoffnung, dass da noch Inhalte hinzugefügt werden. Aber eigentlich ist das Ganze nur entstanden, weil ich eine Seite "wikifizieren" wollte (wie ihr das so schön nennt :) ). Zu Jabber gab's noch nichts und eine leere Seite zu erstellen war mir dann auch zu frech.
:Ich geh aber in jedem Fall noch mal in mich.
:Super wäre natürlich eine Lösung, wie man die Inhalte der CommandRef automatisch ins Wiki übernehmen könnte. Da ist mir aber noch nichts schlaues dazu eingefallen. Und irgendwie gehe ich davon aus, dass das auch gar nicht erwünscht ist ;) --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 13:22, 12. Jan. 2017 (CET)

<HR>
::Klar könnten wir die commandref automatisch übernehmen. Ich sehe darin aber keine Notwendigkeit und keinen Nutzen, da man die mit einem Klick in einem separaten Fenster als HTML öffnen kann. Das halte ich für mindestens genauso komfortabel wie ein separate Wiki-Seite. Wenn man es übernehmen würde, dann müsste die Übernahme täglich aktualisiert werden; man müsste verhindern, dass jeder Wiki-Schreiber an der commandref-Wiki-Seite etwas ändern kann,usw. Das würde viel Pflege- und Arbeitsaufwand für eine Übernahme-Schnittstelle bedeuten, die eigentlich nichts zusätzliches bringt.
::Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 10:15, 17. Jan. 2017 (CET)Christian

<hr>
:::Man müsste die übernommenen CR-Artikel irgendwie sperren können. MediaWiki sieht das allerdings leider nicht vor.
:::Ich persönlich habe leichte Bedienungsprobleme mit der CommandRef. Mich macht z.B. die laaange Ladezeit fertig. Und ich ordne gerne Fenster nebeneinander an. Wenn man also die CR im "Vollbild" liest und dann das Browser-Fenster auf die Hälfte des Bildschirms verkleinert, scrollt die CR irgendwo hin und man kann den Anker erst recht wieder suchen. Finde ich einfach unpraktisch. Eine kurze Seite pro Modul z.B. im Wiki wäre einfacher.
:::Gruß, --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 10:24, 17. Jan. 2017 (CET)

== Änderungen in (Kategorisierung) von Vorlagen ==

Hallo Drhirn,

ich habe gerade zwei von Dir gemachte Änderungen an Vorlagen rückgängig gemacht. Zur Erläuterung: alle FHEM-Wiki spezifischen Vorlagen sind entsprechend den Beispielen in https://de.wikipedia.org/wiki/Kategorie:Vorlage: einsortiert. Solange es damit keine Probleme gibt oder trifitige Gründe, das anders zu machen, möchte ich Dich bitten, das so zu belassen, ansonsten Änderungen bitte vorher im Rahmen einer Diskussion zu klären. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:13, 16. Jan. 2017 (CET)
<hr>
:Hi,
:Grund 1: Der Doppelpunkt am Schluss ("Kategorie:Vorlage:") gehört da eigentlich nicht hin (aus technischer Sicht). Wenn ihr da aber einen Grund dafür habt, entschuldige ich mich für's vorschnelle Editieren.
:Grund 2: Vorlagen in eine Kategorie "Vorlagen" einzuordnen ist zwar manchmal praktisch, aber eigentlich nicht notwendig. Wenn man schnell alle Vorlagen angezeigt bekommen möchte, geht das einfacher über "Alle Seiten -> Namensraum 'Vorlage'".
:Gruß
:--[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 12:42, 16. Jan. 2017 (CET)

== Kategorie für Serversoftware ==

Hallo Stefan!

Du hattest hier: https://forum.fhem.de/index.php/topic,64682.msg559529.html#msg559529 bezüglich neuer Kategorie angefragt. Mir ist nicht klar, wo Du diese Kategorie einordnen willst. Solche Artikel würden aktuell bspw. in HowTos passen. Da es sich nicht um FHEM-spezifische Artikel handelt, möchte ich die auch nicht in den Vordergrund des FHEM Wikis durch spezielle Kategorien schieben. Diese Artikel drohen regelmäßig schnell zu veralten, da die Zielgruppe und damit auch potentielle Mitschreiber normalerweise relativ klein ist. Das bedeutet nicht, dass diese Artikel nicht geschrieben werden sollen/dürfen, sondern ich möchte nur die Probleme in langfristiger Sicht aufzeigen.

Das deckt sich ein wenig mit dem von Dir bemängelten Linux Init-Artikel. Der Artikel ist nur indirekt FHEM-bezogen und es kümmert sich keiner so richtig darum. Ich mag da nicht einsteigen, da es mich nicht betrifft und interessiert. Finde so etwas kann man besser als Hinweis auf ein externes Linux-Wiki verlinken. Dort gibt es kompetente Wiki-Schreiber, die einen solchen Artikel pflegen.

Grundsätzlich bin ich der Meinung, dass wir mit der vorhandenen Kategorisierung klar kommen sollten, um es nicht zu komplex zu gestalten.

Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 10:02, 17. Jan. 2017 (CET)
<hr>
:Ok, gute Argumente.
:Eventuell die HowTos untergliedern?
:LG, --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 10:24, 17. Jan. 2017 (CET)

== OpenMultiroom ==

Sorry, das war ein Versehen, ich habe deine Änderungen wieder eingebaut, danke dafür. Hatte die Datei noch im Offline-Editor offen und habe etwas vorschnell gespeichert.

OpenMultiroom

2017-01-29T12:23:23Z

Unimatrix27: Änderungen von Drhirn wieder rein (by SublimeText.Mediawiker) (by SublimeText.Mediawiker)

<div style="float:right">{{Infobox Modul
|ModPurpose=Steuern der einzelnen Multiroom-Systemkomponenten
|ModType=d
|ModCmdRef=OpenMultiroom
|ModForumArea=Multimedia
|ModTechName=98_OpenMultiroom.pm
|ModOwner=unimatrix
}}
{{Infobox Modul
|ModPurpose=Steuern eines Snapcast-Servers
|ModType=d
|ModCmdRef=Snapcast
|ModForumArea=Multimedia
|ModTechName=96_Snapcast.pm
|ModOwner=unimatrix
}}
[[Datei:OpenMultiroomOverview.png|mini|400px|Schaubild des Zusammenspiels der einzelnen Komponenten eines Multiroomsystems mit den Backends [https://forum.fhem.de/index.php/topic,18517.msg MPD] und [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] sowie der Nutzung von Text2Speech]]
</div>

Achtung: Das Modul ist noch sehr neu und bisher nur im Forum / auf dem Github des Autors verfügbar. Sobald alles stabil ist, wird es im SVN eingestellt.

'''OpenMultiroom''' ist ein Steuerungsmodul sowie auch ein Gesamtkonzept zur Realisierung eines Multiroom-Audio-Systems unter Nutzung von ausschließlich frei verfügbarer Software und ohne Bezug auf die Hardware eines bestimmten Herstellers. Es ist so ausgelegt, dass es prinzipiell flexibel bezüglich der Auswahl der Backendsysteme ist. Zurzeit ist es für die Nutzung mit [https://www.musicpd.org/ MPD] bzw. [https://www.mopidy.com/ Mopidy] und [https://github.com/badaix/snapcast Snapcast] implementiert. Daher wird in diesem WIKI-Eintrag immer von diesen Systemen gesprochen. Einen grundsätzlichen Überblick über das Konzept bietet das Schaubild.

== Grobe Übersicht des Funktionsumfangs der Gesamtlösung==
=== Features ===
* Integrierte Steuerung des Musikplayers über das [[MPD]]-Modul sowie des Multiroom-System [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] in einem einzigen Modul
* Implementierung einer Schnittstelle gemäß [[DevelopmentGuidelinesAV]] als Basis für eine Visualisierung mit z.B. [[SmartVisu]] oder [FHEM Tablet UI]]
* Synchrones Playback auf z.B. Raspberry Pi oder Android-Geräten (Snapcast-Feature)
* optionale Komprimierung der Soundübertragung als OGG oder FLAC (Snapcast-Feature)
* Möglichkeit der Bedienung völlig ohne Display über eine Fernbedienung und entsprechender Text2Speech Rückmeldung, insbesondere
** Durschalten von Playlisten mit entsprechenden Channel - Tasten unter Nutzung von raumspezifischen Filtern
** Forward und Rewind mit definierbaren Sprungweiten (implementiert direkt im [[MPD]]-Modul)
** Direktanwahl von Playlisten, Tracks oder Trackpositionen durch Zifferneingabe und anschließende Funktionstaste
** Abfrage von Statusinformationen durch Funktionstasten und Text2Speech Rückmeldungen
** Mithören in anderen Räumen und Übernahme des Playerzustandes anderer Räume durch Nutzung von Funktionstasten
** Einschlaftimer per Zifferneingabe oder per vordefinierten Zeitabständen, hierbei wird auch die Restlaufzeit des aktuellen Tracks angeboten.
* manuelles oder automatisches Speichern und Laden von Playlistbookmarks (implementiert direkt im [[MPD]]-Modul)
* Möglichkeit der Festlegung von tageszeit- und tagestypabhängigen Lautstärkebegrenzungen bis auf 0% z.B. für Kinderzimmer
* individuelles Verwalten von Playlisten für verschiedene Familienmitglieder
* Nutzung des Audiosystems für systemunabhängige FHEM-Announcements. Ein entsprechendes Announcement-Modul ist in Planung. Dabei können mehrere Räume gleichzeitig oder auch getrennt angesprochen werden

=== Anwendungszweck und Kurzbeschreibung der Funktionsweise ===
Wie der Name des Systems vermuten lässt, ist die Lösung vor allem dann sinnvoll einzusetzen, wenn Audiodateien in mindestens 2 verschiedenen Räumen oder "Zonen" sowohl synchron als auch unabhängig abgespielt werden soll und wenn hierzu eine komfortable und integrierte Steuerung über FHEM verwendet werden soll. Mit Einschränkungen ist die Lösung auch dann sinnvoll, wenn es nur um das Abspielen in einem Raum geht. Hier kann dann z.B. die Steuerung über eine Fernbedienung mit Hilfe des '''OpenMultiroom'''-Moduls genutzt werden, die über eine reine Nutzung des MPD-Moduls hinausgeht.

Für die Nutzung ist nicht zwingend ein zentraler Server notwendig. Diese Rolle kann auch von einem der Clients übernommen werden, z.B. einem Pi. Zur einfacheren Darstellung wird in diesem Eintrag jedoch immer von der Nutzung eines Servers ausgegangen, der nicht gleichzeitig auch Client ist.

Das Abspielen von Audio funktioniert prinzipiell in 2 Stufen:
# Nutzung von MPD oder einem MPD-kompatiblen Player zum direkten Abspielen von Sounddateien. Pro existierendem Raum gibt es mindestens eine Instanz von MPD. Hier wird davon ausgegangen, dass es genau eine Instanz pro Raum gibt. Jeder Raum hat also "seinen" MPD.
# Nutzung von Snapcast zur Verteilung des von MPD abgespielten Sounds an den entsprechenden Raum. Snapcast übernimmt hierbei die zeitliche Synchronisation

Durch das Modul '''OpenMultiroom''' steuert der Nutzer sowohl MPD als auch Snapcast. Für jeden Raum wird eine Instanz des Moduls definiert.

=== Verwendete komponenten ===
Folgende Komponenten kommen zum Einsatz:

==== Server: ====
* MPD oder Mopidy oder ein anderer MPD-kompatibler Player. 1 Instanz pro Raum
* Snapserver
* mplayer (bei Nutzung von Text 2 Speech)
* Optional Pulseaudio (im System-Mode) bei Nutzung von Text 2 Speech oder erweiterten Konfigurationen. Hierbei wird Pulseaudio zwischen MPD und Snapcast geschaltet.
* Optional Anbindung an Subsonic oder Libresonic (hier zurzeit nicht beschrieben) zur Synchronisation von Playlisten uvm.
* FHEM: Modul 98_OpenMultiroom.pm
* FHEM: Modul 96_Snapcast.pm
* FHEM: Modul [[MPD|73_MPD.pm]]
* FHEM: Optional Modul 98_Text2Speech.pm

==== Client: ====
* Linux: Alsa oder Pulseaudio zur Soundwiedergabe
* Linux: Snapclient
* Android: Nur der Android Snapclient
* Webbrowser zur Steuerung per Visualisierung
* ggf. Infrarot oder Funkfernbedienung. In diesem Artikel wird das Beispiel anhand der Nutzung von X10-Funkfernbedienungen gezeigt, diese gibt es sehr günstig in der Bucht o.ä.
* Vision: Nutzung von Tastern und Display am PI oder Nutzung eines Steuergerätes mit Tastern und Display auf Basis eines Arduino mit WLAN, z.B. im alten Gehäuse eines Küchenradios usw.

== Aufbau anhand einer vollständigen Beispielkonfiguration ==

In diesem Artikel soll beispielhaft eine vollständige Konfiguration gezeigt werden. Jeder Nutzer muss diese Konfiguration an seine eigenen Bedürfnisse anpassen. Es seien folgende Komponenten vorhanden:

* Server mit Ubuntu 16.04, hier befindet sich eine MP3-Sammlung
* Kind1: Raspberry Pi Model 1 mit Raspbian
* Kind2: BananaPi mit Ubuntu, an diesem Pi ist auch ein X10 Empfänger angeschlossen, da er zentral im Haus positioniert ist
* Wohnzimmer: Raspberry Pi3 mit OSMC und KODI, wird primär zum Fernsehen verwendet
* Küche: Raspberry Pi Model 1 mit Raspbian

Anmerkung: Es ist möglich, mehrere Räume mit nur einem physikalischen Client zu bedienen. Hierbei werden auf einem Client mehrere Instanzen des Snapclients laufen gelassen. Der physikalische Client hat dann z.B. mehrere USB Soundkarten, dessen Audioausgänge in verschiedene Räume verkabelt sind. Dies wird hier zurzeit nicht näher beschrieben.

=== Pulseaudio Konfiguration ===
Will man Pulseaudio verwenden, z.B. um Text2Speech Nachrichten in laufende Musik einzublenden, sollte dieses am besten zuerst konfiguriert werden. Pulseaudio muss hierzu im System-Mode laufen. Dies ist auf einem Headless-Server kein Problem. Bei Ubuntu 16.10 wird dies durch folgenden Inhalt in ''/etc/systemd/system/pulseaudio.server'' erreicht:
<source lang="bash">
[Unit]
Description=PA
After=network.target sound.target

[Service]
ExecStart=/usr/bin/pulseaudio --system

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>
Weiterhin ist der Befehl
<source lang="bash">sudo systemctl enable pulseaudio</source>
einzugeben, um Pulseaudio beim Systemstart automatisch zu starten.

Ausgehend von der Standardkonfiguration werden nun in ''/etc/pulse/system.pa'' die benötigten Module eingetragen
<source lang="bash">
load-module module-pipe-sink file=/tmp/wohn.fifo sink_name=wohn
load-module module-pipe-sink file=/tmp/kind1.fifo sink_name=kind1
load-module module-pipe-sink file=/tmp/kind2.fifo sink_name=kind2
load-module module-pipe-sink file=/tmp/kueche.fifo sink_name=kueche

load-module module-combine-sink slaves=kind1,kind2 sink_name=kinder
load-module module-combine-sink slaves=wohn,kueche sink_name=unten
load-module module-combine-sink slaves=wohn,kueche,kind1,kind2 sink_name=alle

pactl load-module module-role-ducking trigger_roles=announcement ducking_roles=music
</source>
Snapcast benötigt die Audioquelle in Form von FIFOs. Daher wird hier in den erstem 4 Zeilen je ein FIFO von Pulseaudio erzeugt. Der sink_name wird später bei der Konfiguration von MPD als Ausgang verwendet. In den 3 weiteren Zeilen werden noch 3 Sinks als Combine-Sinks erstellt. Diese erzeugen keine neuen FIFOs, sondern omrhen under entsprechenden Sink-Namen eine vorgegebene Kombination von Räumen nach außen hin verfügbar. Der Sink "alle" kann also genutzt werden, um Audio auf allen 4 FIFOs gleichzeitig abzuspielen (und somit später potentiall in allen Räumen gleichzeitig). Dies kann für Announcements sinnvoll sein. Die Nutzung dieser Combine-Sinks ist optional. Ebenso optional ist das Laden des Ducking-Moduls am Ende. Das Ducking Modul führt dazu, dass Pulseaudio automatisch die Lautstärke der durch MPD abgespielten Tracks absenkt, wenn etwas über die Text2Speech-Module abgespielt wird. Ohne dies sind die Ausgaben speziell über die Google API unter Umständen nur schwer hörbar.

=== Snapcast Konfiguration ===
[https://github.com/badaix/snapcast Snapcast] muss entsprechend der Angaben auf der Webseite installiert werden. Auf dem Server muss logischerweise die Serverkomponente und auf den Clients die Clientkomponente installiert werden. Bei Android-Clients wird die auf der Webseite zur Verfügung gestellt APK installiert. Snapcast befindet sich selbst noch in fortlaufender Entwicklung. Die hier vorgestellte Lösung ist mit [https://github.com/badaix/snapcast/tree/98be8a58d945f84af50e40ebcf8a774592dd6e7b dieser Version] kompatibel und getestet.

Die Konfiguration des Servers beschränkt sich auf die Definition der Streams in ''/etc/default/snapserver''
<source lang="bash">
START_SNAPSERVER=true
SNAPSERVER_OPTS="-d -s pipe:///tmp/kind1.fifo?name=kind1&mode=read -s pipe:///tmp/kind2.fifo?name=kind2&mode=read -s pipe:///tmp/wohn.fifo?name=wohn&mode=read -s pipe:///tmp/kueche.fifo?name=kueche&mode=read"
</source>
Hier werden die 4 Streams erstellt, diese entsprechen vom Dateinamen her der Pulseaudiokonfiguration. Der hier verwendete Name kann später in FHEM oder auch im Android-Client angezeigt werden. Die Option <pre>mode=read</pre> ist wichtig, weil Pulseaudio meckert, wenn es die FIFO-Dateien nicht selbst anlegen darf.

Auf der Clientseite sieht die Datei ''/etc/default/snapclient'' dann so aus:
<source lang="bash">
START_SNAPCLIENT=true
SNAPCLIENT_OPTS="-d -s dmix:CARD=Aureon51MkII,DEV=0"
</source>
Den Server findet der Snapclient automatisch, er kann aber auch angegeben werden. Wie hier zu sehen kann ein spezielles Output-Device angegeben werden. Dies ist bei den PIs mit externer USB-Soundkarte meistens notwendig, da ansonsten der interne Sound genutzt würde. Eine Liste der verfügbaren Devices wird mit dem Aufruf von <pre>snapclient -l</pre> ausgegeben, hier muss dann das passende genommen werden. GGf. so lange ausprobieren, bis der Sound an der richtigen Stelle rauskommt.

In der hier betrachteten Konfiguration soll auf dem Wohnzimmer-PI ein Snapclient laufen, dieser wird aber normalerweise zum TV und Filme schauen mit KODI verwendet. Sowohl KODI als auch der Snapclient blockieren aber das ALSA-Device und funktionieren beide meistens entweder gar nicht oder nicht richtig zusammen, insbesondere dann nicht, wenn von KODI Mehrkanalsound oder sogar Passthrough ausgegeben wird. Die Entwicklung eines nativen Snapcast-Clients innerhalb von KODI wird gerade an verschiedenen Stellen diskutiert, z.B. [https://github.com/badaix/snapcast/issues/155 hier]. Bis dahin kann ein kleiner Workaround Abhilfe schaffen. Mit folgendem (nur rudimentär getesteten) [https://github.com/unimatrix27/snapcast/commit/88e42a2ecc8b44223701e18abb63af04b673b67b Hack] für den Snapcast-Client wird erreicht, dass der Client das ALSA-Device frei gibt, sobald er über den Server auf Mute gestellt wird. KODI selbst gibt das Device ebenfalls frei, wenn es im Zustand "Stop" ist. Bei dieser Lösung kann der Snapclient auf dem KODI-Rechner immer laufen gelassen werde. Es ist jedoch in der Verantwortung des Benutzers, den Client zu "muten". Vergisst er dies, wird ggf. die Wiedergabe in KODI nicht möglich sein.

Nach Abschluss der Snapcastkonfiguration und dem Starten von Server und den Clients empfiehlt es sich, die Android-App ebenfalls zu verwenden, da diese einen schnellen Überblick über den Zustand des Servers, der konfigurierten Streams und der Clients bietet.

=== Mopidy Konfiguration ===

In diesem Beispiel wird Mopidy als MPD-Ersatz verwendet, genau so gut kann aber auch direkt MPD verwendet werden. Die genauen Konfigurationsoptionen sind natürlich anders, und jeweils in entsprechenden Tutorials oder Dokumentationen beschrieben. Mopidy ist relativ umfangreich und modular aufgebaut, es bietet u.a. die Möglichkeit, neben lokal gespeicherten Dateien auch Dateien von verschiedenen, teilweise kommerziellen, Streamingdiensten abzuspielen. Die Detailkonfiguration all dieser Komponenten geht über diesen Artikel hinaus. Entscheidend hier ist die Konfiguration in einer Weise, so dass mehrere Mopidy-Instanzen gleichzeitig ausgeführt werden können und dann auf unterschiedlichen Ports zur Verfügung stehen.

Nach Installation von Mopidy findet sich die Konfiguration in der Datei ''/etc/mopidy/mopidy.cfg''. Mopidy unterstützt hierarische Konfigurationen, es reicht also, den für jede Instanz spezifischen Teil aus dieser allgemeinen Konfiguration zu entfernen und in jeweils eigene Dateien zu verschieben. In diesem Beispiel sollen das die Dateien ''/etc/mopidy/kind1.conf'' bis ''/etc/mopidy/kueche.conf'' sein. Die folgenden Zeilen gehören jeweils in diese 4 Dateien und werden dort entsprechend angepasst. Hier das Beispiel für Kind2:

<source lang="bash">
[logging]
config_file = /etc/mopidy/logging_kind2.conf
debug_file = /var/log/mopidy/mopidy-debug_kind2.log

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! pulsesink device=kind2 stream-properties="props,media.role=music"

[mpd]
enabled = true
hostname = 0.0.0.0
port=6601

[http]
enabled = true
hostname = 0.0.0.0
port=6681
zeroconf = Musik Kind2
</source>

Im Audioteil wird der entsprechende Sink aus der Pulseaudiokonfiguration genommen. Die Angabe von stream-properties ermöglicht dem Duck-Modul den Stream als Musik zu erkennen und beim Abspielen von Announcements in der Lautstärke abzusenken. Beim MPD muss der Port für jede Instanz unterschiedlich sein, ebenso beim HTTP-Modul für die Weboberfläche der jeweiligen Instanz. Der Zerokonfname sollte auch eindeutig sein. Neben dieser Datei ist noch die dazu passende logging-Konfiguration anzulegen, hier also ''/etc/mopidy/logging_kind2.conf''. Dazu wird die Standarddatei kopiert und darin nur der Name der Logdatei angepasst.

Um nun auch die entsprechende Anzahl Instanzen automatisch zu starten, sind die entsprechenden Startdateien anzulegen. Dazu kann die Datei ''/etc/systemd/system/mopidy.cfg'' z.B. in ''/etc/systemd/system/mopidy_kind1.cfg'' umbenannt werden und dann 3 mal mit den Endungen der anderen Instanzen kopiert werden. Der Inhalt ist dann wie folgt:

<source lang="bash">
[Unit]
Description=Mopidy_kind1
After=network.target sound.target

[Service]
EnvironmentFile=/etc/default/mopidy
ExecStart=/usr/bin/mopidy --quiet --config /etc/mopidy/kind1.conf

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>

Abschließend sollten die 4 Instanzen durch den Aufruf von <pre>systemctl enable mopidy_kind1</pre> usw. aktiviert werden. Es empfiehlt sich nach dem Start von Mopidy die korrekte Funtkionsweise mit dem [https://www.musicpd.org/clients/mpc/ MPC]-Client oder mit [http://rybczak.net/ncmpcpp/ NCMPCPP] auf der Konsole zu testen.

Hierbei sollte es dann bereits möglich sein, die Multiroom-Fähigkeiten von Snapcast mit Hilfe des Android-Clients von Snapcast zu testen und so auch festzustellen, dass die restliche Konfiguration von Snapcast und Pulseaudio korrekt sind.

=== FHEM ===

In FHEM sind nun in der ''fhem.cfg'' die entsprechenden Module einzurichten:
* Ein Snapcast-Modul im Server Modus
* Pro Raum ein Snapcast-Modul im Clientmodus
* Pro Raum ein MPD-Modul
* Pro Raum ein OpenMultiroom-Modul
* Optional pro Raum ein Text2Speech-Modul
* weitere Text2Speech-Module, falls man diese in Pulseaudio mit dem per Combine-Sink vorgesehen hat.

<source lang="bash">
define scs.snap Snapcast

define scc.kind1 Snapcast client scs.snap b827eb9aec84
attr scc.kind1 constraintDummy freestring
attr scc.kind1 constraints standard|07:00 0 20:00 100 21:00 50 21:30 30 24:00 0,beforefree|07:00 0 21:00 100 22:00 50 23:00 30 24:00 0,beforeschool|07:00 0 08:30 50 20:00 100 21:00 50 21:30 30 24:00 0,free|07:00 0 08:30 50 21:00 100 22:00 50 23:00 30 24:00 0

define scc.kind2 Snapcast client scs.snap 025009413c29
attr scc.kind2 constraintDummy freestring
attr scc.kind2 constraints standard|07:00 0 20:15 100 20:30 50 24:00 0,beforefree|07:00 0 21:00 100 22:30 50 24:00 0,beforeschool|07:00 0 08:30 50 20:15 100 20:30 50 24:00 0,free|07:00 0 08:30 50 21:00 100 22:30 50 24:00 0

define scc.kueche Snapcast client scs.snap b827eb9a2ad3

define scc.wohn Snapcast client scs.snap 00aefa4aa3a9
</source>

Oben zu sehen ist das define für das Server-Modul. Ohne Parameter verbindet sich mit localhost auf dem Standardport 1705. Es folgt die Definition von 2 Clients. Der erste Parameter "client" versetzt das Snapcastmodul in den Clientmodus. Der zweite Parameter verweist auf das Servermodul, der dritte Parameter ist die Client-ID. Diese besteht bei der aktuellen Snapcast-Version meistens aus der MAC-Adresse des Clients. Für die Kinder werden noch die Attribute constraintDummy ond constraints vergeben. Hiermit wird eine tagestyp- und tageszeitabhängige Lautstärkebegrenzung konfiguriert. Für die vier Tagestypen "standard", "beforefree", "beforeschool" und "free" wird ein jeweils anderes Lautstärkezeitprofil definiert.

Das Zeitprofil wird hier nach dem gleichen Muster wie die Temperaturlisten der Homematic-Thermostate, erklärt hier: [HomeMatic_Type_Thermostat]. Für den Tagestyp wird zusätzlich das Attribut constraintDummy verwendet. Es definiert, dass in dem Dummy "freestring" jeweils drin steht, welcher Tagestyp gerade ist. Diese Variable wirkt somit als Selektor auf die Liste der erlaubten Maximallautstärken. Wie eine solche Dummyvariable jeweils mit einem entsprechenden Wert befüllt werden kann, z.B. abhängig vom Wochentag, von Schulferien oder Feiertagen, wird hier nicht erläutert. Es ist auch möglich, nur ein Lautstärkeprofil anzugeben. Ohne dass ein Attribut constraintDummy gesetzt ist, verwendet das Snapcastmodul immer den Wert "standard". Wie man hier sehen kann, gibt es im Beispiel 4 Typen, hierbei fallen Freitage normalerweise in die Kategorie "beforefree" (es sind Tage, bevor dann frei ist, es kann also typischerweise länger und lauter Musik gehört werden), Samstage normalerweise in die Kategorie "free" und Sonntage in die Kategorie "beforeschool", ebenso landen dort Feiertage vor Schultagen usw.

<source lang="bash">
define tts.wohn Text2Speech pulsewohn
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.wohn TTS_UseMP3Wrap true
attr tts.wohn TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120

define tts.kind1 Text2Speech pulsekind1
attr tts.kind1 TTS_FileTemplateDir /data/misc/announcements/
attr tts.kind1 TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.kind1 TTS_UseMP3Wrap true

define tts.kind2 Text2Speech pulsekind2
attr tts.kind2 TTS_FileTemplateDir /data/misc/announcements/
attr tts.kind2 TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.kind2 TTS_UseMP3Wrap true

define tts.kueche Text2Speech pulsekueche
attr tts.kueche TTS_FileTemplateDir /data/misc/announcements/
attr tts.kueche TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.kueche TTS_UseMP3Wrap true

define tts.kinder Text2Speech pulsekinder
attr tts.kinder TTS_FileTemplateDir /data/misc/announcements/
attr tts.kinder TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.kinder TTS_UseMP3Wrap true

define tts.unten Text2Speech pulseunten
attr tts.unten TTS_FileTemplateDir /data/misc/announcements/
attr tts.unten TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.unten TTS_UseMP3Wrap true

define tts.alle Text2Speech pulsealle
attr tts.alle TTS_FileTemplateDir /data/misc/announcements/
attr tts.alle TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.alle TTS_UseMP3Wrap true
</source>
Hier sind die Definitionen der Text2Speech Module zu sehen (optional). Sie werden jeweils mit den in Pulseaudio definierten Sinks verbunden. Die Nutzung eines TemplateDirs ist ebenfalls optional, hier können bereits fertige MP3s verwendet werden, die dann anstelle der von der Google TTS API erzeugten Dateien benutzt werden. Dies können auch Bestätigungs und Fehlertöne sein, die bei Benutzern ohne Display, die rein mit Fernbedienung arbeiten, auf Fehlbedienungen etc. aufmerksam zu omrhen. Der Aufruf von mplayer wird noch modifiziert, um dafür zu sorgen, dass die Ausgabe bei Pulseaudio als media.role "announcement" eingehen. Dies wird dann vom duck-Modul erkannt, und führt dazu, dass die Lautstärke der ggf. ablaufenden Musik, etc. abgesenkt wird, so lange die tts-Ausgabe läuft.

<source lang="bash">
define mpd.kind1 MPD 192.168.2.2 6600
attr mpd.kind1 player mopidy
attr mpd.kind1 bookmarkDir mpdstates
attr mpd.kind1 autoBookmark 1

define mpd.kind2 MPD 192.168.2.2 6702
attr mpd.kind2 player mopidy
attr mpd.kind2 bookmarkDir mpdstates
attr mpd.kind2 autoBookmark 1

define mpd.kueche MPD 192.168.2.2 6703
attr mpd.kueche player mopidy
attr mpd.kueche bookmarkDir mpdstates
attr mpd.kueche autoBookmark 1

define mpd.wohn MPD 192.168.2.2 6704
attr mpd.wohn player mopidy
attr mpd.wohn bookmarkDir mpdstates
attr mpd.wohn autoBookmark 1
</source>
Pro laufender MPD oder Mopidy-Instanz wird ein MPD-Modul eingerichtet. Der Hostname und die Ports sind entsprechend anzupassen. Durch die bookmarkDir und autoBookmark - Attribute wird erreicht, dass der Zustand von Playlisten beim Wechsel derselben gespeichert und später wiederhergestellt werden kann. So lässt sich das Hören eines Hörbuchs unterbrechen, auf z.B. eine Radiostreamplayliste schalten, um dann später zur gleichen Stelle im Hörbuch zurückzukehren.

<source lang="bash">
define omr.kind1 OpenMultiroom
attr omr.kind1 mr scc.kind1
attr omr.kind1 soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.kind1 playlistPattern kind1
attr omr.kind1 ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.kind1 defaultTts tts.kind1
attr omr.kind1 defaultStream kind1
attr omr.kind1 defaultSound mpd.kind1

define omr.kind2 OpenMultiroom
attr omr.kind2 mr scc.kind2
attr omr.kind2 soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.kind2 playlistPattern kind2
attr omr.kind2 ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.kind2 defaultTts tts.kind2
attr omr.kind2 defaultStream kind2
attr omr.kind2 defaultSound mpd.kind2

define omr.kueche OpenMultiroom
attr omr.kueche mr scc.kueche
attr omr.kueche soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.kueche playlistPattern wohn
attr omr.kueche ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.kueche defaultTts tts.kueche
attr omr.kueche defaultStream kueche
attr omr.kueche defaultSound mpd.kueche

define omr.wohn OpenMultiroom
attr omr.wohn mr scc.wohn
attr omr.wohn soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.wohn playlistPattern wohn
attr omr.wohn ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.wohn defaultTts tts.wohn
attr omr.wohn defaultStream wohn
attr omr.wohn defaultSound mpd.wohn
</source>
Die Konfiguration der OpenMultiroom-Module schließt die Einrichtung von FHEM ab. Jede Instanz benötigt mindestens das "mr"- und das "soundMapping"-Attribut. Nur so kann sich das Modul mit den entsprechenden Snapcast und MPD-Modulen verbinden. Durch das "mr"-Attribut wird ein OpenMultiroom-Modul einem Snapcast-Client-Modul fest zugeordnet. Das Soundmapping ordnet die in Snapcast definierten Streams (siehe oben, Konfiguration vom Snapserver) den entsprechenden Instanzen des MPD-Moduls zu. Dadurch weiß FHEM, welcher MPD auf welchem Stream abspielt und kann je nachdem, welchem Stream ein Raum gerade zuhört, den dazu passenden MPD steuern und seine Readings durchreichen. Das OpenMultiroom-Modul bildet alle Readings des MPD-Moduls nochmal direkt ab. Wechselt ein Benutzer aber den Stream, dem er zuhört, aktualisieren sich auch alle Readings dementsprechend mit denen des dann aktuellen MPD-Moduls.

Das Attribut playlistPattern ist optional und sorgt dafür, dass beim Durchschalten der Playlists mit den Kommandos "channelUp" und "channelDown" nur diejenigen Playlists berücksichtigt werden, die auf das Pattern passen.

Analog zum soundMapping definiert das Attribut ttsMapping die Zuordnung der TTS-Module zu den Streams. Beim Ausgeben von Announcement kann so das OpenMultiroom-Modul ermitteln, auf welchem Stream welcher Raum gerade zuhört, und wo dementsprechend die TTS-Ausgaben zu erzeugen sind, damit sie auch in den gewünschten Räumen ankommen. Dieser Umweg ist zurzeit nötig, da ein Snapcast-Client nur auf einem einzigen Stream lauschen kann. Lauschen noch andere Clients auf demselben Stream, hören sie allerdings zwangsweise auch die Announcements.

Die 3 Default-Attribute legen fest, welche der TTS-Module, welcher Stream und welcher MPD dem entsprechenden Modul fest zugeordnet sind. Dies wird u.a. von einer Resetfunktion im Modul verwendet.

== Bedienung des OpenMultiroom-Moduls ==

=== set-Kommandos ===

=== Readings ===

=== Attribute ===

== Anbindung einer Fernbedienung an ein OpenMultiroom-Modul ==

=== Konfiguration von LIRC und IRExec ===

=== Zuordnung der Tasten: Beispiel ===

[[Category:Examples]]
[[Category:HOWTOS]]
[[Category:Unterhaltungselektronik]]

ABFALL

2017-01-29T12:18:02Z

Unimatrix27: Zweites Beispiel für Tablet UI eingefügt (by SublimeText.Mediawiker) (by SublimeText.Mediawiker)

{{Infobox Modul
|ModPurpose=Filtern von (Abfall-)Terminen aus einem Calendar.
|ModType=x
|ModFTopic=48237
|ModForumArea=Codeschnipsel
|ModTechName=57_ABFALL.pm
|ModOwner=Constantin / {{Link2FU|14026|uniqueck}}
}}

[[ABFALL]] ist ein (inoffizielles, nicht Bestandteil der Distribution) Hilfsmodul, das bestimmte Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt.

== Voraussetzungen ==
Es muss ein Calendar-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des ABFALL-Objekts spezifiziert werden.
Es können auch mehrere Calendar Objekte übergeben werden.

Sonderzeichen aus dem Namen der Termine, werden entfernt um die Namen der generierten Readings FHEM tauglich zu machen, für die Werte der Readings bleiben diese allerdings erhalten.

== Anwendung ==
=== Installation ===
Mit folgendem Befehl kann das Modul direkt in den Standard FHEM Update Prozess eingeklinkt werden.
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code>
Um es nur zu installieren, kann auch einfach nur das Command
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code>
eingegeben werden.

=== Entwicklungsstrang ===
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code>
bzw.
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code>

=== Define ===
:<code>define <Name> ABFALL <calendarname>,<calendarname2>,...</code>

Erläuterung der Parameter im '''define''':
;<calendarname>
:Name des '''Calendar''' Kalenders

Beispiel:
:<code>define myAbfall ABFALL AbfallGoogleCalender</code>

=== Werte aktualisieren ===
Die Werte aktualisieren sich abhängig vom [[notify]] der entsprechenden Calendar Instanz, welche im define angegeben wurde(n).

=== Weitere Attribute ===

{| class="wikitable"
!Attribut
!Werteliste
!Beschreibung
!Default Wert
|-
!align="right" |calendarname_praefix
|0 und 1
|soll der Kalendername als praefix dem Reading vorangestellt werden, sollte bei nur einem Kalender auf 0 gesetzt werden
|1 - praefix wird vorangestellt
|-
!align="right" |abfall_clear_reading_regex
|
|regex zum Entfernen von Anteilen aus dem Termin, dieser wird vor dem Entfernen von Sonderzeichen aus den Namen der Termine angewandt.
|
|-
!align="right" |disable
|0 und 1
|deaktiviert das Modul
|0
|-
!align="right" |weekday_mapping
|
|Mapping, wie die Readings der Tage angezeigt werden sollen, zum Beispiel So Mo Di Mi Do Fr Sa
|Sonntag Montag Dienstag Mittwoch Donnerstag Freitag Samstag
|-
!align="right" |delimiter_text_reading
|
|Wenn zwei Abholungen an ein und demselben Tag existieren, wird dieses Trennzeichen genutzt, um die beiden (oder mehrere) Werte zu einem Text zu verbinden. Nur relevant für die Readings next_text und now_text
|und
|-
!align="right" |delimiter_reading
|
|wie attribute delimiter_text_reading, allerdings nur für die readings next und now
|
|-
!align="right" |filter
|
|regex zum Filtern der Namen der Termine aus den Kalendern, so dass nur solche genutzt werden, welche diesem Filter entsprechen
|
|-
|}

== Anwendungsbeispiel(e) ==
=== Einbindung ins Tablet UI ===
<pre><div data-device="myABFALL" data-type="symbol" class="bigger warn wider"
data-get="next" data-get-warn=".*(\d+).*"
data-get-on='["Restmuell_.*","Wertstoff_.*"]'
data-on-colors='["#000","#6EB54C"]'
data-icons='["fa-trash-o","fa-trash-o"]'></div></pre>

=== Einbindung ins Tablet UI, erweitert ===
Fallen die Leerungen zweier verschiedener Tonnen nicht auf den selben Tag, reicht es normalerweise, nur ein Symbol auf der Oberfläche zu platzieren und dieses dann dynamisch zu befüllen. In folgendem Beispiel werden folgende Anforderungen umgesetzt:
* Anzeige unterschiedlicher Symbole bzw. Farben für Papiertonne, Restmülltonne, Biotonne und gelbe Säcke
* Anzeige der verbleibenden Tage bis zur Leerung als "Warn"-Marker in Rot, aber nur, wenn die Leerung innerhalb der nächsten 2 Tage ist
* Blinken des Symbols, wenn die nächste Leerung morgen ansteht
* Rotation des Symbols, wenn die nächste Leerung noch am selben Tag ansteht. Nach einer bestimmten Uhrzeit (z.B. 9 Uhr morgens) soll dann auf die nächste Tonne geschaltet werden
* Anzeige des Datums bzw. von "heute" oder "morgen" unter dem Symbol als Label

Zur Datumsanzeige wird eine kleine Hilfsfunktion in die 99_myUtils eingebaut.
<source lang="perl">
sub datumHeuteMorgen($){
my $compareDate = shift;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
$year += 1900; $mon += 1;
my $heute = sprintf('%02d.%02d.%04d', $mday, $mon, $year);
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time+86400);
$year += 1900; $mon += 1;
my $morgen = sprintf('%02d.%02d.%04d', $mday, $mon, $year);
return "heute" if $compareDate eq $heute;
return "morgen" if $compareDate eq $morgen;
return $compareDate;
}
</source>
Diese Funktion wird in den userReadings des Abfall-Moduls verwendet. Das Abfallmodul erzeugt eine Gruppe von Readings mit dem Namen now_*, wenn die Leerung am selben Tag ansteht, bzw. genau dann, wenn der Termin im zu Grunde liegenden Kalender gerade aktiv ist. In diesem Beispiel liegt dem Kalender-Modul ein Google-Kalender zu Grunde, bei dem die Termine immer von 0 Uhr bis 9 Uhr morgens eingetragen sind. Dadurch wird erreicht, dass die Anzeige nach 9 Uhr weiterspringt, weil dann die now-Readings verschwinden.

Folgende userReadings werden zum Abfallmodul hinzugefügt, welches in diesem Beispiel "abf.abfall" genannt ist:
<source lang="perl">
attr abf.abfall userReadings ftui_datum {ReadingsVal("abf.abfall","now_text","") eq "" ? datumHeuteMorgen(ReadingsVal("abf.abfall","next_datum","")) : "heute";},ftui_next {ReadingsVal("abf.abfall","now_text","") eq "" ? ReadingsVal("abf.abfall","next","") : ReadingsVal("abf.abfall","now","")."_0";}
</source>
Das Reading "ftui_next" bildet die Grundlage für das Symbol in TabletUI, das Reading "ftui_datum" wird für das Label genutzt.

Somit lässt sich ganze in FTUI wie folgt darstellen:
<source lang="html">
<div data-device="abf.abfall"
data-type="symbol"
data-get="ftui_next"
data-get-on='["Biotonne_0$","Biotonne_1$","Biotonne_.*","GelberSack_0$","GelberSack_1$","GelberSack_.*","Papiertonne_0$","Papiertonne_1$","Papiertonne_.*","Restmuelltonne_0$","Restmuelltonne_1$","Restmuelltonne_.*"]'
data-get-warn=".*([0|1|2]).*"
data-on-colors='["#8B4513","#8B4513","#8B4513","#f4e946","#f4e946","#f4e946","#2d9e1c","#2d9e1c","#2d9e1c","#696969","#696969","#696969"]'
class="large warn"
data-icons='["fa-trash-o fa-spin","fa-trash-o blink","fa-trash-o","fs-bag fa-spin","fs-bag blink","fs-bag","fs-dustbin fa-spin","fs-dustbin blink","fs-dustbin","fa-trash fa-spin","fa-trash blink","fa-trash"]'
/>
<div data-device="abf.abfall" data-get="ftui_datum" data-type="label"/>
</source>
Für Jede Tonne werden hier drei Zustände unterschieden und einzeln in "data-get-on", "data-on-colors" und "data-icons" zugeordnet. Daher haben diese Listen jeweils 12 Einträge.

=== Benachrichtigung ===
==== DOIF ====
<pre>[Abfall:next_tage] == 1) ( set fhemBot message Morgen wird [Abfall:next_text] abgeholt)
[Abfall:now_text] ne "") ( set fhemBot message Heute wird [Abfall:now_text] abgeholt)</pre>

====== Pushbullet Beispiel ======

Die morgigen Leerungen per Push mittels Pushbullet:

<code>define dAbfallmorgen doif ([Abfall:next_tage] == 1) ( msg |Morgen wird [Abfall:next_text] abgeholt)</code>

Die heutigen Leerungen per Push mittels Pushbullet:

<code>define dAbfallheute doif ([Abfall:now_text] ne "") ( msg |Heute wird [Abfall:now_text] abgeholt)</code>

=== Links ===
* Forenthema {{Link2Forum|Topic=50177|LinkText=Abfall Visualisierung mit Bilderrahmen}}

OpenMultiroom

2017-01-26T21:12:43Z

Unimatrix27: Hinzugefügt: Ducking-Funktion von Pulseaudio (by SublimeText.Mediawiker) (by SublimeText.Mediawiker)

<div style="float:right">{{Infobox Modul
|ModPurpose=Steuern der einzelnen Multiroom-Systemkomponenten
|ModType=d
|ModCmdRef=OpenMultiroom
|ModForumArea=Multimedia
|ModTechName=98_OpenMultiroom.pm
|ModOwner=unimatrix
}}
{{Infobox Modul
|ModPurpose=Steuern eines Snapcast-Servers
|ModType=d
|ModCmdRef=Snapcast
|ModForumArea=Multimedia
|ModTechName=96_Snapcast.pm
|ModOwner=unimatrix
}}
[[Datei:OpenMultiroomOverview.png|mini|400px|Schaubild des Zusammenspiels der einzelnen Komponenten eines Multiroomsystems mit den Backends [https://forum.fhem.de/index.php/topic,18517.msg MPD] und [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] sowie der Nutzung von Text2Speech]]
</div>

Achtung: Dieser Wiki-Artikel und auch das beschriebene Modul sind noch in der Implemntierung und noch nicht verfügbar.

'''OpenMultiroom''' ist ein Steuerungsmodul sowie auch ein Gesamtkonzept zur Realisierung eines Multiroom-Audio-Systems unter Nutzung von ausschließlich frei verfügbarer Software und ohne Bezug auf die Hardware eines bestimmten Herstellers. Es ist so ausgelegt, dass es prinzipiell flexibel bezüglich der Auswahl der Backendsysteme ist. Zurzeit ist es für die Nutzung mit [https://www.musicpd.org/ MPD] bzw. [https://www.mopidy.com/ Mopidy] und [https://github.com/badaix/snapcast Snapcast] implementiert. Daher wird in diesem WIKI-Eintrag immer von diesen Systemen gesprochen. Einen grundsätzlichen Überblick über das Konzept bietet das Schaubild.

== Grobe Übersicht des Funktionsumfangs der Gesamtlösung==
=== Features ===
* Integrierte Steuerung des Musikplayers über das [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul sowie des Multiroom-System [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] in einem einzigen Modul
* Implementierung einer Schnittstelle gemäß [[DevelopmentGuidelinesAV]] als Basis für eine Visualisierung mit z.B. [[SmartVisu]] oder [[FHEM_Tablet_UI]]
* Synchrones Playback auf z.B. Raspberry Pi oder Android-Geräten (Snapcast-Feature)
* optionale Komprimierung der Soundübertragung als OGG oder FLAC (Snapcast-Feature)
* Möglichkeit der Bedienung völlig ohne Display über eine Fernbedienung und entsprechender Text2Speech Rückmeldung, insbesondere
** Durschalten von Playlisten mit entsprechenden Channel - Tasten unter Nutzung von raumspezifischen Filtern
** Forward und Rewind mit definierbaren Sprungweiten (implementiert direkt im [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul)
** Direktanwahl von Playlisten, Tracks oder Trackpositionen durch Zifferneingabe und anschließende Funktionstaste
** Abfrage von Statusinformationen durch Funktionstasten und Text2Speech Rückmeldungen
** Mithören in anderen Räumen und Übernahme des Playerzustandes anderer Räume durch Nutzung von Funktionstasten
** Einschlaftimer per Zifferneingabe oder per vordefinierten Zeitabständen, hierbei wird auch die Restlaufzeit des aktuellen Tracks angeboten.
* manuelles oder automatisches Speichern und Laden von Playlistbookmarks (implementiert direkt im [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul)
* Möglichkeit der Festlegung von tageszeit- und tagestypabhängigen Lautstärkebegrenzungen bis auf 0% z.B. für Kinderzimmer
* individuelles Verwalten von Playlisten für verschiedene Familienmitglieder
* Nutzung des Audiosystems für systemunabhängige FHEM-Announcements. Ein entsprechendes Announcement-Modul ist in Planung. Dabei können mehrere Räume gleichzeitig oder auch getrennt angesprochen werden

=== Anwendungszweck und Kurzbeschreibung der Funktionsweise ===
Wie der Name des Systems vermuten lässt, ist die Lösung vor allem dann sinnvoll einzusetzen, wenn Audiodateien in mindestens 2 verschiedenen Räumen oder "Zonen" sowohl synchron als auch unabhängig abgespielt werden soll und wenn hierzu eine komfortable und integrierte Steuerung über FHEM verwendet werden soll. Mit Einschränkungen ist die Lösung auch dann sinnvoll, wenn es nur um das Abspielen in einem Raum geht. Hier kann dann z.B. die Steuerung über eine Fernbedienung mit Hilfe des '''OpenMultiroom'''-Moduls genutzt werden, die über eine reine Nutzung des MPD-Moduls hinausgeht.

Für die Nutzung ist nicht zwingend ein zentraler Server notwendig. Diese Rolle kann auch von einem der Clients übernommen werden, z.B. einem Pi. Zur einfacheren Darstellung wird in diesem Eintrag jedoch immer von der Nutzung eines Servers ausgegangen, der nicht gleichzeitig auch Client ist.

Das Abspielen von Audio funktioniert prinzipiell in 2 Stufen:
# Nutzung von MPD oder einem MPD-kompatiblen Player zum direkten Abspielen von Sounddateien. Pro existierendem Raum gibt es mindestens eine Instanz von MPD. Hier wird davon ausgegangen, dass es genau eine Instanz pro Raum gibt. Jeder Raum hat also "seinen" MPD.
# Nutzung von Snapcast zur Verteilung des von MPD abgespielten Sounds an den entsprechenden Raum. Snapcast übernimmt hierbei die zeitliche Synchronisation

Durch das Modul '''OpenMultiroom''' steuert der Nutzer sowohl MPD als auch Snapcast. Für jeden Raum wird eine Instanz des Moduls definiert.

=== verwendete komponenten ===
Folgende Komponenten kommen zum Einsatz:

==== Server: ====
* MPD oder Mopidy oder ein anderer MPD-kompatibler Player. 1 Instanz pro Raum
* Snapserver
* mplayer (bei Nutzung von Text 2 Speech)
* Optional Pulseaudio (im System-Mode) bei Nutzung von Text 2 Speech oder erweiterten Konfigurationen. Hierbei wird Pulseaudio zwischen MPD und Snapcast geschaltet.
* Optional Anbindung an Subsonic oder Libresonic (hier zurzeit nicht beschrieben) zur Synchronisation von Playlisten uvm.
* FHEM: Modul 98_OpenMultiroom.pm
* FHEM: Modul 96_Snapcast.pm
* FHEM: Modul 73_MPD.pm
* FHEM: Optional Modul 98_Text2Speech.pm

==== Client: ====
* Linux: Alsa oder Pulseaudio zur Soundwiedergabe
* Linux: Snapclient
* Android: Nur der Android Snapclient
* Webbrowser zur Steuerung per Visualisierung
* ggf. Infrarot oder Funkfernbedienung. In diesem Artikel wird das Beispiel anhand der Nutzung von X10-Funkfernbedienungen gezeigt, diese gibt es sehr günstig in der Bucht o.ä.
* Vision: Nutzung von Tastern und Display am PI oder Nutzung eine Steuergerätes mit Tastern und Display auf Basis eines Arduino mit WLAN, z.B. im alten Gehäuse eines Küchenradios usw.

== Aufbau anhand einer vollständigen Beispielkonfiguration ==

In diesem Artikel soll beispielhaft eine vollständige Konfiguration gezeigt werden. Jeder Nutzer muss diese Konfiguration an seine eigenen Bedürfnisse anpassen. Es seien folgende Komponenten vorhanden:

* Server mit Ubuntu 16.04, hier befindet sich eine MP3-Sammlung
* Kind1: Raspberry Pi Model 1 mit Raspbian
* Kind2: BananaPi mit Ubuntu, an diesem Pi ist auch ein X10 Empfänger angeschlossen, da er zentral im Haus positioniert ist
* Wohnzimmer: Raspberry Pi3 mit OSMC und KODI, wird primär zum Fernsehen verwendet
* Küche: Raspberry Pi Model 1 mit Raspbian

Anmerkung: Es ist möglich, mehrere Räume mit nur einem physikalischen Client zu bedienen. Hierbei werden auf einem Client mehrere Instanzen des Snapclients laufen gelassen. Der physikalische Client hat dann z.B. mehrere USB Soundkarten, dessen Audioausgänge in verschiedene Räume verkabelt sind. Dies wird hier zurzeit nicht näher beschrieben.

=== Pulseaudio Konfiguration ===
Will man Pulseaudio verwenden, z.B. um Text2Speech Nachrichten in laufende Musik einzublenden, sollte dieses am besten zuerst konfiguriert werden. Pulseaudio muss hierzu im System-Mode laufen. Dies ist auf einem Headless-Server kein Problem. Bei Ubuntu 16.10 wird dies durch folgenden Inhalt in ''/etc/systemd/system/pulseaudio.server'' erreicht:
<source lang="bash">
[Unit]
Description=PA
After=network.target sound.target

[Service]
ExecStart=/usr/bin/pulseaudio --system

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>
Weiterhin ist der Befehl
<source lang="bash">sudo systemctl enable pulseaudio</source>
einzugeben, um Pulseaudio beim Systemstart automatisch zu starten.

Ausgehend von der Standardkonfiguration werden nun in ''/etc/pulse/system.pa'' die benötigten Module eingetragen
<source lang="bash">
load-module module-pipe-sink file=/tmp/wohn.fifo sink_name=wohn
load-module module-pipe-sink file=/tmp/kind1.fifo sink_name=kind1
load-module module-pipe-sink file=/tmp/kind2.fifo sink_name=kind2
load-module module-pipe-sink file=/tmp/kueche.fifo sink_name=kueche

load-module module-combine-sink slaves=kind1,kind2 sink_name=kinder
load-module module-combine-sink slaves=wohn,kueche sink_name=unten
load-module module-combine-sink slaves=wohn,kueche,kind1,kind2 sink_name=alle

pactl load-module module-role-ducking trigger_roles=announcement ducking_roles=music
</source>
Snapcast benötigt die Audioquelle in Form von FIFOs. Daher wird hier in den erstem 4 Zeilen je ein FIFO von Pulseaudio erzeugt. Der sink_name wird später bei der Konfiguration von MPD als Ausgang verwendet. In den 3 weiteren Zeilen werden noch 3 Sinks als Combine-Sinks erstellt. Diese erzeugen keine neuen FIFOs, sondern omrhen under entsprechenden Sink-Namen eine vorgegebene Kombination von Räumen nach außen hin verfügbar. Der Sink "alle" kann also genutzt werden, um Audio auf allen 4 FIFOs gleichzeitig abzuspielen (und somit später potentiall in allen Räumen gleichzeitig). Dies kann für Announcements sinnvoll sein. Die Nutzung dieser Combine-Sinks ist optional. Ebenso optional ist das Laden des Ducking-Moduls am Ende. Das Ducking Modul führt dazu, dass Pulseaudio automatisch die Lautstärke der durch MPD abgespielten Tracks absenkt, wenn etwas über die Text2Speech-Module abgespielt wird. Ohne dies sind die Ausgaben speziell über die Google API unter Umständen nur schwer hörbar.

=== Snapcast Konfiguration ===
[https://github.com/badaix/snapcast Snapcast] muss entsprechend der Angaben auf der Webseite installiert werden. Auf dem Server muss logischerweise die Serverkomponente und auf den Clients die Clientkomponente installiert werden. Bei Android-Clients wird die auf der Webseite zur Verfügung gestellt APK installiert. Snapcast befindet sich selbst noch in fortlaufender Entwicklung. Die hier vorgestellte Lösung ist mit [https://github.com/badaix/snapcast/tree/98be8a58d945f84af50e40ebcf8a774592dd6e7b dieser Version] kompatibel und getestet.

Die Konfiguration des Servers beschränkt sich auf die Definition der Streams in ''/etc/default/snapserver''
<source lang="bash">
START_SNAPSERVER=true
SNAPSERVER_OPTS="-d -s pipe:///tmp/kind1.fifo?name=kind1&mode=read -s pipe:///tmp/kind2.fifo?name=kind2&mode=read -s pipe:///tmp/wohn.fifo?name=wohn&mode=read -s pipe:///tmp/kueche.fifo?name=kueche&mode=read"
</source>
Hier werden die 4 Streams erstellt, diese entsprechen vom Dateinamen her der Pulseaudiokonfiguration. Der hier verwendete Name kann später in FHEM oder auch im Android-Client angezeigt werden. Die Option <pre>mode=read</pre> ist wichtig, weil Pulseaudio meckert, wenn es die FIFO-Dateien nicht selbst anlegen darf.

Auf der Clientseite sieht die Datei ''/etc/default/snapclient'' dann so aus:
<source lang="bash">
START_SNAPCLIENT=true
SNAPCLIENT_OPTS="-d -s dmix:CARD=Aureon51MkII,DEV=0"
</source>
Den Server findet der Snapclient automatisch, er kann aber auch angegeben werden. Wie hier zu sehen kann ein spezielles Output-Device angegeben werden. Dies ist bei den PIs mit externer USB-Soundkarte meistens notwendig, da ansonsten der interne Sound genutzt würde. Eine Liste der verfügbaren Devices wird mit dem Aufruf von <pre>snapclient -l</pre> ausgegeben, hier muss dann das passende genommen werden. GGf. so lange ausprobieren, bis der Sound an der richtigen Stelle rauskommt.

In der hier betrachteten Konfiguration soll auf dem Wohnzimmer-PI ein Snapclient laufen, dieser wird aber normalerweise zum TV und Filme schauen mit KODI verwendet. Sowohl KODI als auch der Snapclient blockieren aber das ALSA-Device und funktionieren beide meistens entweder gar nicht oder nicht richtig zusammen, insbesondere dann nicht, wenn von KODI Mehrkanalsound oder sogar Passthrough ausgegeben wird. Die Entwicklung eines nativen Snapcast-Clients innerhalb von KODI wird gerade an verschiedenen Stellen diskutiert, z.B. [https://github.com/badaix/snapcast/issues/155 hier]. Bis dahin kann ein kleiner Workaround Abhilfe schaffen. Mit folgendem (nur rudimentär getesteten) [https://github.com/unimatrix27/snapcast/commit/88e42a2ecc8b44223701e18abb63af04b673b67b Hack] für den Snapcast-Client wird erreicht, dass der Client das ALSA-Device frei gibt, sobald er über den Server auf Mute gestellt wird. KODI selbst gibt das Device ebenfalls frei, wenn es im Zustand "Stop" ist. Bei dieser Lösung kann der Snapclient auf dem KODI-Rechner immer laufen gelassen werde. Es ist jedoch in der Verantwortung des Benutzers, den Client zu "muten". Vergisst er dies, wird ggf. die Wiedergabe in KODI nicht möglich sein.

Nach Abschluss der Snapcastkonfiguration und dem Starten von Server und den Clients empfiehlt es sich, die Android-App ebenfalls zu verwenden, da diese einen schnellen Überblick über den Zustand des Servers, der konfigurierten Streams und der Clients bietet.

=== Mopidy Konfiguration ===

In diesem Beispiel wird Mopidy als MPD-Ersatz verwendet, genau so gut kann aber auch direkt MPD verwendet werden. Die genauen Konfigurationsoptionen sind natürlich anders, und jeweils in entsprechenden Tutorials oder Dokumentationen beschrieben. Mopidy ist relativ umfangreich und modular aufgebaut, es bietet u.a. die Möglichkeit, neben lokal gespeicherten Dateien auch Dateien von verschiedenen, teilweise kommerziellen, Streamingdiensten abzuspielen. Die Detailkonfiguration all dieser Komponenten geht über diesen Artikel hinaus. Entscheidend hier ist die Konfiguration in einer Weise, so dass mehrere Mopidy-Instanzen gleichzeitig ausgeführt werden können und dann auf unterschiedlichen Ports zur Verfügung stehen.

Nach Installation von Mopidy findet sich die Konfiguration in der Datei ''/etc/mopidy/mopidy.cfg''. Mopidy unterstützt hierarische Konfigurationen, es reicht also, den für jede Instanz spezifischen Teil aus dieser allgemeinen Konfiguration zu entfernen und in jeweils eigene Dateien zu verschieben. In diesem Beispiel sollen das die Dateien ''/etc/mopidy/kind1.conf'' bis ''/etc/mopidy/kueche.conf'' sein. Die folgenden Zeilen gehören jeweils in diese 4 Dateien und werden dort entsprechend angepasst. Hier das Beispiel für Kind2:

<source lang="bash">
[logging]
config_file = /etc/mopidy/logging_kind2.conf
debug_file = /var/log/mopidy/mopidy-debug_kind2.log

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! pulsesink device=kind2 stream-properties="props,media.role=music"

[mpd]
enabled = true
hostname = 0.0.0.0
port=6601

[http]
enabled = true
hostname = 0.0.0.0
port=6681
zeroconf = Musik Kind2
</source>

Im Audioteil wird der entsprechende Sink aus der Pulseaudiokonfiguration genommen. Die Angabe von stream-properties ermöglicht dem Duck-Modul den Stream als Musik zu erkennen und beim Abspielen von Announcements in der Lautstärke abzusenken. Beim MPD muss der Port für jede Instanz unterschiedlich sein, ebenso beim HTTP-Modul für die Weboberfläche der jeweiligen Instanz. Der Zerokonfname sollte auch eindeutig sein. Neben dieser Datei ist noch die dazu passende logging-Konfiguration anzulegen, hier also ''/etc/mopidy/logging_kind2.conf''. Dazu wird die Standarddatei kopiert und darin nur der Name der Logdatei angepasst.

Um nun auch die entsprechende Anzahl Instanzen automatisch zu starten, sind die entsprechenden Startdateien anzulegen. Dazu kann die Datei ''/etc/systemd/system/mopidy.cfg'' z.B. in ''/etc/systemd/system/mopidy_kind1.cfg'' umbenannt werden und dann 3 mal mit den Endungen der anderen Instanzen kopiert werden. Der Inhalt ist dann wie folgt:

<source lang="bash">
[Unit]
Description=Mopidy_kind1
After=network.target sound.target

[Service]
EnvironmentFile=/etc/default/mopidy
ExecStart=/usr/bin/mopidy --quiet --config /etc/mopidy/kind1.conf

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>

Abschließend sollten die 4 Instanzen durch den Aufruf von <pre>systemctl enable mopidy_kind1</pre> usw. aktiviert werden. Es empfiehlt sich nach dem Start von Mopidy die korrekte Funtkionsweise mit dem [https://www.musicpd.org/clients/mpc/ MPC]-Client oder mit [http://rybczak.net/ncmpcpp/ NCMPCPP] auf der Konsole zu testen.

Hierbei sollte es dann bereits möglich sein, die Multiroom-Fähigkeiten von Snapcast mit Hilfe des Android-Clients von Snapcast zu testen und so auch festzustellen, dass die restliche Konfiguration von Snapcast und Pulseaudio korrekt sind.

=== FHEM ===

In FHEM sind nun in der ''fhem.cfg'' die entsprechenden Module einzurichten:
* Ein Snapcast-Modul im Server Modus
* Pro Raum ein Snapcast-Modul im Clientmodus
* Pro Raum ein MPD-Modul
* Pro Raum ein OpenMultiroom-Modul
* Optional pro Raum ein Text2Speech-Modul
* weitere Text2Speech-Module, falls man diese in Pulseaudio mit dem per Combine-Sink vorgesehen hat.

<source lang="bash">
define scs.snap Snapcast

define scc.kind1 Snapcast client scs.snap b827eb9aec84
attr scc.kind1 constraintDummy freestring
attr scc.kind1 constraints standard|07:00 0 20:00 100 21:00 50 21:30 30 24:00 0,beforefree|07:00 0 21:00 100 22:00 50 23:00 30 24:00 0,beforeschool|07:00 0 08:30 50 20:00 100 21:00 50 21:30 30 24:00 0,free|07:00 0 08:30 50 21:00 100 22:00 50 23:00 30 24:00 0

define scc.kind2 Snapcast client scs.snap 025009413c29
attr scc.kind2 constraintDummy freestring
attr scc.kind2 constraints standard|07:00 0 20:15 100 20:30 50 24:00 0,beforefree|07:00 0 21:00 100 22:30 50 24:00 0,beforeschool|07:00 0 08:30 50 20:15 100 20:30 50 24:00 0,free|07:00 0 08:30 50 21:00 100 22:30 50 24:00 0

define scc.kueche Snapcast client scs.snap b827eb9a2ad3

define scc.wohn Snapcast client scs.snap 00aefa4aa3a9
</source>

Oben zu sehen ist das define für das Server-Modul. Ohne Parameter verbindet sich mit localhost auf dem Standardport 1705. Es folgt die Definition von 2 Clients. Der erste Parameter "client" versetzt das Snapcastmodul in den Clientmodus. Der zweite Parameter verweist auf das Servermodul, der dritte Parameter ist die Client-ID. Diese besteht bei der aktuellen Snapcast-Version meistens aus der MAC-Adresse des Clients. Für die Kinder werden noch die Attribute constraintDummy ond constraints vergeben. Hiermit wird eine tagestyp- und tageszeitabhängige Lautstärkebegrenzung konfiguriert. Für die vier Tagestypen "standard", "beforefree", "beforeschool" und "free" wird ein jeweils anderes Lautstärkezeitprofil definiert.

Das Zeitprofil wird hier nach dem gleichen Muster wie die Temperaturlisten der Homematic-Thermostate, erklärt hier: [HomeMatic_Type_Thermostat]. Für den Tagestyp wird zusätzlich das Attribut constraintDummy verwendet. Es definiert, dass in dem Dummy "freestring" jeweils drin steht, welcher Tagestyp gerade ist. Diese Variable wirkt somit als Selektor auf die Liste der erlaubten Maximallautstärken. Wie eine solche Dummyvariable jeweils mit einem entsprechenden Wert befüllt werden kann, z.B. abhängig vom Wochentag, von Schulferien oder Feiertagen, wird hier nicht erläutert. Es ist auch möglich, nur ein Lautstärkeprofil anzugeben. Ohne dass ein Attribut constraintDummy gesetzt ist, verwendet das Snapcastmodul immer den Wert "standard". Wie man hier sehen kann, gibt es im Beispiel 4 Typen, hierbei fallen Freitage normalerweise in die Kategorie "beforefree" (es sind Tage, bevor dann frei ist, es kann also typischerweise länger und lauter Musik gehört werden), Samstage normalerweise in die Kategorie "free" und Sonntage in die Kategorie "beforeschool", ebenso landen dort Feiertage vor Schultagen usw.

<source lang="bash">
define tts.wohn Text2Speech pulsewohn
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.wohn TTS_UseMP3Wrap true
attr tts.wohn TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120

define tts.kind1 Text2Speech pulsekind1
attr tts.kind1 TTS_FileTemplateDir /data/misc/announcements/
attr tts.kind1 TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.kind1 TTS_UseMP3Wrap true

define tts.kind2 Text2Speech pulsekind2
attr tts.kind2 TTS_FileTemplateDir /data/misc/announcements/
attr tts.kind2 TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.kind2 TTS_UseMP3Wrap true

define tts.kueche Text2Speech pulsekueche
attr tts.kueche TTS_FileTemplateDir /data/misc/announcements/
attr tts.kueche TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.kueche TTS_UseMP3Wrap true

define tts.kinder Text2Speech pulsekinder
attr tts.kinder TTS_FileTemplateDir /data/misc/announcements/
attr tts.kinder TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.kinder TTS_UseMP3Wrap true

define tts.unten Text2Speech pulseunten
attr tts.unten TTS_FileTemplateDir /data/misc/announcements/
attr tts.unten TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.unten TTS_UseMP3Wrap true

define tts.alle Text2Speech pulsealle
attr tts.alle TTS_FileTemplateDir /data/misc/announcements/
attr tts.alle TTS_MplayerCall PULSE_PROP='media.role=announcement' /usr/bin/mplayer -softvol -volume 120
attr tts.alle TTS_UseMP3Wrap true
</source>
Hier sind die Definitionen der Text2Speech Module zu sehen (optional). Sie werden jeweils mit den in Pulseaudio definierten Sinks verbunden. Die Nutzung eines TemplateDirs ist ebenfalls optional, hier können bereits fertige MP3s verwendet werden, die dann anstelle der von der Google TTS API erzeugten Dateien benutzt werden. Dies können auch Bestätigungs und Fehlertöne sein, die bei Benutzern ohne Display, die rein mit Fernbedienung arbeiten, auf Fehlbedienungen etc. aufmerksam zu omrhen. Der Aufruf von mplayer wird noch modifiziert, um dafür zu sorgen, dass die Ausgabe bei Pulseaudio als media.role "announcement" eingehen. Dies wird dann vom duck-Modul erkannt, und führt dazu, dass die Lautstärke der ggf. ablaufenden Musik, etc. abgesenkt wird, so lange die tts-Ausgabe läuft.

<source lang="bash">
define mpd.kind1 MPD 192.168.2.2 6600
attr mpd.kind1 player mopidy
attr mpd.kind1 bookmarkDir mpdstates
attr mpd.kind1 autoBookmark 1

define mpd.kind2 MPD 192.168.2.2 6702
attr mpd.kind2 player mopidy
attr mpd.kind2 bookmarkDir mpdstates
attr mpd.kind2 autoBookmark 1

define mpd.kueche MPD 192.168.2.2 6703
attr mpd.kueche player mopidy
attr mpd.kueche bookmarkDir mpdstates
attr mpd.kueche autoBookmark 1

define mpd.wohn MPD 192.168.2.2 6704
attr mpd.wohn player mopidy
attr mpd.wohn bookmarkDir mpdstates
attr mpd.wohn autoBookmark 1
</source>
Pro laufender MPD oder Mopidy-Instanz wird ein MPD-Modul eingerichtet. Der Hostname und die Ports sind entsprechend anzupassen. Durch die bookmarkDir und autoBookmark - Attribute wird erreicht, dass der Zustand von Playlisten beim Wechsel derselben gespeichert und später wiederhergestellt werden kann. So lässt sich das Hören eines Hörbuchs unterbrechen, auf z.B. eine Radiostreamplayliste schalten, um dann später zur gleichen Stelle im Hörbuch zurückzukehren.

<source lang="bash">
define omr.kind1 OpenMultiroom
attr omr.kind1 mr scc.kind1
attr omr.kind1 soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.kind1 playlistPattern kind1
attr omr.kind1 ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.kind1 defaultTts tts.kind1
attr omr.kind1 defaultStream kind1
attr omr.kind1 defaultSound mpd.kind1

define omr.kind2 OpenMultiroom
attr omr.kind2 mr scc.kind2
attr omr.kind2 soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.kind2 playlistPattern kind2
attr omr.kind2 ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.kind2 defaultTts tts.kind2
attr omr.kind2 defaultStream kind2
attr omr.kind2 defaultSound mpd.kind2

define omr.kueche OpenMultiroom
attr omr.kueche mr scc.kueche
attr omr.kueche soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.kueche playlistPattern wohn
attr omr.kueche ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.kueche defaultTts tts.kueche
attr omr.kueche defaultStream kueche
attr omr.kueche defaultSound mpd.kueche

define omr.wohn OpenMultiroom
attr omr.wohn mr scc.wohn
attr omr.wohn soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.wohn playlistPattern wohn
attr omr.wohn ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.wohn defaultTts tts.wohn
attr omr.wohn defaultStream wohn
attr omr.wohn defaultSound mpd.wohn
</source>
Die Konfiguration der OpenMultiroom-Module schließt die Einrichtung von FHEM ab. Jede Instanz benötigt mindestens das "mr"- und das "soundMapping"-Attribut. Nur so kann sich das Modul mit den entsprechenden Snapcast und MPD-Modulen verbinden. Durch das "mr"-Attribut wird ein OpenMultiroom-Modul einem Snapcast-Client-Modul fest zugeordnet. Das Soundmapping ordnet die in Snapcast definierten Streams (siehe oben, Konfiguration vom Snapserver) den entsprechenden Instanzen des MPD-Moduls zu. Dadurch weiß FHEM, welcher MPD auf welchem Stream abspielt und kann je nachdem, welchem Stream ein Raum gerade zuhört, den dazu passenden MPD steuern und seine Readings durchreichen. Das OpenMultiroom-Modul bildet alle Readings des MPD-Moduls nochmal direkt ab. Wechselt ein Benutzer aber den Stream, dem er zuhört, aktualisieren sich auch alle Readings dementsprechend mit denen des dann aktuellen MPD-Moduls.

Das Attribut playlistPattern ist optional und sorgt dafür, dass beim Durchschalten der Playlists mit den Kommandos "channelUp" und "channelDown" nur diejenigen Playlists berücksichtigt werden, die auf das Pattern passen.

Analog zum soundMapping definiert das Attribut ttsMapping die Zuordnung der TTS-Module zu den Streams. Beim Ausgeben von Announcement kann so das OpenMultiroom-Modul ermitteln, auf welchem Stream welcher Raum gerade zuhört, und wo dementsprechend die TTS-Ausgaben zu erzeugen sind, damit sie auch in den gewünschten Räumen ankommen. Dieser Umweg ist zurzeit nötig, da ein Snapcast-Client nur auf einem einzigen Stream lauschen kann. Lauschen noch andere Clients auf demselben Stream, hören sie allerdings zwangsweise auch die Announcements.

Die 3 Default-Attribute legen fest, welche der TTS-Module, welcher Stream und welcher MPD dem entsprechenden Modul fest zugeordnet sind. Dies wird u.a. von einer Resetfunktion im Modul verwendet.

== Bedienung des OpenMultiroom-Moduls ==

=== set-Kommandos ===

=== Readings ===

=== Attribute ===

== Anbindung einer Fernbedienung an ein OpenMultiroom-Modul ==

=== Konfiguration von LIRC und IRExec ===

=== Zuordnung der Tasten: Beispiel ===

[[Category:Examples]]
[[Category:HOWTOS]]
[[Category:Unterhaltungselektronik]]

OpenMultiroom

2017-01-26T13:29:46Z

Unimatrix27: some error corrections before publishing to FHEM forum (by SublimeText.Mediawiker) (by SublimeText.Mediawiker)

<div style="float:right">{{Infobox Modul
|ModPurpose=Steuern der einzelnen Multiroom-Systemkomponenten
|ModType=d
|ModCmdRef=OpenMultiroom
|ModForumArea=Multimedia
|ModTechName=98_OpenMultiroom.pm
|ModOwner=unimatrix
}}
{{Infobox Modul
|ModPurpose=Steuern eines Snapcast-Servers
|ModType=d
|ModCmdRef=Snapcast
|ModForumArea=Multimedia
|ModTechName=96_Snapcast.pm
|ModOwner=unimatrix
}}
[[Datei:OpenMultiroomOverview.png|mini|400px|Schaubild des Zusammenspiels der einzelnen Komponenten eines Multiroomsystems mit den Backends [https://forum.fhem.de/index.php/topic,18517.msg MPD] und [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] sowie der Nutzung von Text2Speech]]
</div>

Achtung: Dieser Wiki-Artikel und auch das beschriebene Modul sind noch in der Implemntierung und noch nicht verfügbar.

'''OpenMultiroom''' ist ein Steuerungsmodul sowie auch ein Gesamtkonzept zur Realisierung eines Multiroom-Audio-Systems unter Nutzung von ausschließlich frei verfügbarer Software und ohne Bezug auf die Hardware eines bestimmten Herstellers. Es ist so ausgelegt, dass es prinzipiell flexibel bezüglich der Auswahl der Backendsysteme ist. Zurzeit ist es für die Nutzung mit [https://www.musicpd.org/ MPD] bzw. [https://www.mopidy.com/ Mopidy] und [https://github.com/badaix/snapcast Snapcast] implementiert. Daher wird in diesem WIKI-Eintrag immer von diesen Systemen gesprochen. Einen grundsätzlichen Überblick über das Konzept bietet das Schaubild.

== Grobe Übersicht des Funktionsumfangs der Gesamtlösung==
=== Features ===
* Integrierte Steuerung des Musikplayers über das [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul sowie des Multiroom-System [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] in einem einzigen Modul
* Implementierung einer Schnittstelle gemäß [[DevelopmentGuidelinesAV]] als Basis für eine Visualisierung mit z.B. [[SmartVisu]] oder [[FHEM_Tablet_UI]]
* Synchrones Playback auf z.B. Raspberry Pi oder Android-Geräten (Snapcast-Feature)
* optionale Komprimierung der Soundübertragung als OGG oder FLAC (Snapcast-Feature)
* Möglichkeit der Bedienung völlig ohne Display über eine Fernbedienung und entsprechender Text2Speech Rückmeldung, insbesondere
** Durschalten von Playlisten mit entsprechenden Channel - Tasten unter Nutzung von raumspezifischen Filtern
** Forward und Rewind mit definierbaren Sprungweiten (implementiert direkt im [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul)
** Direktanwahl von Playlisten, Tracks oder Trackpositionen durch Zifferneingabe und anschließende Funktionstaste
** Abfrage von Statusinformationen durch Funktionstasten und Text2Speech Rückmeldungen
** Mithören in anderen Räumen und Übernahme des Playerzustandes anderer Räume durch Nutzung von Funktionstasten
** Einschlaftimer per Zifferneingabe oder per vordefinierten Zeitabständen, hierbei wird auch die Restlaufzeit des aktuellen Tracks angeboten.
* manuelles oder automatisches Speichern und Laden von Playlistbookmarks (implementiert direkt im [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul)
* Möglichkeit der Festlegung von tageszeit- und tagestypabhängigen Lautstärkebegrenzungen bis auf 0% z.B. für Kinderzimmer
* individuelles Verwalten von Playlisten für verschiedene Familienmitglieder
* Nutzung des Audiosystems für systemunabhängige FHEM-Announcements. Ein entsprechendes Announcement-Modul ist in Planung. Dabei können mehrere Räume gleichzeitig oder auch getrennt angesprochen werden

=== Anwendungszweck und Kurzbeschreibung der Funktionsweise ===
Wie der Name des Systems vermuten lässt, ist die Lösung vor allem dann sinnvoll einzusetzen, wenn Audiodateien in mindestens 2 verschiedenen Räumen oder "Zonen" sowohl synchron als auch unabhängig abgespielt werden soll und wenn hierzu eine komfortable und integrierte Steuerung über FHEM verwendet werden soll. Mit Einschränkungen ist die Lösung auch dann sinnvoll, wenn es nur um das Abspielen in einem Raum geht. Hier kann dann z.B. die Steuerung über eine Fernbedienung mit Hilfe des '''OpenMultiroom'''-Moduls genutzt werden, die über eine reine Nutzung des MPD-Moduls hinausgeht.

Für die Nutzung ist nicht zwingend ein zentraler Server notwendig. Diese Rolle kann auch von einem der Clients übernommen werden, z.B. einem Pi. Zur einfacheren Darstellung wird in diesem Eintrag jedoch immer von der Nutzung eines Servers ausgegangen, der nicht gleichzeitig auch Client ist.

Das Abspielen von Audio funktioniert prinzipiell in 2 Stufen:
# Nutzung von MPD oder einem MPD-kompatiblen Player zum direkten Abspielen von Sounddateien. Pro existierendem Raum gibt es mindestens eine Instanz von MPD. Hier wird davon ausgegangen, dass es genau eine Instanz pro Raum gibt. Jeder Raum hat also "seinen" MPD.
# Nutzung von Snapcast zur Verteilung des von MPD abgespielten Sounds an den entsprechenden Raum. Snapcast übernimmt hierbei die zeitliche Synchronisation

Durch das Modul '''OpenMultiroom''' steuert der Nutzer sowohl MPD als auch Snapcast. Für jeden Raum wird eine Instanz des Moduls definiert.

=== verwendete komponenten ===
Folgende Komponenten kommen zum Einsatz:

==== Server: ====
* MPD oder Mopidy oder ein anderer MPD-kompatibler Player. 1 Instanz pro Raum
* Snapserver
* mplayer (bei Nutzung von Text 2 Speech)
* Optional Pulseaudio (im System-Mode) bei Nutzung von Text 2 Speech oder erweiterten Konfigurationen. Hierbei wird Pulseaudio zwischen MPD und Snapcast geschaltet.
* Optional Anbindung an Subsonic oder Libresonic (hier zurzeit nicht beschrieben) zur Synchronisation von Playlisten uvm.
* FHEM: Modul 98_OpenMultiroom.pm
* FHEM: Modul 96_Snapcast.pm
* FHEM: Modul 73_MPD.pm
* FHEM: Optional Modul 98_Text2Speech.pm

==== Client: ====
* Linux: Alsa oder Pulseaudio zur Soundwiedergabe
* Linux: Snapclient
* Android: Nur der Android Snapclient
* Webbrowser zur Steuerung per Visualisierung
* ggf. Infrarot oder Funkfernbedienung. In diesem Artikel wird das Beispiel anhand der Nutzung von X10-Funkfernbedienungen gezeigt, diese gibt es sehr günstig in der Bucht o.ä.
* Vision: Nutzung von Tastern und Display am PI oder Nutzung eine Steuergerätes mit Tastern und Display auf Basis eines Arduino mit WLAN, z.B. im alten Gehäuse eines Küchenradios usw.

== Aufbau anhand einer vollständigen Beispielkonfiguration ==

In diesem Artikel soll beispielhaft eine vollständige Konfiguration gezeigt werden. Jeder Nutzer muss diese Konfiguration an seine eigenen Bedürfnisse anpassen. Es seien folgende Komponenten vorhanden:

* Server mit Ubuntu 16.04, hier befindet sich eine MP3-Sammlung
* Kind1: Raspberry Pi Model 1 mit Raspbian
* Kind2: BananaPi mit Ubuntu, an diesem Pi ist auch ein X10 Empfänger angeschlossen, da er zentral im Haus positioniert ist
* Wohnzimmer: Raspberry Pi3 mit OSMC und KODI, wird primär zum Fernsehen verwendet
* Küche: Raspberry Pi Model 1 mit Raspbian

Anmerkung: Es ist möglich, mehrere Räume mit nur einem physikalischen Client zu bedienen. Hierbei werden auf einem Client mehrere Instanzen des Snapclients laufen gelassen. Der physikalische Client hat dann z.B. mehrere USB Soundkarten, dessen Audioausgänge in verschiedene Räume verkabelt sind. Dies wird hier zurzeit nicht näher beschrieben.

=== Pulseaudio Konfiguration ===
Will man Pulseaudio verwenden, z.B. um Text2Speech Nachrichten in laufende Musik einzublenden, sollte dieses am besten zuerst konfiguriert werden. Pulseaudio muss hierzu im System-Mode laufen. Dies ist auf einem Headless-Server kein Problem. Bei Ubuntu 16.10 wird dies durch folgenden Inhalt in ''/etc/systemd/system/pulseaudio.server'' erreicht:
<source lang="bash">
[Unit]
Description=PA
After=network.target sound.target

[Service]
ExecStart=/usr/bin/pulseaudio --system

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>
Weiterhin ist der Befehl
<source lang="bash">sudo systemctl enable pulseaudio</source>
einzugeben, um Pulseaudio beim Systemstart automatisch zu starten.

Ausgehend von der Standardkonfiguration werden nun in ''/etc/pulse/system.pa'' die benötigten Module eingetragen
<source lang="bash">
load-module module-pipe-sink file=/tmp/wohn.fifo sink_name=wohn
load-module module-pipe-sink file=/tmp/kind1.fifo sink_name=kind1
load-module module-pipe-sink file=/tmp/kind2.fifo sink_name=kind2
load-module module-pipe-sink file=/tmp/kueche.fifo sink_name=kueche

load-module module-combine-sink slaves=kind1,kind2 sink_name=kinder
load-module module-combine-sink slaves=wohn,kueche sink_name=unten
load-module module-combine-sink slaves=wohn,kueche,kind1,kind2 sink_name=alle
</source>
Snapcast benötigt die Audioquelle in Form von FIFOs. Daher wird hier in den erstem 4 Zeilen je ein FIFO von Pulseaudio erzeugt. Der sink_name wird später bei der Konfiguration von MPD als Ausgang verwendet. In den 3 letzten Zeilen werden noch 3 weitere Sinks als Combine-Sinks erstellt. Diese erzeugen keine neuen FIFOs, sondern omrhen under entsprechenden Sink-Namen eine vorgegebene Kombination von Räumen nach außen hin verfügbar. Der Sink "alle" kann also genutzt werden, um Audio auf allen 4 FIFOs gleichzeitig abzuspielen (und somit später potentiall in allen Räumen gleichzeitig). Dies kann für Announcements sinnvoll sein. Die Nutzung dieser Combine-Sinks ist optional.

=== Snapcast Konfiguration ===
[https://github.com/badaix/snapcast Snapcast] muss entsprechend der Angaben auf der Webseite installiert werden. Auf dem Server muss logischerweise die Serverkomponente und auf den Clients die Clientkomponente installiert werden. Bei Android-Clients wird die auf der Webseite zur Verfügung gestellt APK installiert. Snapcast befindet sich selbst noch in fortlaufender Entwicklung. Die hier vorgestellte Lösung ist mit [https://github.com/badaix/snapcast/tree/98be8a58d945f84af50e40ebcf8a774592dd6e7b dieser Version] kompatibel und getestet.

Die Konfiguration des Servers beschränkt sich auf die Definition der Streams in ''/etc/default/snapserver''
<source lang="bash">
START_SNAPSERVER=true
SNAPSERVER_OPTS="-d -s pipe:///tmp/kind1.fifo?name=kind1&mode=read -s pipe:///tmp/kind2.fifo?name=kind2&mode=read -s pipe:///tmp/wohn.fifo?name=wohn&mode=read -s pipe:///tmp/kueche.fifo?name=kueche&mode=read"
</source>
Hier werden die 4 Streams erstellt, diese entsprechen vom Dateinamen her der Pulseaudiokonfiguration. Der hier verwendete Name kann später in FHEM oder auch im Android-Client angezeigt werden. Die Option <pre>mode=read</pre> ist wichtig, weil Pulseaudio meckert, wenn es die FIFO-Dateien nicht selbst anlegen darf.

Auf der Clientseite sieht die Datei ''/etc/default/snapclient'' dann so aus:
<source lang="bash">
START_SNAPCLIENT=true
SNAPCLIENT_OPTS="-d -s dmix:CARD=Aureon51MkII,DEV=0"
</source>
Den Server findet der Snapclient automatisch, er kann aber auch angegeben werden. Wie hier zu sehen kann ein spezielles Output-Device angegeben werden. Dies ist bei den PIs mit externer USB-Soundkarte meistens notwendig, da ansonsten der interne Sound genutzt würde. Eine Liste der verfügbaren Devices wird mit dem Aufruf von <pre>snapclient -l</pre> ausgegeben, hier muss dann das passende genommen werden. GGf. so lange ausprobieren, bis der Sound an der richtigen Stelle rauskommt.

In der hier betrachteten Konfiguration soll auf dem Wohnzimmer-PI ein Snapclient laufen, dieser wird aber normalerweise zum TV und Filme schauen mit KODI verwendet. Sowohl KODI als auch der Snapclient blockieren aber das ALSA-Device und funktionieren beide meistens entweder gar nicht oder nicht richtig zusammen, insbesondere dann nicht, wenn von KODI Mehrkanalsound oder sogar Passthrough ausgegeben wird. Die Entwicklung eines nativen Snapcast-Clients innerhalb von KODI wird gerade an verschiedenen Stellen diskutiert, z.B. [https://github.com/badaix/snapcast/issues/155 hier]. Bis dahin kann ein kleiner Workaround Abhilfe schaffen. Mit folgendem (nur rudimentär getesteten) [https://github.com/unimatrix27/snapcast/commit/88e42a2ecc8b44223701e18abb63af04b673b67b Hack] für den Snapcast-Client wird erreicht, dass der Client das ALSA-Device frei gibt, sobald er über den Server auf Mute gestellt wird. KODI selbst gibt das Device ebenfalls frei, wenn es im Zustand "Stop" ist. Bei dieser Lösung kann der Snapclient auf dem KODI-Rechner immer laufen gelassen werde. Es ist jedoch in der Verantwortung des Benutzers, den Client zu "muten". Vergisst er dies, wird ggf. die Wiedergabe in KODI nicht möglich sein.

Nach Abschluss der Snapcastkonfiguration und dem Starten von Server und den Clients empfiehlt es sich, die Android-App ebenfalls zu verwenden, da diese einen schnellen Überblick über den Zustand des Servers, der konfigurierten Streams und der Clients bietet.

=== Mopidy Konfiguration ===

In diesem Beispiel wird Mopidy als MPD-Ersatz verwendet, genau so gut kann aber auch direkt MPD verwendet werden. Die genauen Konfigurationsoptionen sind natürlich anders, und jeweils in entsprechenden Tutorials oder Dokumentationen beschrieben. Mopidy ist relativ umfangreich und modular aufgebaut, es bietet u.a. die Möglichkeit, neben lokal gespeicherten Dateien auch Dateien von verschiedenen, teilweise kommerziellen, Streamingdiensten abzuspielen. Die Detailkonfiguration all dieser Komponenten geht über diesen Artikel hinaus. Entscheidend hier ist die Konfiguration in einer Weise, so dass mehrere Mopidy-Instanzen gleichzeitig ausgeführt werden können und dann auf unterschiedlichen Ports zur Verfügung stehen.

Nach Installation von Mopidy findet sich die Konfiguration in der Datei ''/etc/mopidy/mopidy.cfg''. Mopidy unterstützt hierarische Konfigurationen, es reicht also, den für jede Instanz spezifischen Teil aus dieser allgemeinen Konfiguration zu entfernen und in jeweils eigene Dateien zu verschieben. In diesem Beispiel sollen das die Dateien ''/etc/mopidy/kind1.conf'' bis ''/etc/mopidy/kueche.conf'' sein. Die folgenden Zeilen gehören jeweils in diese 4 Dateien und werden dort entsprechend angepasst. Hier das Beispiel für Kind2:

<source lang="bash">
[logging]
config_file = /etc/mopidy/logging_kind2.conf
debug_file = /var/log/mopidy/mopidy-debug_kind2.log

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! pulsesink device=kind2

[mpd]
enabled = true
hostname = 0.0.0.0
port=6601

[http]
enabled = true
hostname = 0.0.0.0
port=6681
zeroconf = Musik Kind2
</source>

Im Audioteil wird der entsprechende Sink aus der Pulseaudiokonfiguration genommen. Beim MPD muss der Port für jede Instanz unterschiedlich sein, ebenso beim HTTP-Modul für die Weboberfläche der jeweiligen Instanz. Der Zerokonfname sollte auch eindeutig sein. Neben dieser Datei ist noch die dazu passende logging-Konfiguration anzulegen, hier also ''/etc/mopidy/logging_kind2.conf''. Dazu wird die Standarddatei kopiert und darin nur der Name der Logdatei angepasst.

Um nun auch die entsprechende Anzahl Instanzen automatisch zu starten, sind die entsprechenden Startdateien anzulegen. Dazu kann die Datei ''/etc/systemd/system/mopidy.cfg'' z.B. in ''/etc/systemd/system/mopidy_kind1.cfg'' umbenannt werden und dann 3 mal mit den Endungen der anderen Instanzen kopiert werden. Der Inhalt ist dann wie folgt:

<source lang="bash">
[Unit]
Description=Mopidy_kind1
After=network.target sound.target

[Service]
EnvironmentFile=/etc/default/mopidy
ExecStart=/usr/bin/mopidy --quiet --config /etc/mopidy/kind1.conf

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>

Abschließend sollten die 4 Instanzen durch den Aufruf von <pre>systemctl enable mopidy_kind1</pre> usw. aktiviert werden. Es empfiehlt sich nach dem Start von Mopidy die korrekte Funtkionsweise mit dem [https://www.musicpd.org/clients/mpc/ MPC]-Client oder mit [http://rybczak.net/ncmpcpp/ NCMPCPP] auf der Konsole zu testen.

Hierbei sollte es dann bereits möglich sein, die Multiroom-Fähigkeiten von Snapcast mit Hilfe des Android-Clients von Snapcast zu testen und so auch festzustellen, dass die restliche Konfiguration von Snapcast und Pulseaudio korrekt sind.

=== FHEM ===

In FHEM sind nun in der ''fhem.cfg'' die entsprechenden Module einzurichten:
* Ein Snapcast-Modul im Server Modus
* Pro Raum ein Snapcast-Modul im Clientmodus
* Pro Raum ein MPD-Modul
* Pro Raum ein OpenMultiroom-Modul
* Optional pro Raum ein Text2Speech-Modul
* weitere Text2Speech-Module, falls man diese in Pulseaudio mit dem per Combine-Sink vorgesehen hat.

<source lang="bash">
define scs.snap Snapcast

define scc.kind1 Snapcast client scs.snap b827eb9aec84
attr scc.kind1 constraintDummy freestring
attr scc.kind1 constraints standard|07:00 0 20:00 100 21:00 50 21:30 30 24:00 0,beforefree|07:00 0 21:00 100 22:00 50 23:00 30 24:00 0,beforeschool|07:00 0 08:30 50 20:00 100 21:00 50 21:30 30 24:00 0,free|07:00 0 08:30 50 21:00 100 22:00 50 23:00 30 24:00 0

define scc.kind2 Snapcast client scs.snap 025009413c29
attr scc.kind2 constraintDummy freestring
attr scc.kind2 constraints standard|07:00 0 20:15 100 20:30 50 24:00 0,beforefree|07:00 0 21:00 100 22:30 50 24:00 0,beforeschool|07:00 0 08:30 50 20:15 100 20:30 50 24:00 0,free|07:00 0 08:30 50 21:00 100 22:30 50 24:00 0

define scc.kueche Snapcast client scs.snap b827eb9a2ad3

define scc.wohn Snapcast client scs.snap 00aefa4aa3a9
</source>

Oben zu sehen ist das define für das Server-Modul. Ohne Parameter verbindet sich mit localhost auf dem Standardport 1705. Es folgt die Definition von 2 Clients. Der erste Parameter "client" versetzt das Snapcastmodul in den Clientmodus. Der zweite Parameter verweist auf das Servermodul, der dritte Parameter ist die Client-ID. Diese besteht bei der aktuellen Snapcast-Version meistens aus der MAC-Adresse des Clients. Für die Kinder werden noch die Attribute constraintDummy ond constraints vergeben. Hiermit wird eine tagestyp- und tageszeitabhängige Lautstärkebegrenzung konfiguriert. Für die vier Tagestypen "standard", "beforefree", "beforeschool" und "free" wird ein jeweils anderes Lautstärkezeitprofil definiert.

Das Zeitprofil wird hier nach dem gleichen Muster wie die Temperaturlisten der Homematic-Thermostate, erklärt hier: [HomeMatic_Type_Thermostat]. Für den Tagestyp wird zusätzlich das Attribut constraintDummy verwendet. Es definiert, dass in dem Dummy "freestring" jeweils drin steht, welcher Tagestyp gerade ist. Diese Variable wirkt somit als Selektor auf die Liste der erlaubten Maximallautstärken. Wie eine solche Dummyvariable jeweils mit einem entsprechenden Wert befüllt werden kann, z.B. abhängig vom Wochentag, von Schulferien oder Feiertagen, wird hier nicht erläutert. Es ist auch möglich, nur ein Lautstärkeprofil anzugeben. Ohne dass ein Attribut constraintDummy gesetzt ist, verwendet das Snapcastmodul immer den Wert "standard". Wie man hier sehen kann, gibt es im Beispiel 4 Typen, hierbei fallen Freitage normalerweise in die Kategorie "beforefree" (es sind Tage, bevor dann frei ist, es kann also typischerweise länger und lauter Musik gehört werden), Samstage normalerweise in die Kategorie "free" und Sonntage in die Kategorie "beforeschool", ebenso landen dort Feiertage vor Schultagen usw.

<source lang="bash">
define tts.wohn Text2Speech pulsewohn
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.wohn TTS_UseMP3Wrap true

define tts.kind1 Text2Speech pulsekind1
attr tts.kind1 TTS_FileTemplateDir /data/misc/announcements/
attr tts.kind1 TTS_UseMP3Wrap true

define tts.kind2 Text2Speech pulsekind2
attr tts.kind2 TTS_FileTemplateDir /data/misc/announcements/
attr tts.kind2 TTS_UseMP3Wrap true

define tts.kueche Text2Speech pulsekueche
attr tts.kueche TTS_FileTemplateDir /data/misc/announcements/
attr tts.kueche TTS_UseMP3Wrap true

define tts.kinder Text2Speech pulsekinder
attr tts.kinder TTS_FileTemplateDir /data/misc/announcements/
attr tts.kinder TTS_UseMP3Wrap true

define tts.unten Text2Speech pulseunten
attr tts.unten TTS_FileTemplateDir /data/misc/announcements/
attr tts.unten TTS_UseMP3Wrap true

define tts.alle Text2Speech pulsealle
attr tts.alle TTS_FileTemplateDir /data/misc/announcements/
attr tts.alle TTS_UseMP3Wrap true
</source>
Hier sind die Definitionen der Text2Speech Module zu sehen (optional). Sie werden jeweils mit den in Pulseaudio definierten Sinks verbunden. Die Nutzung eines TemplateDirs ist ebenfalls optional, hier können bereits fertige MP3s verwendet werden, die dann anstelle der von der Google TTS API erzeugten Dateien benutzt werden. Dies können auch Bestätigungs und Fehlertöne sein, die bei Benutzern ohne Display, die rein mit Fernbedienung arbeiten, auf Fehlbedienungen etc. aufmerksam zu omrhen.

<source lang="bash">
define mpd.kind1 MPD 192.168.2.2 6600
attr mpd.kind1 player mopidy
attr mpd.kind1 bookmarkDir mpdstates
attr mpd.kind1 autoBookmark 1

define mpd.kind2 MPD 192.168.2.2 6702
attr mpd.kind2 player mopidy
attr mpd.kind2 bookmarkDir mpdstates
attr mpd.kind2 autoBookmark 1

define mpd.kueche MPD 192.168.2.2 6703
attr mpd.kueche player mopidy
attr mpd.kueche bookmarkDir mpdstates
attr mpd.kueche autoBookmark 1

define mpd.wohn MPD 192.168.2.2 6704
attr mpd.wohn player mopidy
attr mpd.wohn bookmarkDir mpdstates
attr mpd.wohn autoBookmark 1
</source>
Pro laufender MPD oder Mopidy-Instanz wird ein MPD-Modul eingerichtet. Der Hostname und die Ports sind entsprechend anzupassen. Durch die bookmarkDir und autoBookmark - Attribute wird erreicht, dass der Zustand von Playlisten beim Wechsel derselben gespeichert und später wiederhergestellt werden kann. So lässt sich das Hören eines Hörbuchs unterbrechen, auf z.B. eine Radiostreamplayliste schalten, um dann später zur gleichen Stelle im Hörbuch zurückzukehren.

<source lang="bash">
define omr.kind1 OpenMultiroom
attr omr.kind1 mr scc.kind1
attr omr.kind1 soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.kind1 playlistPattern kind1
attr omr.kind1 ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.kind1 defaultTts tts.kind1
attr omr.kind1 defaultStream kind1
attr omr.kind1 defaultSound mpd.kind1

define omr.kind2 OpenMultiroom
attr omr.kind2 mr scc.kind2
attr omr.kind2 soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.kind2 playlistPattern kind2
attr omr.kind2 ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.kind2 defaultTts tts.kind2
attr omr.kind2 defaultStream kind2
attr omr.kind2 defaultSound mpd.kind2

define omr.kueche OpenMultiroom
attr omr.kueche mr scc.kueche
attr omr.kueche soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.kueche playlistPattern wohn
attr omr.kueche ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.kueche defaultTts tts.kueche
attr omr.kueche defaultStream kueche
attr omr.kueche defaultSound mpd.kueche

define omr.wohn OpenMultiroom
attr omr.wohn mr scc.wohn
attr omr.wohn soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr omr.wohn playlistPattern wohn
attr omr.wohn ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr omr.wohn defaultTts tts.wohn
attr omr.wohn defaultStream wohn
attr omr.wohn defaultSound mpd.wohn
</source>
Die Konfiguration der OpenMultiroom-Module schließt die Einrichtung von FHEM ab. Jede Instanz benötigt mindestens das "mr"- und das "soundMapping"-Attribut. Nur so kann sich das Modul mit den entsprechenden Snapcast und MPD-Modulen verbinden. Durch das "mr"-Attribut wird ein OpenMultiroom-Modul einem Snapcast-Client-Modul fest zugeordnet. Das Soundmapping ordnet die in Snapcast definierten Streams (siehe oben, Konfiguration vom Snapserver) den entsprechenden Instanzen des MPD-Moduls zu. Dadurch weiß FHEM, welcher MPD auf welchem Stream abspielt und kann je nachdem, welchem Stream ein Raum gerade zuhört, den dazu passenden MPD steuern und seine Readings durchreichen. Das OpenMultiroom-Modul bildet alle Readings des MPD-Moduls nochmal direkt ab. Wechselt ein Benutzer aber den Stream, dem er zuhört, aktualisieren sich auch alle Readings dementsprechend mit denen des dann aktuellen MPD-Moduls.

Das Attribut playlistPattern ist optional und sorgt dafür, dass beim Durchschalten der Playlists mit den Kommandos "channelUp" und "channelDown" nur diejenigen Playlists berücksichtigt werden, die auf das Pattern passen.

Analog zum soundMapping definiert das Attribut ttsMapping die Zuordnung der TTS-Module zu den Streams. Beim Ausgeben von Announcement kann so das OpenMultiroom-Modul ermitteln, auf welchem Stream welcher Raum gerade zuhört, und wo dementsprechend die TTS-Ausgaben zu erzeugen sind, damit sie auch in den gewünschten Räumen ankommen. Dieser Umweg ist zurzeit nötig, da ein Snapcast-Client nur auf einem einzigen Stream lauschen kann. Lauschen noch andere Clients auf demselben Stream, hören sie allerdings zwangsweise auch die Announcements.

Die 3 Default-Attribute legen fest, welche der TTS-Module, welcher Stream und welcher MPD dem entsprechenden Modul fest zugeordnet sind. Dies wird u.a. von einer Resetfunktion im Modul verwendet.

== Bedienung des OpenMultiroom-Moduls ==

=== set-Kommandos ===

=== Readings ===

=== Attribute ===

== Anbindung einer Fernbedienung an ein OpenMultiroom-Modul ==

=== Konfiguration von LIRC und IRExec ===

=== Zuordnung der Tasten: Beispiel ===

[[Category:Examples]]
[[Category:HOWTOS]]
[[Category:Unterhaltungselektronik]]

OpenMultiroom

2017-01-25T19:28:52Z

Unimatrix27: Fehler beseitigt (by SublimeText.Mediawiker) (by SublimeText.Mediawiker)

<div style="float:right">{{Infobox Modul
|ModPurpose=Steuern der einzelnen Multiroom-Systemkomponenten
|ModType=d
|ModCmdRef=OpenMultiroom
|ModForumArea=Multimedia
|ModTechName=98_OpenMultiroom.pm
|ModOwner=unimatrix
}}
{{Infobox Modul
|ModPurpose=Steuern eines Snapcast-Servers
|ModType=d
|ModCmdRef=Snapcast
|ModForumArea=Multimedia
|ModTechName=96_Snapcast.pm
|ModOwner=unimatrix
}}
[[Datei:OpenMultiroomOverview.png|mini|400px|Schaubild des Zusammenspiels der einzelnen Komponenten eines Multiroomsystems mit den Backends [https://forum.fhem.de/index.php/topic,18517.msg MPD] und [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] sowie der Nutzung von Text2Speech]]
</div>

Achtung: Dieser Wiki-Artikel und auch das beschriebene Modul sind noch in der Implemntierung und noch nicht verfügbar.

'''OpenMultiroom''' ist ein Steuerungsmodul sowie auch ein Gesamtkonzept zur Realisierung eines Multiroom-Audio-Systems unter Nutzung von ausschließlich frei verfügbarer Software und ohne Bezug auf die Hardware eines bestimmten Herstellers. Es ist so ausgelegt, dass es prinzipiell flexibel bezüglich der Auswahl der Backendsysteme ist. Zurzeit ist es für die Nutzung mit [https://www.musicpd.org/ MPD] bzw. [https://www.mopidy.com/ Mopidy] und [https://github.com/badaix/snapcast Snapcast] implementiert. Daher wird in diesem WIKI-Eintrag immer von diesen Systemen gesprochen. Einen grundsätzlichen Überblick über das Konzept bietet das Schaubild.

== Grobe Übersicht des Funktionsumfangs der Gesamtlösung==
=== Features ===
* Integrierte Steuerung des Musikplayers über das [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul sowie des Multiroom-System [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] in einem einzigen Modul
* Implementierung einer Schnittstelle gemäß [[DevelopmentGuidelinesAV]] als Basis für eine Visualisierung mit z.B. [[SmartVisu]] oder [[FHEM_Tablet_UI]]
* Synchrones Playback auf z.B. Raspberry Pi oder Android-Geräten (Snapcast-Feature)
* optionale Komprimierung der Soundübertragung als OGG oder FLAC (Snapcast-Feature)
* Möglichkeit der Bedienung völlig ohne Display über eine Fernbedienung und entsprechender Text2Speech Rückmeldung, insbesondere
** Durschalten von Playlisten mit entsprechenden Channel - Tasten unter Nutzung von raumspezifischen Filtern
** Forward und Rewind mit definierbaren Sprungweiten (implementiert direkt im [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul)
** Direktanwahl von Playlisten, Tracks oder Trackpositionen durch Zifferneingabe und anschließende Funktionstaste
** Abfrage von Statusinformationen durch Funktionstasten und Text2Speech Rückmeldungen
** Mithören in anderen Räumen und Übernahme des Playerzustandes anderer Räume durch Nutzung von Funktionstasten
** Einschlaftimer per Zifferneingabe oder per vordefinierten Zeitabständen, hierbei wird auch die Restlaufzeit des aktuellen Tracks angeboten.
* manuelles oder automatisches Speichern und Laden von Playlistbookmarks (implementiert direkt im [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul)
* Möglichkeit der Festlegung von tageszeit- und tagestypabhängigen Lautstärkebegrenzungen bis auf 0% z.B. für Kinderzimmer
* individuelles Verwalten von Playlisten für verschiedene Familienmitglieder
* Nutzung des Audiosystems für systemunabhängige FHEM-Announcements. Ein entsprechendes Announcement-Modul ist in Planung. Dabei können mehrere Räume gleichzeitig oder auch getrennt angesprochen werden

=== Anwendungszweck und Kurzbeschreibung der Funktionsweise ===
Wie der Name des Systems vermuten lässt, ist die Lösung vor allem dann sinnvoll einzusetzen, wenn Audiodateien in mindestens 2 verschiedenen Räumen oder "Zonen" sowohl synchron als auch unabhängig abgespielt werden soll und wenn hierzu eine komfortable und integrierte Steuerung über FHEM verwendet werden soll. Mit Einschränkungen ist die Lösung auch dann sinnvoll, wenn es nur um das Abspielen in einem Raum geht. Hier kann dann z.B. die Steuerung über eine Fernbedienung mit Hilfe des '''OpenMultiroom'''-Moduls genutzt werden, die über eine reine Nutzung des MPD-Moduls hinausgeht.

Für die Nutzung ist nicht zwingend ein zentraler Server notwendig. Diese Rolle kann auch von einem der Clients übernommen werden, z.B. einem Pi. Zur einfacheren Darstellung wird in diesem Eintrag jedoch immer von der Nutzung eines Servers ausgegangen, der nicht gleichzeitig auch Client ist.

Das Abspielen von Audio funktioniert prinzipiell in 2 Stufen:
# Nutzung von MPD oder einem MPD-kompatiblen Player zum direkten Abspielen von Sounddateien. Pro existierendem Raum gibt es mindestens eine Instanz von MPD. Hier wird davon ausgegangen, dass es genau eine Instanz pro Raum gibt. Jeder Raum hat also "seinen" MPD.
# Nutzung von Snapcast zur Verteilung des von MPD abgespielten Sounds an den entsprechenden Raum. Snapcast übernimmt hierbei die zeitliche Synchronisation

Durch das Modul '''OpenMultiroom''' steuert der Nutzer sowohl MPD als auch Snapcast. Für jeden Raum wird eine Instanz des Moduls definiert.

=== verwendete komponenten ===
Folgende Komponenten kommen zum Einsatz:

==== Server: ====
* MPD oder Mopidy oder ein anderer MPD-kompatibler Player. 1 Instanz pro Raum
* Snapserver
* mplayer (bei Nutzung von Text 2 Speech)
* Optional Pulseaudio (im System-Mode) bei Nutzung von Text 2 Speech oder erweiterten Konfigurationen. Hierbei wird Pulseaudio zwischen MPD und Snapcast geschaltet.
* Optional Anbindung an Subsonic oder Libresonic (hier zurzeit nicht beschrieben) zur Synchronisation von Playlisten uvm.
* FHEM: Modul 98_OpenMultiroom.pm
* FHEM: Modul 96_Snapcast.pm
* FHEM: Modul 73_MPD.pm
* FHEM: Optional Modul 98_Text2Speech.pm

==== Client: ====
* Linux: Alsa oder Pulseaudio zur Soundwiedergabe
* Linux: Snapclient
* Android: Nur der Android Snapclient
* Webbrowser zur Steuerung per Visualisierung
* ggf. Infrarot oder Funkfernbedienung. In diesem Artikel wird das Beispiel anhand der Nutzung von X10-Funkfernbedienungen gezeigt, diese gibt es sehr günstig in der Bucht o.ä.
* Vision: Nutzung von Tastern und Display am PI oder Nutzung eine Steuergerätes mit Tastern und Display auf Basis eines Arduino mit WLAN, z.B. im alten Gehäuse eines Küchenradios usw.

== Aufbau anhand einer vollständigen Beispielkonfiguration ==

In diesem Artikel soll beispielhaft eine vollständige Konfiguration gezeigt werden. Jeder Nutzer muss diese Konfiguration an seine eigenen Bedürfnisse anpassen. Es seien folgende Komponenten vorhanden:

* Server mit Ubuntu 16.04, hier befindet sich eine MP3-Sammlung
* Kind1: Raspberry Pi Model 1 mit Raspbian
* Kind2: BananaPi mit Ubuntu, an diesem Pi ist auch ein X10 Empfänger angeschlossen, da er zentral im Haus positioniert ist
* Wohnzimmer: Raspberry Pi3 mit OSMC und KODI, wird primär zum Fernsehen verwendet
* Küche: Raspberry Pi Model 1 mit Raspbian

Anmerkung: Es ist möglich, mehrere Räume mit nur einem physikalischen Client zu bedienen. Hierbei werden auf einem Client mehrere Instanzen des Snapclients laufen gelassen. Der physikalische Client hat dann z.B. mehrere USB Soundkarten, dessen Audioausgänge in verschiedene Räume verkabelt sind. Dies wird hier zurzeit nicht näher beschrieben.

=== Pulseaudio Konfiguration ===
Will man Pulseaudio verwenden, z.B. um Text2Speech Nachrichten in laufende Musik einzublenden, sollte dieses am besten zuerst konfiguriert werden. Pulseaudio muss hierzu im System-Mode laufen. Dies ist auf einem Headless-Server kein Problem. Bei Ubuntu 16.10 wird dies durch folgenden Inhalt in ''/etc/systemd/system/pulseaudio.server'' erreicht:
<source lang="bash">
[Unit]
Description=PA
After=network.target sound.target

[Service]
ExecStart=/usr/bin/pulseaudio --system

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>
Weiterhin ist der Befehl
<source lang="bash">sudo systemctl enable pulseaudio</source>
einzugeben, um Pulseaudio beim Systemstart automatisch zu starten.

Ausgehend von der Standardkonfiguration werden nun in ''/etc/pulse/system.pa'' die benötigten Module eingetragen
<source lang="bash">
load-module module-pipe-sink file=/tmp/wohn.fifo sink_name=wohn
load-module module-pipe-sink file=/tmp/kind1.fifo sink_name=kind1
load-module module-pipe-sink file=/tmp/kind2.fifo sink_name=kind2
load-module module-pipe-sink file=/tmp/kueche.fifo sink_name=kueche

load-module module-combine-sink slaves=kind1,kind2 sink_name=kinder
load-module module-combine-sink slaves=wohn,kueche sink_name=unten
load-module module-combine-sink slaves=wohn,kueche,kind1,kind2 sink_name=alle
</source>
Snapcast benötigt die Audioquelle in Form von FIFOs. Daher wird hier in den erstem 4 Zeilen je ein FIFO von Pulseaudio erzeugt. Der sink_name wird später bei der Konfiguration von MPD als Ausgang verwendet. In den 3 letzten Zeilen werden noch 3 weitere Sinks als Combine-Sinks erstellt. Diese erzeugen keine neuen FIFOs, sondern machen under entsprechenden Sink-Namen eine vorgegebene Kombination von Räumen nach außen hin verfügbar. Der Sink "alle" kann also genutzt werden, um Audio auf allen 4 FIFOs gleichzeitig abzuspielen (und somit später potentiall in allen Räumen gleichzeitig). Dies kann für Announcements sinnvoll sein. Die Nutzung dieser Combine-Sinks ist optional.

=== Snapcast Konfiguration ===
[https://github.com/badaix/snapcast Snapcast] muss entsprechend der Angaben auf der Webseite installiert werden. Auf dem Server muss logischerweise die Serverkomponente und auf den Clients die Clientkomponente installiert werden. Bei Android-Clients wird die auf der Webseite zur Verfügung gestellt APK installiert. Snapcast befindet sich selbst noch in fortlaufender Entwicklung. Die hier vorgestellte Lösung ist mit [https://github.com/badaix/snapcast/tree/98be8a58d945f84af50e40ebcf8a774592dd6e7b dieser Version] kompatibel und getestet.

Die Konfiguration des Servers beschränkt sich auf die Definition der Streams in ''/etc/default/snapserver''
<source lang="bash">
START_SNAPSERVER=true
SNAPSERVER_OPTS="-d -s pipe:///tmp/kind1.fifo?name=kind1&mode=read -s pipe:///tmp/kind2.fifo?name=kind2&mode=read -s pipe:///tmp/wohn.fifo?name=wohn&mode=read -s pipe:///tmp/kueche.fifo?name=kueche&mode=read"
</source>
Hier werden die 4 Streams erstellt, diese entsprechen vom Dateinamen her der Pulseaudiokonfiguration. Der hier verwendete Name kann später in FHEM oder auch im Android-Client angezeigt werden. Die Option <pre>mode=read</pre> ist wichtig, weil Pulseaudio meckert, wenn es die FIFO-Dateien nicht selbst anlegen darf.

Auf der Clientseite sieht die Datei ''/etc/default/snapclient'' dann so aus:
<source lang="bash">
START_SNAPCLIENT=true
SNAPCLIENT_OPTS="-d -s dmix:CARD=Aureon51MkII,DEV=0"
</source>
Den Server findet der Snapclient automatisch, er kann aber auch angegeben werden. Wie hier zu sehen kann ein spezielles Output-Device angegeben werden. Dies ist bei den PIs mit externer USB-Soundkarte meistens notwendig, da ansonsten der interne Sound genutzt würde. Eine Liste der verfügbaren Devices wird mit dem Aufruf von <pre>snapclient -l</pre> ausgegeben, hier muss dann das passende genommen werden. GGf. so lange ausprobieren, bis der Sound an der richtigen Stelle rauskommt.

In der hier betrachteten Konfiguration soll auf dem Wohnzimmer-PI ein Snapclient laufen, dieser wird aber normalerweise zum TV und Filme schauen mit KODI verwendet. Sowohl KODI als auch der Snapclient blockieren aber das ALSA-Device und funktionieren beide meistens entweder gar nicht oder nicht richtig zusammen, insbesondere dann nicht, wenn von KODI Mehrkanalsound oder sogar Passthrough ausgegeben wird. Die Entwicklung eines nativen Snapcast-Clients innerhalb von KODI wird gerade an verschiedenen Stellen diskutiert, z.B. [https://github.com/badaix/snapcast/issues/155 hier]. Bis dahin kann ein kleiner Workaround Abhilfe schaffen. Mit folgendem (nur rudimentär getesteten) [https://github.com/unimatrix27/snapcast/commit/88e42a2ecc8b44223701e18abb63af04b673b67b Hack] für den Snapcast-Client wird erreicht, dass der Client das ALSA-Device frei gibt, sobald er über den Server auf Mute gestellt wird. KODI selbst gibt das Device ebenfalls frei, wenn es im Zustand "Stop" ist. Bei dieser Lösung kann der Snapclient auf dem KODI-Rechner immer laufen gelassen werde. Es ist jedoch in der Verantwortung des Benutzers, den Client zu "muten". Vergisst er dies, wird ggf. die Wiedergabe in KODI nicht möglich sein.

Nach Abschluss der Snapcastkonfiguration und dem Starten von Server und den Clients empfiehlt es sich, die Android-App ebenfalls zu verwenden, da diese einen schnellen Überblick über den Zustand des Servers, der konfigurierten Streams und der Clients bietet.

=== Mopidy Konfiguration ===

In diesem Beispiel wird Mopidy als MPD-Ersatz verwendet, genau so gut kann aber auch direkt MPD verwendet werden. Die genauen Konfigurationsoptionen sind natürlich anders, und jeweils in entsprechenden Tutorials oder Dokumentationen beschrieben. Mopidy ist relativ umfangreich und modular aufgebaut, es bietet u.a. die Möglichkeit, neben lokal gespeicherten Dateien auch Dateien von verschiedenen, teilweise kommerziellen, Streamingdiensten abzuspielen. Die Detailkonfiguration all dieser Komponenten geht über diesen Artikel hinaus. Entscheidend hier ist die Konfiguration in einer Weise, so dass mehrere Mopidy-Instanzen gleichzeitig ausgeführt werden können und dann auf unterschiedlichen Ports zur Verfügung stehen.

Nach Installation von Mopidy findet sich die Konfiguration in der Datei ''/etc/mopidy/mopidy.cfg''. Mopidy unterstützt hierarische Konfigurationen, es reicht also, den für jede Instanz spezifischen Teil aus dieser allgemeinen Konfiguration zu entfernen und in jeweils eigene Dateien zu verschieben. In diesem Beispiel sollen das die Dateien ''/etc/mopidy/kind1.conf'' bis ''/etc/mopidy/kueche.conf'' sein. Die folgenden Zeilen gehören jeweils in diese 4 Dateien und werden dort entsprechend angepasst. Hier das Beispiel für Kind2:

<source lang="bash">
[logging]
config_file = /etc/mopidy/logging_kind2.conf
debug_file = /var/log/mopidy/mopidy-debug_kind2.log

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! pulsesink device=kind2

[mpd]
enabled = true
hostname = 0.0.0.0
port=6601

[http]
enabled = true
hostname = 0.0.0.0
port=6681
zeroconf = Musik Kind2
</source>

Im Audioteil wird der entsprechende Sink aus der Pulseaudiokonfiguration genommen. Beim MPD muss der Port für jede Instanz unterschiedlich sein, ebenso beim HTTP-Modul für die Weboberfläche der jeweiligen Instanz. Der Zerokonfname sollte auch eindeutig sein. Neben dieser Datei ist noch die dazu passende logging-Konfiguration anzulegen, hier also ''/etc/mopidy/logging_kind2.conf''. Dazu wird die Standarddatei kopiert und darin nur der Name der Logdatei angepasst.

Um nun auch die entsprechende Anzahl Instanzen automatisch zu starten, sind die entsprechenden Startdateien anzulegen. Dazu kann die Datei ''/etc/systemd/system/mopidy.cfg'' z.B. in ''/etc/systemd/system/mopidy_kind1.cfg'' umbenannt werden und dann 3 mal mit den Endungen der anderen Instanzen kopiert werden. Der Inhalt ist dann wie folgt:

<source lang="bash">
[Unit]
Description=Mopidy_kind1
After=network.target sound.target

[Service]
EnvironmentFile=/etc/default/mopidy
ExecStart=/usr/bin/mopidy --quiet --config /etc/mopidy/kind1.conf

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>

Abschließend sollten die 4 Instanzen durch den Aufruf von <pre>systemctl enable mopidy_kind1</pre> usw. aktiviert werden. Es empfiehlt sich nach dem Start von Mopidy die korrekte Funtkionsweise mit dem [https://www.musicpd.org/clients/mpc/ MPC]-Client oder mit [http://rybczak.net/ncmpcpp/ NCMPCPP] auf der Konsole zu testen.

Hierbei sollte es dann bereits möglich sein, die Multiroom-Fähigkeiten von Snapcast mit Hilfe des Android-Clients von Snapcast zu testen und so auch festzustellen, dass die restliche Konfiguration von Snapcast und Pulseaudio korrekt sind.

=== FHEM ===

In FHEM sind nun in der ''fhem.cfg'' die entsprechenden Module einzurichten:
* Ein Snapcast-Modul im Server Modus
* Pro Raum ein Snapcast-Modul im Clientmodus
* Pro Raum ein MPD-Modul
* Pro Raum ein OpenMultiroom-Modul
* Optional pro Raum ein Text2Speech-Modul
* weitere Text2Speech-Module, falls man diese in Pulseaudio mit dem per Combine-Sink vorgesehen hat.

<source lang="bash">
define scs.snap Snapcast

define scc.kind1 Snapcast client scs.snap b827eb9aec84
attr scc.kind1 constraintDummy freestring
attr scc.kind1 constraints standard|07:00 0 20:00 100 21:00 50 21:30 30 24:00 0,beforefree|07:00 0 21:00 100 22:00 50 23:00 30 24:00 0,beforeschool|07:00 0 08:30 50 20:00 100 21:00 50 21:30 30 24:00 0,free|07:00 0 08:30 50 21:00 100 22:00 50 23:00 30 24:00 0

define scc.kind2 Snapcast client scs.snap 025009413c29
attr scc.kind2 constraintDummy freestring
attr scc.kind2 constraints standard|07:00 0 20:15 100 20:30 50 24:00 0,beforefree|07:00 0 21:00 100 22:30 50 24:00 0,beforeschool|07:00 0 08:30 50 20:15 100 20:30 50 24:00 0,free|07:00 0 08:30 50 21:00 100 22:30 50 24:00 0

define scc.kueche Snapcast client scs.snap b827eb9a2ad3

define scc.wohn Snapcast client scs.snap 00aefa4aa3a9
</source>

Oben zu sehen ist das define für das Server-Modul. Ohne Parameter verbindet sich mit localhost auf dem Standardport 1705. Es folgt die Definition von 2 Clients. Der erste Parameter "client" versetzt das Snapcastmodul in den Clientmodus. Der zweite Parameter verweist auf das Servermodul, der dritte Parameter ist die Client-ID. Diese besteht bei der aktuellen Snapcast-Version meistens aus der MAC-Adresse des Clients. Für die Kinder werden noch die Attribute constraintDummy ond constraints vergeben. Hiermit wird eine tagestyp- und tageszeitabhängige Lautstärkebegrenzung konfiguriert. Für die vier Tagestypen "standard", "beforefree", "beforeschool" und "free" wird ein jeweils anderes Lautstärkezeitprofil definiert.

Das Zeitprofil wird hier nach dem gleichen Muster wie die Temperaturlisten der Homematic-Thermostate, erklärt hier: [HomeMatic_Type_Thermostat]. Für den Tagestyp wird zusätzlich das Attribut constraintDummy verwendet. Es definiert, dass in dem Dummy "freestring" jeweils drin steht, welcher Tagestyp gerade ist. Diese Variable wirkt somit als Selektor auf die Liste der erlaubten Maximallautstärken. Wie eine solche Dummyvariable jeweils mit einem entsprechenden Wert befüllt werden kann, z.B. abhängig vom Wochentag, von Schulferien oder Feiertagen, wird hier nicht erläutert. Es ist auch möglich, nur ein Lautstärkeprofil anzugeben. Ohne dass ein Attribut constraintDummy gesetzt ist, verwendet das Snapcastmodul immer den Wert "standard". Wie man hier sehen kann, gibt es im Beispiel 4 Typen, hierbei fallen Freitage normalerweise in die Kategorie "beforefree" (es sind Tage, bevor dann frei ist, es kann also typischerweise länger und lauter Musik gehört werden), Samstage normalerweise in die Kategorie "free" und Sonntage in die Kategorie "beforeschool", ebenso landen dort Feiertage vor Schultagen usw.

<source lang="bash">
define tts.wohn Text2Speech pulsewohn
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.wohn TTS_UseMP3Wrap true

define tts.kind1 Text2Speech pulsekind1
attr tts.kind1 TTS_FileTemplateDir /data/misc/announcements/
attr tts.kind1 TTS_UseMP3Wrap true

define tts.kind2 Text2Speech pulsekind2
attr tts.kind2 TTS_FileTemplateDir /data/misc/announcements/
attr tts.kind2 TTS_UseMP3Wrap true

define tts.kueche Text2Speech pulsekueche
attr tts.kueche TTS_FileTemplateDir /data/misc/announcements/
attr tts.kueche TTS_UseMP3Wrap true

define tts.kinder Text2Speech pulsekinder
attr tts.kinder TTS_FileTemplateDir /data/misc/announcements/
attr tts.kinder TTS_UseMP3Wrap true

define tts.unten Text2Speech pulseunten
attr tts.unten TTS_FileTemplateDir /data/misc/announcements/
attr tts.unten TTS_UseMP3Wrap true

define tts.alle Text2Speech pulsealle
attr tts.alle TTS_FileTemplateDir /data/misc/announcements/
attr tts.alle TTS_UseMP3Wrap true
</source>
Hier sind die Definitionen der Text2Speech Module zu sehen (optional). Sie werden jeweils mit den in Pulseaudio definierten Sinks verbunden. Die Nutzung eines TemplateDirs ist ebenfalls optional, hier können bereits fertige MP3s verwendet werden, die dann anstelle der von der Google TTS API erzeugten Dateien benutzt werden. Dies können auch Bestätigungs und Fehlertöne sein, die bei Benutzern ohne Display, die rein mit Fernbedienung arbeiten, auf Fehlbedienungen etc. aufmerksam zu machen.

<source lang="bash">
define mpd.kind1 MPD 192.168.2.2 6600
attr mpd.kind1 player mopidy
attr mpd.kind1 bookmarkDir mpdstates
attr mpd.kind1 autoBookmark 1

define mpd.kind2 MPD 192.168.2.2 6702
attr mpd.kind2 player mopidy
attr mpd.kind2 bookmarkDir mpdstates
attr mpd.kind2 autoBookmark 1

define mpd.kueche MPD 192.168.2.2 6703
attr mpd.kueche player mopidy
attr mpd.kueche bookmarkDir mpdstates
attr mpd.kueche autoBookmark 1

define mpd.wohn MPD 192.168.2.2 6704
attr mpd.wohn player mopidy
attr mpd.wohn bookmarkDir mpdstates
attr mpd.wohn autoBookmark 1
</source>
Pro laufender MPD oder Mopidy-Instanz wird ein MPD-Modul eingerichtet. Der Hostname und die Ports sind entsprechend anzupassen. Durch die bookmarkDir und autoBookmark - Attribute wird erreicht, dass der Zustand von Playlisten beim Wechsel derselben gespeichert und später wiederhergestellt werden kann. So lässt sich das Hören eines Hörbuchs unterbrechen, auf z.B. eine Radiostreamplayliste schalten, um dann später zur gleichen Stelle im Hörbuch zurückzukehren.

<source lang="bash">
define mac.kind1 MultiroomAudioController
attr mac.kind1 mr scc.kind1
attr mac.kind1 soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.kind1 playlistPattern kind1
attr mac.kind1 ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr mac.kind1 defaultTts tts.kind1
attr mac.kind1 defaultStream kind1
attr mac.kind1 defaultSound mpd.kind1

define mac.kind2 MultiroomAudioController
attr mac.kind2 mr scc.kind2
attr mac.kind2 soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.kind2 playlistPattern kind2
attr mac.kind2 ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr mac.kind2 defaultTts tts.kind2
attr mac.kind2 defaultStream kind2
attr mac.kind2 defaultSound mpd.kind2

define mac.kueche MultiroomAudioController
attr mac.kueche mr scc.kueche
attr mac.kueche soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.kueche playlistPattern wohn
attr mac.kueche ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr mac.kueche defaultTts tts.kueche
attr mac.kueche defaultStream kueche
attr mac.kueche defaultSound mpd.kueche

define mac.wohn MultiroomAudioController
attr mac.wohn mr scc.wohn
attr mac.wohn soundMapping kind1:mpd.kind1,kind2:mpd.kind2,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.wohn playlistPattern wohn
attr mac.wohn ttsMapping kind1:tts.kind1,kind2:tts.kind2,kueche:tts.kueche,wohn:tts.wohn
attr mac.wohn defaultTts tts.wohn
attr mac.wohn defaultStream wohn
attr mac.wohn defaultSound mpd.wohn
</source>
Die Konfiguration der OpenMultiroom-Module schließt die Einrichtung von FHEM ab. Jede Instanz benötigt mindestens das "mr"- und das "soundMapping"-Attribut. Nur so kann sich das Modul mit den entsprechenden Snapcast und MPD-Modulen verbinden. Durch das "mr"-Attribut wird ein OpenMultiroom-Modul einem Snapcast-Client-Modul fest zugeordnet. Das Soundmapping ordnet die in Snapcast definierten Streams (siehe oben, Konfiguration vom Snapserver) den entsprechenden Instanzen des MPD-Moduls zu. Dadurch weiß FHEM, welcher MPD auf welchem Stream abspielt und kann je nachdem, welchem Stream ein Raum gerade zuhört, den dazu passenden MPD steuern und seine Readings durchreichen. Das OpenMultiroom-Modul bildet alle Readings des MPD-Moduls nochmal direkt ab. Wechselt ein Benutzer aber den Stream, dem er zuhört, aktualisieren sich auch alle Readings dementsprechend mit denen des dann aktuellen MPD-Moduls.

Das Attribut playlistPattern ist optional und sorgt dafür, dass beim Durchschalten der Playlists mit den Kommandos "channelUp" und "channelDown" nur diejenigen Playlists berücksichtigt werden, die auf das Pattern passen.

Analog zum soundMapping definiert das Attribut ttsMapping die Zuordnung der TTS-Module zu den Streams. Beim Ausgeben von Announcement kann so das OpenMultiroom-Modul ermitteln, auf welchem Stream welcher Raum gerade zuhört, und wo dementsprechend die TTS-Ausgaben zu erzeugen sind, damit sie auch in den gewünschten Räumen ankommen. Dieser Umweg ist zurzeit nötig, da ein Snapcast-Client nur auf einem einzigen Stream lauschen kann. Lauschen noch andere Clients auf demselben Stream, hören sie allerdings zwangsweise auch die Announcements.

Die 3 Default-Attribute legen fest, welche der TTS-Module, welcher Stream und welcher MPD dem entsprechenden Modul fest zugeordnet sind. Dies wird u.a. von einer Resetfunktion im Modul verwendet.

== Bedienung des OpenMultiroom-Moduls ==

=== set-Kommandos ===

=== Readings ===

=== Attribute ===

== Anbindung einer Fernbedienung an ein OpenMultiroom-Modul ==

=== Konfiguration von LIRC und IRExec ===

=== Zuordnung der Tasten: Beispiel ===

[[Category:Examples]]
[[Category:HOWTOS]]
[[Category:Unterhaltungselektronik]]

OpenMultiroom

2017-01-25T19:27:35Z

Unimatrix27: Konfiguration vervollstaendigt (by SublimeText.Mediawiker) (by SublimeText.Mediawiker)

<div style="float:right">{{Infobox Modul
|ModPurpose=Steuern der einzelnen Multiroom-Systemkomponenten
|ModType=d
|ModCmdRef=OpenMultiroom
|ModForumArea=Multimedia
|ModTechName=98_OpenMultiroom.pm
|ModOwner=unimatrix
}}
{{Infobox Modul
|ModPurpose=Steuern eines Snapcast-Servers
|ModType=d
|ModCmdRef=Snapcast
|ModForumArea=Multimedia
|ModTechName=96_Snapcast.pm
|ModOwner=unimatrix
}}
[[Datei:OpenMultiroomOverview.png|mini|400px|Schaubild des Zusammenspiels der einzelnen Komponenten eines Multiroomsystems mit den Backends [https://forum.fhem.de/index.php/topic,18517.msg MPD] und [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] sowie der Nutzung von Text2Speech]]
</div>

Achtung: Dieser Wiki-Artikel und auch das beschriebene Modul sind noch in der Implemntierung und noch nicht verfügbar.

'''OpenMultiroom''' ist ein Steuerungsmodul sowie auch ein Gesamtkonzept zur Realisierung eines Multiroom-Audio-Systems unter Nutzung von ausschließlich frei verfügbarer Software und ohne Bezug auf die Hardware eines bestimmten Herstellers. Es ist so ausgelegt, dass es prinzipiell flexibel bezüglich der Auswahl der Backendsysteme ist. Zurzeit ist es für die Nutzung mit [https://www.musicpd.org/ MPD] bzw. [https://www.mopidy.com/ Mopidy] und [https://github.com/badaix/snapcast Snapcast] implementiert. Daher wird in diesem WIKI-Eintrag immer von diesen Systemen gesprochen. Einen grundsätzlichen Überblick über das Konzept bietet das Schaubild.

== Grobe Übersicht des Funktionsumfangs der Gesamtlösung==
=== Features ===
* Integrierte Steuerung des Musikplayers über das [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul sowie des Multiroom-System [https://forum.fhem.de/index.php/topic,62389.0.html Snapcast] in einem einzigen Modul
* Implementierung einer Schnittstelle gemäß [[DevelopmentGuidelinesAV]] als Basis für eine Visualisierung mit z.B. [[SmartVisu]] oder [[FHEM_Tablet_UI]]
* Synchrones Playback auf z.B. Raspberry Pi oder Android-Geräten (Snapcast-Feature)
* optionale Komprimierung der Soundübertragung als OGG oder FLAC (Snapcast-Feature)
* Möglichkeit der Bedienung völlig ohne Display über eine Fernbedienung und entsprechender Text2Speech Rückmeldung, insbesondere
** Durschalten von Playlisten mit entsprechenden Channel - Tasten unter Nutzung von raumspezifischen Filtern
** Forward und Rewind mit definierbaren Sprungweiten (implementiert direkt im [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul)
** Direktanwahl von Playlisten, Tracks oder Trackpositionen durch Zifferneingabe und anschließende Funktionstaste
** Abfrage von Statusinformationen durch Funktionstasten und Text2Speech Rückmeldungen
** Mithören in anderen Räumen und Übernahme des Playerzustandes anderer Räume durch Nutzung von Funktionstasten
** Einschlaftimer per Zifferneingabe oder per vordefinierten Zeitabständen, hierbei wird auch die Restlaufzeit des aktuellen Tracks angeboten.
* manuelles oder automatisches Speichern und Laden von Playlistbookmarks (implementiert direkt im [https://forum.fhem.de/index.php/topic,18517.msg MPD]-Modul)
* Möglichkeit der Festlegung von tageszeit- und tagestypabhängigen Lautstärkebegrenzungen bis auf 0% z.B. für Kinderzimmer
* individuelles Verwalten von Playlisten für verschiedene Familienmitglieder
* Nutzung des Audiosystems für systemunabhängige FHEM-Announcements. Ein entsprechendes Announcement-Modul ist in Planung. Dabei können mehrere Räume gleichzeitig oder auch getrennt angesprochen werden

=== Anwendungszweck und Kurzbeschreibung der Funktionsweise ===
Wie der Name des Systems vermuten lässt, ist die Lösung vor allem dann sinnvoll einzusetzen, wenn Audiodateien in mindestens 2 verschiedenen Räumen oder "Zonen" sowohl synchron als auch unabhängig abgespielt werden soll und wenn hierzu eine komfortable und integrierte Steuerung über FHEM verwendet werden soll. Mit Einschränkungen ist die Lösung auch dann sinnvoll, wenn es nur um das Abspielen in einem Raum geht. Hier kann dann z.B. die Steuerung über eine Fernbedienung mit Hilfe des '''OpenMultiroom'''-Moduls genutzt werden, die über eine reine Nutzung des MPD-Moduls hinausgeht.

Für die Nutzung ist nicht zwingend ein zentraler Server notwendig. Diese Rolle kann auch von einem der Clients übernommen werden, z.B. einem Pi. Zur einfacheren Darstellung wird in diesem Eintrag jedoch immer von der Nutzung eines Servers ausgegangen, der nicht gleichzeitig auch Client ist.

Das Abspielen von Audio funktioniert prinzipiell in 2 Stufen:
# Nutzung von MPD oder einem MPD-kompatiblen Player zum direkten Abspielen von Sounddateien. Pro existierendem Raum gibt es mindestens eine Instanz von MPD. Hier wird davon ausgegangen, dass es genau eine Instanz pro Raum gibt. Jeder Raum hat also "seinen" MPD.
# Nutzung von Snapcast zur Verteilung des von MPD abgespielten Sounds an den entsprechenden Raum. Snapcast übernimmt hierbei die zeitliche Synchronisation

Durch das Modul '''OpenMultiroom''' steuert der Nutzer sowohl MPD als auch Snapcast. Für jeden Raum wird eine Instanz des Moduls definiert.

=== verwendete komponenten ===
Folgende Komponenten kommen zum Einsatz:

==== Server: ====
* MPD oder Mopidy oder ein anderer MPD-kompatibler Player. 1 Instanz pro Raum
* Snapserver
* mplayer (bei Nutzung von Text 2 Speech)
* Optional Pulseaudio (im System-Mode) bei Nutzung von Text 2 Speech oder erweiterten Konfigurationen. Hierbei wird Pulseaudio zwischen MPD und Snapcast geschaltet.
* Optional Anbindung an Subsonic oder Libresonic (hier zurzeit nicht beschrieben) zur Synchronisation von Playlisten uvm.
* FHEM: Modul 98_OpenMultiroom.pm
* FHEM: Modul 96_Snapcast.pm
* FHEM: Modul 73_MPD.pm
* FHEM: Optional Modul 98_Text2Speech.pm

==== Client: ====
* Linux: Alsa oder Pulseaudio zur Soundwiedergabe
* Linux: Snapclient
* Android: Nur der Android Snapclient
* Webbrowser zur Steuerung per Visualisierung
* ggf. Infrarot oder Funkfernbedienung. In diesem Artikel wird das Beispiel anhand der Nutzung von X10-Funkfernbedienungen gezeigt, diese gibt es sehr günstig in der Bucht o.ä.
* Vision: Nutzung von Tastern und Display am PI oder Nutzung eine Steuergerätes mit Tastern und Display auf Basis eines Arduino mit WLAN, z.B. im alten Gehäuse eines Küchenradios usw.

== Aufbau anhand einer vollständigen Beispielkonfiguration ==

In diesem Artikel soll beispielhaft eine vollständige Konfiguration gezeigt werden. Jeder Nutzer muss diese Konfiguration an seine eigenen Bedürfnisse anpassen. Es seien folgende Komponenten vorhanden:

* Server mit Ubuntu 16.04, hier befindet sich eine MP3-Sammlung
* Kind1: Raspberry Pi Model 1 mit Raspbian
* Kind2: BananaPi mit Ubuntu, an diesem Pi ist auch ein X10 Empfänger angeschlossen, da er zentral im Haus positioniert ist
* Wohnzimmer: Raspberry Pi3 mit OSMC und KODI, wird primär zum Fernsehen verwendet
* Küche: Raspberry Pi Model 1 mit Raspbian

Anmerkung: Es ist möglich, mehrere Räume mit nur einem physikalischen Client zu bedienen. Hierbei werden auf einem Client mehrere Instanzen des Snapclients laufen gelassen. Der physikalische Client hat dann z.B. mehrere USB Soundkarten, dessen Audioausgänge in verschiedene Räume verkabelt sind. Dies wird hier zurzeit nicht näher beschrieben.

=== Pulseaudio Konfiguration ===
Will man Pulseaudio verwenden, z.B. um Text2Speech Nachrichten in laufende Musik einzublenden, sollte dieses am besten zuerst konfiguriert werden. Pulseaudio muss hierzu im System-Mode laufen. Dies ist auf einem Headless-Server kein Problem. Bei Ubuntu 16.10 wird dies durch folgenden Inhalt in ''/etc/systemd/system/pulseaudio.server'' erreicht:
<source lang="bash">
[Unit]
Description=PA
After=network.target sound.target

[Service]
ExecStart=/usr/bin/pulseaudio --system

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>
Weiterhin ist der Befehl
<source lang="bash">sudo systemctl enable pulseaudio</source>
einzugeben, um Pulseaudio beim Systemstart automatisch zu starten.

Ausgehend von der Standardkonfiguration werden nun in ''/etc/pulse/system.pa'' die benötigten Module eingetragen
<source lang="bash">
load-module module-pipe-sink file=/tmp/wohn.fifo sink_name=wohn
load-module module-pipe-sink file=/tmp/kind1.fifo sink_name=kind1
load-module module-pipe-sink file=/tmp/kind2.fifo sink_name=kind2
load-module module-pipe-sink file=/tmp/kueche.fifo sink_name=kueche

load-module module-combine-sink slaves=kind1,kind2 sink_name=kinder
load-module module-combine-sink slaves=wohn,kueche sink_name=unten
load-module module-combine-sink slaves=wohn,kueche,kind1,kind2 sink_name=alle
</source>
Snapcast benötigt die Audioquelle in Form von FIFOs. Daher wird hier in den erstem 4 Zeilen je ein FIFO von Pulseaudio erzeugt. Der sink_name wird später bei der Konfiguration von MPD als Ausgang verwendet. In den 3 letzten Zeilen werden noch 3 weitere Sinks als Combine-Sinks erstellt. Diese erzeugen keine neuen FIFOs, sondern machen under entsprechenden Sink-Namen eine vorgegebene Kombination von Räumen nach außen hin verfügbar. Der Sink "alle" kann also genutzt werden, um Audio auf allen 4 FIFOs gleichzeitig abzuspielen (und somit später potentiall in allen Räumen gleichzeitig). Dies kann für Announcements sinnvoll sein. Die Nutzung dieser Combine-Sinks ist optional.

=== Snapcast Konfiguration ===
[https://github.com/badaix/snapcast Snapcast] muss entsprechend der Angaben auf der Webseite installiert werden. Auf dem Server muss logischerweise die Serverkomponente und auf den Clients die Clientkomponente installiert werden. Bei Android-Clients wird die auf der Webseite zur Verfügung gestellt APK installiert. Snapcast befindet sich selbst noch in fortlaufender Entwicklung. Die hier vorgestellte Lösung ist mit [https://github.com/badaix/snapcast/tree/98be8a58d945f84af50e40ebcf8a774592dd6e7b dieser Version] kompatibel und getestet.

Die Konfiguration des Servers beschränkt sich auf die Definition der Streams in ''/etc/default/snapserver''
<source lang="bash">
START_SNAPSERVER=true
SNAPSERVER_OPTS="-d -s pipe:///tmp/kind1.fifo?name=kind1&mode=read -s pipe:///tmp/kind2.fifo?name=kind2&mode=read -s pipe:///tmp/wohn.fifo?name=wohn&mode=read -s pipe:///tmp/kueche.fifo?name=kueche&mode=read"
</source>
Hier werden die 4 Streams erstellt, diese entsprechen vom Dateinamen her der Pulseaudiokonfiguration. Der hier verwendete Name kann später in FHEM oder auch im Android-Client angezeigt werden. Die Option <pre>mode=read</pre> ist wichtig, weil Pulseaudio meckert, wenn es die FIFO-Dateien nicht selbst anlegen darf.

Auf der Clientseite sieht die Datei ''/etc/default/snapclient'' dann so aus:
<source lang="bash">
START_SNAPCLIENT=true
SNAPCLIENT_OPTS="-d -s dmix:CARD=Aureon51MkII,DEV=0"
</source>
Den Server findet der Snapclient automatisch, er kann aber auch angegeben werden. Wie hier zu sehen kann ein spezielles Output-Device angegeben werden. Dies ist bei den PIs mit externer USB-Soundkarte meistens notwendig, da ansonsten der interne Sound genutzt würde. Eine Liste der verfügbaren Devices wird mit dem Aufruf von <pre>snapclient -l</pre> ausgegeben, hier muss dann das passende genommen werden. GGf. so lange ausprobieren, bis der Sound an der richtigen Stelle rauskommt.

In der hier betrachteten Konfiguration soll auf dem Wohnzimmer-PI ein Snapclient laufen, dieser wird aber normalerweise zum TV und Filme schauen mit KODI verwendet. Sowohl KODI als auch der Snapclient blockieren aber das ALSA-Device und funktionieren beide meistens entweder gar nicht oder nicht richtig zusammen, insbesondere dann nicht, wenn von KODI Mehrkanalsound oder sogar Passthrough ausgegeben wird. Die Entwicklung eines nativen Snapcast-Clients innerhalb von KODI wird gerade an verschiedenen Stellen diskutiert, z.B. [https://github.com/badaix/snapcast/issues/155 hier]. Bis dahin kann ein kleiner Workaround Abhilfe schaffen. Mit folgendem (nur rudimentär getesteten) [https://github.com/unimatrix27/snapcast/commit/88e42a2ecc8b44223701e18abb63af04b673b67b Hack] für den Snapcast-Client wird erreicht, dass der Client das ALSA-Device frei gibt, sobald er über den Server auf Mute gestellt wird. KODI selbst gibt das Device ebenfalls frei, wenn es im Zustand "Stop" ist. Bei dieser Lösung kann der Snapclient auf dem KODI-Rechner immer laufen gelassen werde. Es ist jedoch in der Verantwortung des Benutzers, den Client zu "muten". Vergisst er dies, wird ggf. die Wiedergabe in KODI nicht möglich sein.

Nach Abschluss der Snapcastkonfiguration und dem Starten von Server und den Clients empfiehlt es sich, die Android-App ebenfalls zu verwenden, da diese einen schnellen Überblick über den Zustand des Servers, der konfigurierten Streams und der Clients bietet.

=== Mopidy Konfiguration ===

In diesem Beispiel wird Mopidy als MPD-Ersatz verwendet, genau so gut kann aber auch direkt MPD verwendet werden. Die genauen Konfigurationsoptionen sind natürlich anders, und jeweils in entsprechenden Tutorials oder Dokumentationen beschrieben. Mopidy ist relativ umfangreich und modular aufgebaut, es bietet u.a. die Möglichkeit, neben lokal gespeicherten Dateien auch Dateien von verschiedenen, teilweise kommerziellen, Streamingdiensten abzuspielen. Die Detailkonfiguration all dieser Komponenten geht über diesen Artikel hinaus. Entscheidend hier ist die Konfiguration in einer Weise, so dass mehrere Mopidy-Instanzen gleichzeitig ausgeführt werden können und dann auf unterschiedlichen Ports zur Verfügung stehen.

Nach Installation von Mopidy findet sich die Konfiguration in der Datei ''/etc/mopidy/mopidy.cfg''. Mopidy unterstützt hierarische Konfigurationen, es reicht also, den für jede Instanz spezifischen Teil aus dieser allgemeinen Konfiguration zu entfernen und in jeweils eigene Dateien zu verschieben. In diesem Beispiel sollen das die Dateien ''/etc/mopidy/kind1.conf'' bis ''/etc/mopidy/kueche.conf'' sein. Die folgenden Zeilen gehören jeweils in diese 4 Dateien und werden dort entsprechend angepasst. Hier das Beispiel für Kind2:

<source lang="bash">
[logging]
config_file = /etc/mopidy/logging_kind2.conf
debug_file = /var/log/mopidy/mopidy-debug_kind2.log

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! pulsesink device=kind2

[mpd]
enabled = true
hostname = 0.0.0.0
port=6601

[http]
enabled = true
hostname = 0.0.0.0
port=6681
zeroconf = Musik Kind2
</source>

Im Audioteil wird der entsprechende Sink aus der Pulseaudiokonfiguration genommen. Beim MPD muss der Port für jede Instanz unterschiedlich sein, ebenso beim HTTP-Modul für die Weboberfläche der jeweiligen Instanz. Der Zerokonfname sollte auch eindeutig sein. Neben dieser Datei ist noch die dazu passende logging-Konfiguration anzulegen, hier also ''/etc/mopidy/logging_kind2.conf''. Dazu wird die Standarddatei kopiert und darin nur der Name der Logdatei angepasst.

Um nun auch die entsprechende Anzahl Instanzen automatisch zu starten, sind die entsprechenden Startdateien anzulegen. Dazu kann die Datei ''/etc/systemd/system/mopidy.cfg'' z.B. in ''/etc/systemd/system/mopidy_kind1.cfg'' umbenannt werden und dann 3 mal mit den Endungen der anderen Instanzen kopiert werden. Der Inhalt ist dann wie folgt:

<source lang="bash">
[Unit]
Description=Mopidy_kind1
After=network.target sound.target

[Service]
EnvironmentFile=/etc/default/mopidy
ExecStart=/usr/bin/mopidy --quiet --config /etc/mopidy/kind1.conf

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target
</source>

Abschließend sollten die 4 Instanzen durch den Aufruf von <pre>systemctl enable mopidy_kind1</pre> usw. aktiviert werden. Es empfiehlt sich nach dem Start von Mopidy die korrekte Funtkionsweise mit dem [https://www.musicpd.org/clients/mpc/ MPC]-Client oder mit [http://rybczak.net/ncmpcpp/ NCMPCPP] auf der Konsole zu testen.

Hierbei sollte es dann bereits möglich sein, die Multiroom-Fähigkeiten von Snapcast mit Hilfe des Android-Clients von Snapcast zu testen und so auch festzustellen, dass die restliche Konfiguration von Snapcast und Pulseaudio korrekt sind.

=== FHEM ===

In FHEM sind nun in der ''fhem.cfg'' die entsprechenden Module einzurichten:
* Ein Snapcast-Modul im Server Modus
* Pro Raum ein Snapcast-Modul im Clientmodus
* Pro Raum ein MPD-Modul
* Pro Raum ein OpenMultiroom-Modul
* Optional pro Raum ein Text2Speech-Modul
* weitere Text2Speech-Module, falls man diese in Pulseaudio mit dem per Combine-Sink vorgesehen hat.

<source lang="bash">
define scs.snap Snapcast

define scc.kind1 Snapcast client scs.snap b827eb9aec84
attr scc.kind1 constraintDummy freestring
attr scc.kind1 constraints standard|07:00 0 20:00 100 21:00 50 21:30 30 24:00 0,beforefree|07:00 0 21:00 100 22:00 50 23:00 30 24:00 0,beforeschool|07:00 0 08:30 50 20:00 100 21:00 50 21:30 30 24:00 0,free|07:00 0 08:30 50 21:00 100 22:00 50 23:00 30 24:00 0

define scc.kind2 Snapcast client scs.snap 025009413c29
attr scc.kind2 constraintDummy freestring
attr scc.kind2 constraints standard|07:00 0 20:15 100 20:30 50 24:00 0,beforefree|07:00 0 21:00 100 22:30 50 24:00 0,beforeschool|07:00 0 08:30 50 20:15 100 20:30 50 24:00 0,free|07:00 0 08:30 50 21:00 100 22:30 50 24:00 0

define scc.kueche Snapcast client scs.snap b827eb9a2ad3

define scc.wohn Snapcast client scs.snap 00aefa4aa3a9
</source>

Oben zu sehen ist das define für das Server-Modul. Ohne Parameter verbindet sich mit localhost auf dem Standardport 1705. Es folgt die Definition von 2 Clients. Der erste Parameter "client" versetzt das Snapcastmodul in den Clientmodus. Der zweite Parameter verweist auf das Servermodul, der dritte Parameter ist die Client-ID. Diese besteht bei der aktuellen Snapcast-Version meistens aus der MAC-Adresse des Clients. Für die Kinder werden noch die Attribute constraintDummy ond constraints vergeben. Hiermit wird eine tagestyp- und tageszeitabhängige Lautstärkebegrenzung konfiguriert. Für die vier Tagestypen "standard", "beforefree", "beforeschool" und "free" wird ein jeweils anderes Lautstärkezeitprofil definiert.

Das Zeitprofil wird hier nach dem gleichen Muster wie die Temperaturlisten der Homematic-Thermostate, erklärt hier: [HomeMatic_Type_Thermostat]. Für den Tagestyp wird zusätzlich das Attribut constraintDummy verwendet. Es definiert, dass in dem Dummy "freestring" jeweils drin steht, welcher Tagestyp gerade ist. Diese Variable wirkt somit als Selektor auf die Liste der erlaubten Maximallautstärken. Wie eine solche Dummyvariable jeweils mit einem entsprechenden Wert befüllt werden kann, z.B. abhängig vom Wochentag, von Schulferien oder Feiertagen, wird hier nicht erläutert. Es ist auch möglich, nur ein Lautstärkeprofil anzugeben. Ohne dass ein Attribut constraintDummy gesetzt ist, verwendet das Snapcastmodul immer den Wert "standard". Wie man hier sehen kann, gibt es im Beispiel 4 Typen, hierbei fallen Freitage normalerweise in die Kategorie "beforefree" (es sind Tage, bevor dann frei ist, es kann also typischerweise länger und lauter Musik gehört werden), Samstage normalerweise in die Kategorie "free" und Sonntage in die Kategorie "beforeschool", ebenso landen dort Feiertage vor Schultagen usw.

<source lang="bash">
define tts.wohn Text2Speech pulsewohn
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.wohn TTS_UseMP3Wrap true

define tts.nele Text2Speech pulsenele
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.nele TTS_UseMP3Wrap true

define tts.merle Text2Speech pulsemerle
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.merle TTS_UseMP3Wrap true

define tts.kueche Text2Speech pulsekueche
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.kueche TTS_UseMP3Wrap true

define tts.kinder Text2Speech pulsekinder
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.kinder TTS_UseMP3Wrap true

define tts.unten Text2Speech pulseunten
attr tts.wohn TTS_FileTemplateDir /data/misc/announcements/
attr tts.unten TTS_UseMP3Wrap true

define tts.alle Text2Speech pulsealle
attr tts.alle TTS_FileTemplateDir /data/misc/announcements/
attr tts.alle TTS_UseMP3Wrap true
</source>
Hier sind die Definitionen der Text2Speech Module zu sehen (optional). Sie werden jeweils mit den in Pulseaudio definierten Sinks verbunden. Die Nutzung eines TemplateDirs ist ebenfalls optional, hier können bereits fertige MP3s verwendet werden, die dann anstelle der von der Google TTS API erzeugten Dateien benutzt werden. Dies können auch Bestätigungs und Fehlertöne sein, die bei Benutzern ohne Display, die rein mit Fernbedienung arbeiten, auf Fehlbedienungen etc. aufmerksam zu machen.

<source lang="bash">
define mpd.nele MPD 192.168.2.2 6600
attr mpd.nele player mopidy
attr mpd.nele bookmarkDir mpdstates
attr mpd.nele autoBookmark 1

define mpd.merle MPD 192.168.2.2 6702
attr mpd.merle player mopidy
attr mpd.merle bookmarkDir mpdstates
attr mpd.merle autoBookmark 1

define mpd.kueche MPD 192.168.2.2 6703
attr mpd.kueche player mopidy
attr mpd.kueche bookmarkDir mpdstates
attr mpd.kueche autoBookmark 1

define mpd.wohn MPD 192.168.2.2 6704
attr mpd.wohn player mopidy
attr mpd.wohn bookmarkDir mpdstates
attr mpd.wohn autoBookmark 1
</source>
Pro laufender MPD oder Mopidy-Instanz wird ein MPD-Modul eingerichtet. Der Hostname und die Ports sind entsprechend anzupassen. Durch die bookmarkDir und autoBookmark - Attribute wird erreicht, dass der Zustand von Playlisten beim Wechsel derselben gespeichert und später wiederhergestellt werden kann. So lässt sich das Hören eines Hörbuchs unterbrechen, auf z.B. eine Radiostreamplayliste schalten, um dann später zur gleichen Stelle im Hörbuch zurückzukehren.

<source lang="bash">
define mac.nele MultiroomAudioController
attr mac.nele mr scc.nele
attr mac.nele soundMapping nele:mpd.nele,merle:mpd.merle,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.nele playlistPattern nele
attr mac.nele ttsMapping nele:tts.nele,merle:tts.merle,kueche:tts.kueche,wohn:tts.wohn
attr mac.nele defaultTts tts.nele
attr mac.nele defaultStream nele
attr mac.nele defaultSound mpd.nele

define mac.merle MultiroomAudioController
attr mac.merle mr scc.merle
attr mac.merle soundMapping nele:mpd.nele,merle:mpd.merle,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.merle playlistPattern merle
attr mac.merle ttsMapping nele:tts.nele,merle:tts.merle,kueche:tts.kueche,wohn:tts.wohn
attr mac.merle defaultTts tts.merle
attr mac.merle defaultStream merle
attr mac.merle defaultSound mpd.merle

define mac.kueche MultiroomAudioController
attr mac.kueche mr scc.kueche
attr mac.kueche soundMapping nele:mpd.nele,merle:mpd.merle,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.kueche playlistPattern wohn
attr mac.kueche ttsMapping nele:tts.nele,merle:tts.merle,kueche:tts.kueche,wohn:tts.wohn
attr mac.kueche defaultTts tts.kueche
attr mac.kueche defaultStream kueche
attr mac.kueche defaultSound mpd.kueche

define mac.wohn MultiroomAudioController
attr mac.wohn mr scc.wohn
attr mac.wohn soundMapping nele:mpd.nele,merle:mpd.merle,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.wohn playlistPattern wohn
attr mac.wohn ttsMapping nele:tts.nele,merle:tts.merle,kueche:tts.kueche,wohn:tts.wohn
attr mac.wohn defaultTts tts.wohn
attr mac.wohn defaultStream wohn
attr mac.wohn defaultSound mpd.wohn
</source>
Die Konfiguration der OpenMultiroom-Module schließt die Einrichtung von FHEM ab. Jede Instanz benötigt mindestens das "mr"- und das "soundMapping"-Attribut. Nur so kann sich das Modul mit den entsprechenden Snapcast und MPD-Modulen verbinden. Durch das "mr"-Attribut wird ein OpenMultiroom-Modul einem Snapcast-Client-Modul fest zugeordnet. Das Soundmapping ordnet die in Snapcast definierten Streams (siehe oben, Konfiguration vom Snapserver) den entsprechenden Instanzen des MPD-Moduls zu. Dadurch weiß FHEM, welcher MPD auf welchem Stream abspielt und kann je nachdem, welchem Stream ein Raum gerade zuhört, den dazu passenden MPD steuern und seine Readings durchreichen. Das OpenMultiroom-Modul bildet alle Readings des MPD-Moduls nochmal direkt ab. Wechselt ein Benutzer aber den Stream, dem er zuhört, aktualisieren sich auch alle Readings dementsprechend mit denen des dann aktuellen MPD-Moduls.

Das Attribut playlistPattern ist optional und sorgt dafür, dass beim Durchschalten der Playlists mit den Kommandos "channelUp" und "channelDown" nur diejenigen Playlists berücksichtigt werden, die auf das Pattern passen.

Analog zum soundMapping definiert das Attribut ttsMapping die Zuordnung der TTS-Module zu den Streams. Beim Ausgeben von Announcement kann so das OpenMultiroom-Modul ermitteln, auf welchem Stream welcher Raum gerade zuhört, und wo dementsprechend die TTS-Ausgaben zu erzeugen sind, damit sie auch in den gewünschten Räumen ankommen. Dieser Umweg ist zurzeit nötig, da ein Snapcast-Client nur auf einem einzigen Stream lauschen kann. Lauschen noch andere Clients auf demselben Stream, hören sie allerdings zwangsweise auch die Announcements.

Die 3 Default-Attribute legen fest, welche der TTS-Module, welcher Stream und welcher MPD dem entsprechenden Modul fest zugeordnet sind. Dies wird u.a. von einer Resetfunktion im Modul verwendet.

== Bedienung des OpenMultiroom-Moduls ==

=== set-Kommandos ===

=== Readings ===

=== Attribute ===

== Anbindung einer Fernbedienung an ein OpenMultiroom-Modul ==

=== Konfiguration von LIRC und IRExec ===

=== Zuordnung der Tasten: Beispiel ===

[[Category:Examples]]
[[Category:HOWTOS]]
[[Category:Unterhaltungselektronik]]

OpenMultiroom

2017-01-25T16:22:38Z

Unimatrix27: Snapcast und Mopdy hinzugefügt

OpenMultiroom

2017-01-25T14:10:41Z

Unimatrix27: /* Aufbau anhand einer vollständigen Beispielkonfiguration */

OpenMultiroom

2017-01-25T13:02:03Z

Unimatrix27: Weiterentwicklung des Artikels

Datei:OpenMultiroomOverview.png

2017-01-24T06:21:31Z

Unimatrix27: Unimatrix27 lud eine neue Version von Datei:OpenMultiroomOverview.png hoch

Überblick des Zusammenspiels der Komponenten beim OpenMultiroom System, hier mit den Backends MPD und Snapcast

OpenMultiroom

2017-01-23T21:10:27Z

Unimatrix27:

OpenMultiroom

2017-01-23T21:09:22Z

Unimatrix27: Erstversion

Datei:OpenMultiroomOverview.png

2017-01-23T20:33:33Z

Unimatrix27: Überblick des Zusammenspiels der Komponenten beim OpenMultiroom System, hier mit den Backends MPD und Snapcast

Überblick des Zusammenspiels der Komponenten beim OpenMultiroom System, hier mit den Backends MPD und Snapcast

HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi

2016-12-13T18:07:24Z

Unimatrix27: Alternative Möglichkeit zum Flashen hinzugefügt

{{Infobox Hardware
|Bild=HM-MOD-RPI-PCB.jpg
|Bildbeschreibung=HomeMatic Funkmodul für Raspberry Pi
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=1,8–3,6 V DC
|HWPowerConsumption=50 mA max.
|HWPoweredBy=RasPi
|HWSize=19x41x14mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] ist eine Zusatzplatine, die auf die GPIO-Schnittstelle des [[Raspberry Pi]] aufgesteckt werden und damit als [[Interface]] zu [[HomeMatic]] Geräten dienen kann.

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das "neue" [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|Funk-LAN Gateway HM-LGW-O-TW-W-EU]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Vorbereitung serielle Schnittstelle unter Jessie===
Diese Beschreibung gilt für Jessie Version 27.05.2016.
Die Grundlagen findet man hier: [[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]

Die Datei /boot/config.txt um diese Zeile ergänzen

<pre>enable_uart=1</pre>

Beim PI 3 zusätzlich diese Zeilen ergänzen

<pre>dtoverlay=pi3-miniuart-bt
core_freq=250</pre>

In der Datei /boot/cmdline.txt diesen Eintrag löschen:
<pre>console=serial0,115200 </pre>

Den Dienst serial-getty deaktivieren

<pre>systemctl disable serial-getty@ttyAMA0.service</pre>

Bei PI 3 den hciuart Service modifizieren: In der Datei /lib/systemd/system/hciuart.service zweimal ttyAMA0 gegen ttyS0 austauschen.

<pre>sed -i s/ttyAMA0/ttyS0/ /lib/systemd/system/hciuart.service</pre>

Der Benutzer fhem muss Mitglied in der Gruppe dialout sein!
Beim PI 3 kann man wegen Timingproblemen den Start von FHEM etwas verzögern. Dazu die /etc/init.d/fhem um sleep 10 am Anfang ergänzen.

Das System unbedingt neu starten!

=== Vorbereitung serielle Schnittstelle unter Wheezy===
Diese Beschreibung gilt für Wheezy Version Stand 26.07.2016.

Die Datei /boot/config.txt um diese Zeile ergänzen

<pre>enable_uart=1</pre>

In der Datei /boot/cmdline.txt diesen Eintrag löschen:

<pre>console=ttyAMA0,115200</pre>

Die Datei sollte dann den folgenden Inhalt aufweisen:

<pre>dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait</pre>

Den Dienst serial-getty deaktivieren

in der Datei /etc/inittab wie folgt die Zeile (ziemlich am Ende) mit einer # auskommentieren

<pre># T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100</pre>
Mit folgendem Befehlen überprüfen, dass kein getty auf der Schnittstelle läuft
<pre>ps -A |grep getty
cat /etc/inittab</pre>
{{Randnotiz|RNText=Tipp: Sollte der HM-MOD-RPI-PCB nach der Einrichtung immer wieder den Status zwischen init und disconnect wechseln, alle aufgeführten Punkte erneut kontrollieren! reboot nicht vergessen! In ganz hartnäckigen Fällen von der Stromversorgung trennen!}}

Der Benutzer fhem muss Mitglied in der Gruppe dialout sein! Bitte prüfen:
<pre>groups fhem</pre>

'''Das System unbedingt neu starten!'''

=== Kontrolle ===
Berechtigungen der Schnittstelle kontrollieren
<pre>ls -l /dev/ttyAMA0</pre> liefert die Ausgabe unter Jessie
<pre>crw-rw---- 1 root dialout 204, 64 Jul 27 23:39 /dev/ttyAMA0</pre>
bzw. unter wheezy
<pre>crw-rw---T 1 root dialout 204, 64 Aug 9 18:07 /dev/ttyAMA0</pre>

=== Definition in FHEM===
<pre>define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx</pre>

=== Verwendung AES in FHEM===
Das Modul beherrscht AES.
Für weitere Informationen gibt es einen separaten Wiki Eintrag [[AES Encryption]]

=== Logbeispiel ===
Typischerweise meldet sich das Modul beim Start so:
2016.10.06 17:11:16 3: Opening myHmUART device /dev/ttyAMA0
2016.10.06 17:11:16 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.10.06 17:11:16 3: myHmUART device opened
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_BL
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_App

=== Firmware Update HM-MOD-RPI-PCB ===

1. Firmware herunterladen
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3
2. Flashen der neuen Firmware aus Fhem
fhem> set myHmUART updateCoPro /path/to/coprocessor_update.eq3

=== Alternative Methode zum Firmware Update ohne FHEM ===

Sollte das Update über FHEM nicht funktionieren oder FHEM nicht verfügbar sein, kann die Firmware auch wie folgt eingespielt werden (Quelle: [http://heinz-otto.blogspot.com/2016/07/raspberry-pi-homematic-modul.html Ottos Technik Blog])

sudo su
apt-get update && apt-get -y install libusb-1.0-0-dev build-essential git
systemctl stop fhem
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb/
make
# Firmware runterladen
wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3
# eigentliches flashen:
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3

== Remoteanbindung - Pi + RPI Modul = LAN Modul ==
''Noch in Bearbeitung''

Es ist nicht dazu gedacht zwei FHEM Instanzen zu koppeln, sondern das RPI Modul über socat auf dem entfernten Raspi verfügbar zu machen.
auf dem Pi wo das Modul angeschlossen ist:
Kein FHEM Zugriff!
Kein define HmUART_EG HMUARTLGW /dev/ttyAMA0
Kein define RM_HmUART_EG HMUARTLGW uart://192.168.17.185:2000

Installation auf Remote Instanz

sudo apt-get install socat

Auf diesem Pi, also wo das Modul steckt:

sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

In welcher Datei lege ich diesen Befehl am besten ab damit dieser bei einem Neustart ausgeführt wird.
Würde die rc.local ohne sudo dafür verwenden.

Auf dem Modul wo FHEM läuft und das Modul Remote angeschlossen werden soll:

define RM_HmUART_EG HMUARTLGW uart://192.168.17.185:2000

Es handelt sich nicht um sharing der seriellen Schnittstelle und damit "verfügbar machen" des Moduls all over the World!
Es handelt sich um ein exklusives "Kabel" von Pi zu Pi zur Schnittstelle zum RPI Modul.

PI1: FHEM -> uart://IP:Port -> Netzwerk ->
Remote PI2: Netzwerk -> socat listener -> socat serial -> RPI Modul auf PI2

RPI Modul auf PI2 -> serial -> socat -> Netzwerk -> uart://IP:Port -> FHEM auf PI1

== Bekannte Probleme ==
Sollten beim Flashen der Firmware hartnäckige Probleme auftreten (kein Erfolg aber auch gar keine Fehlermeldungen) ist das Modul vom Strom zu trennen, ein Neustart des Pi reicht nicht!

Ein {{Link2Forum|Topic=41203|Message=340320|LinkText=Beitrag}} aus dem genannten Forenthread: ''Das Ding ist anscheinend wirklich einfach das Funkmodul aus der CCU2 (wird zumindest in der eQ-3 SW als CCU2 angesprochen) und spricht ein für Fhem vollkommen neues Protokoll.''

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]
[[Kategorie:Raspberry Pi]]