Ms4h 2.0

**tokylo** · In den letzten 2 Wochen

Ich habe heute das TTS von Loxone MS4H auf Home Assistant umgestellt.
Leider gab VoiceRSS keine Sprachausgabe mehr an die Lautsprecher weiter. Nach langem Suchen und Testen habe ich die Fehlersuche aufgegeben und das Ganze neu aufgebaut über Loxone → MQTT → Home Assistant → MS4H Lyrion (LMS).

Dank ChatGPT konnte ich die benötigten Automationen erstellen und es funktioniert soweit.
Das Audiosignal vor der TTS Ausgabe wird manchmal nicht korrekt abgespielt, das nehme ich fürs Erste in Kauf.

Loxone nutze ich für die Automation,
Home Assistant für Integrationen, Visualisierung und Statistiken.
Den LMS steuere ich über MS4H aus Loxone und auch aus HomeAssistant. Ich hoffe, dass es weiterhin die gute Schnittstelle MS4H nach Loxone gibt.

Ich habe auch überlegt, den Loxone Audioserver zu kaufen, aber der ist mir zu wenig offen und flexibel für meine Anforderungen.

Prof.Mobilux : Dein Hinweis zu Volumio fand ich spannend.
Nach einer kurzen Recherche mit ChatGPT zeigt sich aber, dass Volumio deutliche Schwächen bei TTS haben soll und das ist mir besonders wichtig.

Antwort von ChatGPT:

🔊 1. LMS (Logitech Media Server) – Top für Multiroom & Flexibilität

Pro: Sehr stabil, lokal, geringe Latenz, ideal für TTS (z. B. deine Automation), Multiroom-fähig mit Squeezelite-Clients.
Con: Etwas altmodisch wirkendes Webinterface, Spotify/Tidal nur mit Plugins.
Integration: Sehr gute Home Assistant Integration über Squeezebox.
Tipp: Kombiniert mit Music Assistant oder direkter tts-Steuerung (wie du es bereits machst), perfekt.

🎶 2. Volumio (Open Source oder Premium Lyrion) – Gut für Einsteiger & Klangfans

Pro: Schönes Webinterface, Webradio, Spotify, Plugins, lokale Musik, Touchscreenfähig, gute Hardwareunterstützung (z. B. Raspberry Pi).
Con: Home Assistant Integration mittelmäßig (via mpd oder upnp), TTS oft problematisch.
Integration: Via MPD oder UPnP, teils unzuverlässig.
Tipp: Gut als Standalone-Player, weniger ideal für komplexe Automationen oder TTS.

🧠 3. Music Assistant (Add-on für HA) – Für zentrale Musiksteuerung

Pro: Lokale Bibliothek, Spotify, Tidal, YT Music (mit PO Token Generator), AirPlay/Chromecast, gute HA-Integration, zentrale Steuerung.
Con: Noch im Aufbau, einige Funktionen instabil (z. B. TTS, Streamwiederherstellung).
Tipp: Ideal für einheitliche Steuerung mehrerer Quellen, v. a. mit Hardware wie LMS oder Snapcast.

📡 4. Snapcast (mit Mopidy oder mpd) – Für synchrones Multiroom

Pro: Perfekte Lippensynchronität im ganzen Haus, geringer Ressourcenverbrauch.
Con: Einrichtung komplexer, TTS nicht von Haus aus.
Tipp: Super für große Multiroom-Systeme, wenn Musik und TTS exakt synchron sein sollen.

🧩 5. Mopidy (mit Iris, Spotify etc.) – Modular und anpassbar

Pro: Sehr flexibel, unterstützt Spotify, Webradio, lokale Musik, Erweiterungen.
Con: Weniger komfortabel zu bedienen, keine native TTS-Funktion.
Tipp: Für Bastler und Linux-Nutzer mit Wunsch nach kompletter Kontrolle.

🔍 Empfehlung für dich (basierend auf deinem Setup):
👉 Bleib bei Logitech Media Server (LMS)
Und ergänze ggf.:

Music Assistant als zentrales Frontend (für einfachere Musiksteuerung).
Squeezelite Clients auf Raspberry Pi, DietPi, oder anderen Geräten.
Snapcast (falls du perfekte Latenz brauchst).

-------------------------------------------------------

❌ Warum TTS in Volumio problematisch ist:

1. Keine native TTS-Unterstützung

Volumio wurde für Musikwiedergabe, nicht für automatisierte Durchsagen entwickelt.
Es gibt keinen eingebauten TTS-Mechanismus.
Du müsstest TTS-Files manuell generieren und abspielen – aber das klappt nicht zuverlässig im laufenden Betrieb.

2. Kein "Announce-Modus"

Volumio unterbricht nicht sauber die laufende Wiedergabe für eine TTS-Durchsage.
Es fehlt die Logik für:
- Pause
- Wiedergabe der mp3 (TTS)
- Wiederaufnahme der ursprünglichen Quelle
Auch mpg123, aplay oder mplayer auf der Shell können das nicht richtig in Volumio-Umgebung triggern (wegen player locks).

3. Kein Status-Feedback an Home Assistant

Volumio hat zwar eine Websocket API, aber nicht alle Playerzustände sind verlässlich abrufbar.
Für Wiederherstellung nach TTS ist das problematisch.

4. Volumio blockiert manchmal während Audio-Wechseln

Bei Playbacks von kurzer MP3 (z. B. TTS-Datei) kann es passieren, dass Volumio:
- hängt
- das File nicht abspielt
- oder danach im falschen Zustand bleibt (z. B. idle, aber kein Ton)

**hismastersvoice** · In den letzten 2 Wochen

...und da sieht man wie wenig Ahnung ChatGPT bei dem Thema hat.

Snapcast wurde von mir schon getestet und sieht mehr als vielversprechend aus.

Native unterstützt von TTS ist in keinem Projekt sauber gegeben. Es gibt inzwischen aber sogar gute offline Engines.

Monatliche Kosten sind ein No-Go für so ein Projekt.

**mackerel** · In den letzten 2 Wochen

Ich hoffe, das Projekt lebt weiter und bekommt vielleicht wirklich mit mehr Unterstützung neuen Schwung.
Es stimmt natürlich, dass immer mehr auf Wireless gesetzt wird. Ich persönlich habe allerdings gerade erst in einem Neubau mit Loxone 24 Lautsprecher / 12 Zonen verteilt und habe mich sehr gefreut dieses Projekt zu finden! Ich finde es super bei der Gelegenheit die Kabel gezogen zu haben und nun alles von einer Stellt aus unabhängig von Loxone Hardware befeuern zu können.

Die Zahlen mögen nicht mehr stark wachsen, aber ich denke das Projekt hat für viele User wie mich einen großen Wert.
Danke für die tolle Arbeit hismastersvoice und hoffentlich besteht du die Motivation es auch weiter zu betreuen.

Ich selbst wäre auch gerne bereit zu helfen. Habe Erfahrung als Softwareentwickler, allerdings wenig Plan vom Audio Teil.

Viele Grüße
Christoph

**Gagi** · In den letzten 2 Wochen

Ich bin von meiner Seite gerne auch bei einem Neustart dabei, wieviel Zeit ich dafuer allerdings investieren kann muss man mal sehen.

MSG wurde damals ja von jemand anderem gestartet, ich hab es damals nur uebernommen und fuer den LMS aufgebohrt. Ich hab damals allerdings schon versucht so unabhaengig wie moeglich zu bleiben. Die Kommunikation zwischen Loxone und dem LMS sind getrennt. Man koennte also eine alternative zu LMS anbinden ohne die bestende kaputt zu machen, das wuerde uns ermoeglichen den bestehenden LMS erstmal weiter laufen zu lassen bis das neue system soweit ist.

Bzgl. Audioserver Anbindung. Die Integration an sich ist in weiten Teilen fertig. Die Entwicklung ist leider etwas eingeschlafen da ich auch nicht so viel Zeit mehr hatte, das meiste sollte aber weiterhin noch funktionieren. Problematisch bleibt allerdings die Kommunikation zwischen MSG und Loxone, wenn Loxone moechte kann sie den Hahn recht schnell abdrehen, so aehnlich wie beim Weather Service Emulator.

hismastersvoice Was wuerde denn aktuell Fehlen um die Audioserver-Unterstuetzung zu aktivieren ? Ich frage mich ob es nicht sinnvoll ist ein letztes Release mit Audioserver zu machen und dafuer dann nur noch kleiner Bugfixes anzubieten. Alle neuen Features sollen dann im neuen Projekt entwickelt werden.

Bzgl. LMS als Basis. Ich hatte durchaus auch sehr viele Probleme bei der Anbindung, allerdings sind viele Dinge fuer mich auch nur Spielerei, die ich im Gateway anbieten kann, die ich aber selber nie nutzen wuerde. Im grossen und ganzen laeuft der LMS bei mir ziemlich stabil.

**hismastersvoice** · In den letzten 2 Wochen

Zitat von Gagi

hismastersvoice Was wuerde denn aktuell Fehlen um die Audioserver-Unterstuetzung zu aktivieren ? Ich frage mich ob es nicht sinnvoll ist ein letztes Release mit Audioserver zu machen und dafuer dann nur noch kleiner Bugfixes anzubieten. Alle neuen Features sollen dann im neuen Projekt entwickelt werden.

Gagi
Es waren nur noch ein paar kleine Dinge, wie Line-In File und Alram, aber nichts großes mehr.

Heute kam eine neue Alpha der App raus, in der wird ein neues UI für den AudioServer mitgeliefert.

Es geht erst mal nichts mehr... Auch beim org. AudioServer.
Bin mal gespannt ob sie eine neue API oder nur nur "neue" Bugs eingebaut haben

Was aber noch ein Thema sein könnte der LX-Commander wurde archiviert und über kurz oder lang wird das sicher was nicht mehr gehen.
Schau dir mal was hier auf Git gemacht wurde.
Hier scheint auch jemand schon eine AudioServer Schnittstelle gebaut zu haben die mit unterschiedlichen Backends arbeitet.

GitHub - rudyberends/loxone-custom-audioserver: NodeJS Implementation of the Loxone Audio Server.

https://github.com/rudyberends/loxone-custom-audioserver

NodeJS Implementation of the Loxone Audio Server. Contribute to rudyberends/loxone-custom-audioserver development by creating an account on GitHub.

hme0354 hat es auch schon getestet und der Bildschirm bleiber bei iOS/Android und Windows ohne Werte und Grafiken.

Für mich sieht es so aus, als wurde die API überarbietet.
In vielen Sektionen kommt noch "not implemented yet", was darauf hinweist das es nicht auf der alten API aufsetzt.

**Prof.Mobilux** · In den letzten 2 Wochen

Zitat von hismastersvoice

Was aber noch ein Thema sein könnte der LX-Commander wurde archiviert und über kurz oder lang wird das sicher was nicht mehr gehen.

Aber nur weil Loxone das Paket nicht mehr mit den neueren Änderungen versorgt. Die API ist weiterhin gut dokumentiert: https://www.loxone.com/wp-content/up...Miniserver.pdf

Da die Loxone-Bindungs von HASS, ioBroker, HomeBridge alle auf den LXCommunicator setzen, bin ich mir ziemlich sicher, dass es da bei Änderungen kurzfristig eine Lösung gibt. Die Entwicklergemeinde ist da deutlich größer als hier bei uns.

Schau dir mal was hier auf Git gemacht wurde.
Hier scheint auch jemand schon eine AudioServer Schnittstelle gebaut zu haben die mit unterschiedlichen Backends arbeitet.

GitHub - rudyberends/loxone-custom-audioserver: NodeJS Implementation of the Loxone Audio Server.

https://github.com/rudyberends/loxone-custom-audioserver

NodeJS Implementation of the Loxone Audio Server. Contribute to rudyberends/loxone-custom-audioserver development by creating an account on GitHub.

Von Rudy Berends ist das Loxone Homebridge Binding - das ist ja witzig ;-) Im einzigsten Issue auf GitHub hat er beschrieben, wie der Custom AudioServer funktioniert. Es scheint aber, dass es für jedes System ein Backend entwickelt werden muss (es gibt wohl aktuell nur BeoLink). Das wäre sein Beispiel für ein Backend:

loxone-custom-audioserver/src/backend/Example/backend.ts at main · rudyberends/loxone-custom-audioserver

https://github.com/rudyberends/loxone-custom-audioserver/blob/main/src/backend/Example/backend.ts

NodeJS Implementation of the Loxone Audio Server. Contribute to rudyberends/loxone-custom-audioserver development by creating an account on GitHub.

Let's try if we can get it running in your setups.

In Loxone config, you can add an audioserver. This will have two (stereo) outputs, but you can split them, by right clicking on the output and selecting "split", which will give you 4 (mono) outputs. As we use a custom setup, this will still be stereo (or whatever your source is), but will give you 4 zones. Drag these outputs to your Loxone config. This will automatically attach a player block to the output.

If you look at the player block for each output, you will see it has a Player-ID assigned to it. This is a random number and you need this to map this to your source. After you have added this to your Loxone configuration, you need to safe and restart the Loxone server. At this point the audioserver will show "not fully configured" in Loxone Config.

Then you need to be able to run the code. You can either download it from here and start it with Node, or run it in a docker container. A precompiled docker image is available here.

You then need to use an .env file to configure the zones. If you run the code locally, you can just create the ENV file in the root. For the docker container you need to map it, or inject the entries as ENV variables.

You can use the .env.example and change it to your needs. You need to configure the miniserver ip, username and password to connect to the miniserver. The audioserver_ip needs to be the ip of the device you are running this code on.

Then add your zones and use the player-ID from the player blocks. In my example the player-ids are 14,15,16,20. You also need to map the zones to a backend. Every zone can have its own backend. And you need to specify the ip of the zone.

Only the beolink backend is functional. backendExample and backendSonos will give you some dummy data, but this will give you an idea.

If everything is working correctly, the audioserver should pair with the miniserver and turn green in Loxone config.

Let me know if you can get it running. Please let me know if you need any further information.

Sieht für mich so aus, als ob die Lösung durchaus brauchbar ist und eventuell mit ein wenig "Fleißarbeit" an den LMS angepasst werden kann. Ich hatte auf jeden Fall bzgl. Homebridge mehrmals Kontakt mit Ruby und er ist wirklich sehr hilfsbereit!

**Gagi** · In den letzten 2 Wochen

Der code ist definitiv sauberer geschrieben und aufgeteilt als meiner. Wahrscheinlich hat er auch Ahnung von NodeJS, was ich nicht gerade behaupten kann...

An vielen Stellen schaut der Code aber sehr aehnlich zu meinem aus. Vorallem die Antwort der verschluesselten Kommandos ist 100% das gleiche:

loxone-custom-audioserver/src/http/handlers/secureCommands.ts at main · rudyberends/loxone-custom-audioserver

https://github.com/rudyberends/loxone-custom-audioserver/blob/main/src/http/handlers/secureCommands.ts#L29

NodeJS Implementation of the Loxone Audio Server. Contribute to rudyberends/loxone-custom-audioserver development by creating an account on GitHub.

loxberry-music-server-gateway/bin/service/music-server/index.js at audioserver · Gagi2k/loxberry-music-server-gateway

https://github.com/Gagi2k/loxberry-music-server-gateway/blob/audioserver/bin/service/music-server/index.js#L3333

Contribute to Gagi2k/loxberry-music-server-gateway development by creating an account on GitHub.

Genau das ist aber auch die Stelle die ich meinte, Loxone kann da sehr schnell die API fuer uns abdrehen.

Den LXCommunicator seh ich unkritisch. Ja evtl. fehlen uns in Zukunft ein paar neue Commands, aber fuer alles was wir im Moment benutzen wird er auch weiterhin funktionieren, solange Loxone nichts an der API aendert, was ich nicht glaube.
Zusaetzlich ist das auch der Teil, der am ehesten komplett rausgeschmissen werden kann. Den verwenden wir nur um das komplizierte Spotify User handling zu machen, wobei das jetzt mittlerweile auch ohne ganz gut gehsen sollte und um die mac Adresse des miniservers abzufragen und das pairing zu machen, wir koennten die mac genauso gut auch wieder in die config Datei schreiben.

Ja das mit der neuen API ist interessant, das wuerde alles wieder aendern.

**Prof.Mobilux** · 2025-08-09T07:24:09+02:00

Ich krame das Thema noch einmal raus. Wenn man über einen Neustart des Projekts nachdenkt, stellt sich mir immer noch die Frage welche Alternative es zum LMS gibt.

Volumio: Fällt aus weil kein Multiroom in der kostenlosen Variante. Es gab ein Plugin für Snapcast, das ist aber veraltet.
Jellyfin: Nicht die klassische Server/Client Aufteilung bzw. nur eingeschränkt. Multiroom aus meiner Sicht nicht so umgesetzt wie wir es brauchen. Sync-Qualität unbekannt.
Snapcast: Scheint perfekten Multiroom/Sync laut vielen Berichten zu können (und hismastersvoice hat es ja auch schon geschrieben), er bringt aber keine eigene Medienverwaltung mit (wenn ich es richtig verstanden habe)

Mehr "vielversprechendes" habe ich bei meiner Recherche ehrlich gesagt nicht gefunden. Entweder sind Projekte verwaist, sie bringen nicht alle Funktionen mit die wir bräuchten oder sind closed source bzw. mit kostenpflichtiger Pro-Version. Einiges lief nur auf Raspberry/ARM, was uns auch nichts bringt.

Man findet einige Beiträge von Usern, die sich aus z. B. JellyFin oder Volumio in Kombination mit Music Player Daemon (MTD) und/oder Snapcast entwas "zusammengebaut" haben. Ich bin mir aber nicht sicher, ob man das so flexibel hinbekommt wie wir es brauchen (z. B. "live" Gruppen bilden).

Any ideas?

**Prof.Mobilux** · 2025-08-09T09:41:02+02:00

Nimmt man mal Snapcast als Server/Client als fix an. Das scheint mir (ich hab keine Ahnung von dem Audio-Teil) sehr flexibel zu sein, weil es als Quelle alle möglichen Optionen bietet (Fifo, File, AirPlay).

Bleibt die Auswahl einer Medienverwaltung, die mit Snapcast zusammen arbeitet. Danach habe ich jetzt nochmal explizit gesucht und aus meiner Sicht folgende vielversprechende zwei Projekte gefunden:

Music Player Daemon (MPD): https://mpd.readthedocs.io/en/stable/index.html

Scheint unheimlich mächtig und sehr gut gepflegt. Verwaltet eine Mediensammlung. Es gibt zahlreiche Clients für alles mögliche (Desktop, Web, iOS, Android, Console, ....). Ausgabe an Snapcast geht per Fifo oder sogar eigenem Snapcast-Plugin: snapcast - Snapcast is a multiroom client-server audio player. This plugin allows MPD to act as a Snapcast server. Snapcast clients connect to it and receive audio data from MPD.

Gefällt mir sehr gut, weil mächtige Entwicklergemeinde.

Owntone: https://owntone.github.io/owntone-server/

Bin ich gerade durch Zufall drauf gestoßen. Wird aktiv entwickelt und ist eine Medienverwaltung mit unterschiedlichsten Clients. Kann als Multiroom zu AirPlay und Chromecast Devices streamen (ich glaube das kann Snapcast nicht?), was ich für viele (z. B. Sonos-Nutzer) recht interessant finde. Unterstützt Spotify direkt, was ich so beim MPD nicht gefunden habe. Arbeitet mit Snapcast (über Fifo) zusammen.

Mopidy: https://mopidy.com/

Medienverwaltung, Sporfy, TuneIn. Wird aktiv entwickelt. Kann Musik an Snapcast und MPD weitergeben.

Music Assistent: https://www.music-assistant.io/

Lösung für Homeassistent, läuft aber auch Standalone (nur im Docker?). Arbeitet mit Snapcast zusammen. Als Quelle ebenfalls zahlreiche Streaming Dienste, lokale Sammlungen etc. verfügbar - aus meiner Sicht alles was das Herz begehrt, inkl. Youtube Music und Spotify: https://www.music-assistant.io/music-providers/ Als Clients ist ebenfalls alles mögliche dabei: Snapcast, squeezelite, Airplay, GoogleCast, DLNA, Sonos.... https://www.music-assistant.io/player-support/

Wenn ich mir das so anschaue, finde ich Music Assistent sehr interessant...

**Prof.Mobilux** · 2025-08-10T10:08:03+02:00

Mich lässt das Thema nicht ganz los, weil ich durchaus noch Bedarf an einem MusicServer habe

Ich habe also gestern auf Basis meines obigen Posts mir die Lösungen noch einmal angeschaut und eine Art Konzept gemacht, wie man ein Gemeinschaftsprojekt aufsetzen könnte. Ziel bei meinem Konzept war, möglichst viel gutes, vorhandenes zu übernehmen und nur die Teile zu "modernisieren", die hismastersvoice hier schon angebracht hat.

Gebt gerne Feedback - ist nur eine Idee. Aber es fliegt auch nur, wenn sich mehrere Leute daran beteiligen. Ich habe keine Zeit neben dem LoxBerry so ein Projekt zu stemmen. Ich denke das geht hismastersvoice genauso wenn ich das hier richtig verstanden habe.

Also:

Betriebssystem:
Als Betriebssystem bietet sich DietPi mit LoxBerry an. Damit haben wir Dinge wie SMB-Shares, USB, Netzwerk, etc. pp. abgefrühstückt und brauchen uns darum nicht mehr zu kümmern

Medienverwaltung:
Als Medienverwaltung und Streaming-Provider ist aus meiner Sicht Music Assistent die aktuell Beste Wahl. Die Entwicklungsgemeinde ist gigantisch durch Home Assistent und die Entwicklung ist extrem aktiv. Die Auswahl an möglichen Quellen und Ausgabeformaten ist riesig - unter anderem als Ausgabe Sonos, AirPlay, SnapCast und Squeezelite. Das scheint mir eine perfekte Basis zu sein. Gleichzeitig werden sehr viele Eingabeformate unterstützt: Lokal, Spotify, TuneIn, YoutubeMusik etc. pp.

Das einzigste Feature, was ich aktuell vermisse ist die Möglichkeit per AirPlay auf die Player zu streamen. https://github.com/orgs/music-assist...scussions/1757 Auch Klinke als Eingang scheint nicht out-of-the-box zu gehen. Eventuell kann man hier den Umweg über MPD nehmen. Das müsste man sich anschauen.

Schnittstelle Miniserver (Virtual Input/Outputs):
Zur Kommunikation mit Music Assistent gibt es eine API und dafür eine Python-Implementierung. Das kann man gut nutzen um ein Gateway zu bauen. Aus meiner Sicht bietet sich hier MQTT an. Das hat den Vorteil, dass wir damit über das LoxBerry MQTT Gateway eine Schnittstelle zu VIs in Loxone haben. (also das alte Squeeze-Connect Gateway aus dem MS4H). Zudem müsste man späterm wenn man die Medienverwaltung mal wechselt, nur das Gateway anpassen. Alle nachfolgenden Dinge (siehe unten) können bleiben wie sie sind. Aus meiner Sicht ein riesiger Vorteil.

Schnittstelle Miniserver (Audioserver):
Hier haben wir zwei Möglichkeiten, die sich Gagi schon angeschaut hatte. Man könnte also Gagis eigene Implementierung oder die von Ruby Berends hernehmen und eine MQTT-Schnittstelle hinzufügen bzw. die alte LMS-Implementierung gegen MQTT ersetzen. Schnittstelle zum Music Assistent ist dann das oben erwähnte MQTT-Gateway.

Wenn Loxone die AudioServer Schnittstelle zumacht, bleibt immer noch die Schnittstelle über VIs - so wie zu Anfangszeiten des MS4H ja auch. Das wäre schade, ist aber von uns eh nicht zu ändern.

Weitere aktuelle Features des MS4H (KNX, T5, TTS, Powermanager, etc.):
Diese weären neu zu implementieren. Basis könnten die Skripte von hismastersvoice sein. Vorschlag wäre auch hier auf MQTT umzustellen und wieder das oben erwähnte MQTT Gateway zum MusicAssistent zu nutzen.

Lokale Ausgabe:
MusicAssistent unterstützt Squeezelite als Client. Damit können wir die vorhandenen beiden Squeezelite Plugins direkt nutzen. Zusätzlich könnte man dann noch ein neues SnapCast Plugin für den LoxBerry entwickeln und könnte auch das als Client nutzen (wird ebenfalls von MusicAssistent unterstützt).

Remote Ausgabe:
Von Haus aus unterstützt MusicAssistent Airplay, Bluesound, DLNA, Fully Kiosk, Google Cast, Home Assistent, SnapCast, Sonos, Squeezelite. Somit würden wieder die vorhandenen Squeezelite Plugins für den LoxBerry funktionieren. Für Squeezelite gibt es auch ein ESP32 Projekt. Externe Wifi Lautsprecher würden über AirPlay, Sonos, DLNA funktionieren. Ist UPNP noch aktuell? Das habe ich bei MusicAssistent leider nicht gefunden. Das oben schon erwähnte neue SnapCast Plugin kann ebenfalls direkt als Remote Zone genutzt werden.

Wenn wir das Konzept ausdiskutiert und Rund haben, müssten sich damit dann Leute finden, die sich dem Thema annehmen

Ich würde daher parallel mal eine Liste anfangen, damit wir schauen ob es genügend Leute hat, die mitmachen. Natürlich können mehrere Leute an einzelnen Themen arbeiten. Ich würde folgende Themen sehen:

Gesamtkoordination "MS4H 3.0"
Installationsroutine Medienverwaltung	@Prof.Mobilux
MQTT Gateway	@Prof.Mobilux
Audioserver Schnittstelle	@Gagi
Zus. Feature: PowerManager
Zus. Feature: TTS
Zus. Feature: T5
Zus. Feature: KNX
SnapCast Plugin / Schnittstelle

**hismastersvoice** · 2025-08-10T10:43:23+02:00

Habe das gerade mal alles nachgelesen, und soweit verstanden.

Features...
T5 wird eigentlich nicht mehr gebraucht, das wurde am Anfang nur erstellt weil kein Gateway vorhanden war.
KNX würde ich mal vernachlässigen, da ich das Ganze auf Loxone abzielen würde, und ein KNX Taster usw. kann in Loxone über die Gruppen-Adresse zum Gateway realisiert werden.

PowerManger kann ich wieder übernehmen.
TTS könnte man ggf. die von Liver_64 nutzen. https://wiki.loxberry.de/plugins/text2speech/start

Was aber noch irgendwie für mich fehlt ist das Managen der Player.
Irgendwo muss jeder Player angelegt werden, intere Player gehen sicher über die vorhanden Plugins, aber externe Sonos, AirPlay oder was auch immer nicht.
Das Gateway muss wissen mit wem er gerade redet und die Daten entsprechend der Zone zuweisen.

Zum Thema Gateway.
Es ist gerade bei Loxone so viel im Gange das man hier sicher einen Teil kpl. neu machen muss.

Fehlermeldungen wie...

Code:

DEPRECATED Don't use 'window.GUI.VirginAppScreen' or 'GUI.VirginAppScreen' but require 'VirginAppScreen' from 'LxComponents'

Warning: React has detected a change in the order of Hooks called by %s. This will lead to bugs and errors if not fixed. For more information, read the Rules of Hooks

Weise darauf hin das an der Basis was geändert wird.

Offene Punkte für mich...
- Player Manger (neues Plugin?)
- PowerManger
- Equalizer
- evtl. TTS / Alarm / Bell...

Wenn wir einen PlayerManger schreiben, dann würde ich den PowerManger natürlich dort integrieren.

PS:
Noch ein offener Punkt... Welche Platform(en) wollen wir nutzen?
Je mehr desto aufweniger.

**Prof.Mobilux** · 2025-08-10T11:53:08+02:00

hismastersvoice Magst Du auch die Gesamtkoordination übernehmen? Ist für mich keine Programmieraufgabe, sondern nur "die Fäden zusammenhalten" und im Zweifel Entscheidungen zu treffen. Da Du am meisten Erfahrung mit dem MS4H hast, wärst Du für mich der einzigste, der das machen kann

Den Code würde ich über GIT machen - das hat sich bei LoxBerry extrem bewährt. Die Core-Entwickler haben dort direkt Zugriff auf das Repo, alle anderen können per PullRequest mitarbeiten. Das macht es einfach extrem einfach.

Zitat von hismastersvoice

TTS könnte man ggf. die von Liver_64 nutzen. https://wiki.loxberry.de/plugins/text2speech/start

Das müsste man sich anschauen. Das Plugin ist verwaist, aber Liver_64 baut das kontinuierlich im Sonos-Plugin aus, so wie ich das sehe. Von dort könnte man sicherlich vieles übernehmen oder das TTS-Plugin nochmal auf "Vordermann" bringen.

Die Integration von "Durchsagen" hat Music Assistent schon an Bord. Die Schnittstelle kenne ich (noch) nicht, aber er kann das aus Home Assistent heraus. D. h. Player Stop, Durchsage, Player Start müsste er eigentlich beherrschen. Bei uns könnte diese Funktionalität dann das MQTT Gateway übernehmen.

Was aber noch irgendwie für mich fehlt ist das Managen der Player.
Irgendwo muss jeder Player angelegt werden, intere Player gehen sicher über die vorhanden Plugins, aber externe Sonos, AirPlay oder was auch immer nicht.
Das Gateway muss wissen mit wem er gerade redet und die Daten entsprechend der Zone zuweisen.

Ja, das müssten wir machen. Wäre für mich ein Teil des MusicAssistent Plugins. Würde ich mit übernehmen. Vermutlich geht das aber einfacher, weil man die Player an sich alle in MusicAssistent anlegt. Über das MQTT Gateway kriegen wir die alle nach MQTT. Und von dort lesen wir sie ein und bringen sie Richtung AudioServer Schnittstelle. Eine eigene GUI ist da eventuell gar nicht mehr nötig.

Zum Thema Gateway.
Es ist gerade bei Loxone so viel im Gange das man hier sicher einen Teil kpl. neu machen muss.

Ich denke das kommt eh mehr oder weniger zum Schluss. Erst einmal muss die Infrastruktur laufen (Sync. Player anlegen, MQTT Gateway etc. pp.). Bis dahin haben wir sicherlich auch weitere Infos, was da auf Loxone-Seite gerade passiert.

Offene Punkte für mich...
- Player Manger (neues Plugin?)

Das nehme ich mit zum Gateway.

- PowerManger
- Equalizer

Wären beides Themen, die ich eventuell auch ohne eigene GUI einfach MQTT lösen würde. Maximal mit minimaler GUI und Steuerung über das MQTT-Gateway.

- evtl. TTS / Alarm / Bell...

Die Schnittstelle ist wie geschrieben im MusicAssistent schon integriert. NUr die TTS-Engines müssten wir sicherlich mitliefern.

Wenn wir einen PlayerManger schreiben, dann würde ich den PowerManger natürlich dort integrieren.

Noch ein offener Punkt... Welche Platform(en) wollen wir nutzen?
Je mehr desto aufweniger.

Was meinst Du mit Plattformen genau?

Damit hätten wir dann schon einmal:

Gesamtkoordination "MS4H 3.0"	@hismastersvoice
Installationsroutine Medienverwaltung	@Prof.Mobilux
MQTT Gateway und Player-Verwaltung	@Prof.Mobilux
Audioserver Schnittstelle	@Gagi
Zus. Feature: PowerManager	@hismastersvoice
Zus. Feature: TTS	@Liver_64
SnapCast Plugin / Schnittstelle
Equalizer	@hismastersvoice
Dokumentation

**Meininger** · 2025-08-10T21:38:40+02:00

Hallo,

Da schaut man mal zwei Tage nicht hier rein und auf einmal ist hier richtig was los 🤣👍
Bin auch gern dabei und würde euch gern unterstützen! Da ich jetzt aber kein Profi im Software schreiben bin, kann würde ich anbieten andere Aufgaben übernehmen.... Testen, Doku und so etwas wenn es gebraucht wird 😉
Ich finde es Mega, dass es hier weiter geht! Gerade das offene Konzept mit der Möglichkeit alles an Playern in Loxone einzubinden, was irgendwie einen Netzwerk Standard spricht hat mich schon immer überzeugt. Bis auf ein paar Kleinigkeiten läuft es ja auch mit dem Lyrion Server, wenn es aber anderes gibt, was optimaler genutzt werden kann, ist das natürlich ein Argument.

Gruß Sascha

**tokylo** · 2025-08-10T21:53:34+02:00

Ich finde euren Plan mit MusicAssistant und Snapcast richtig gut!
Bei mir läuft MusicAssistant in HomeAssistant mit YouTube Music und den MS4H Zonen bereits.

Mein Ziel ist, MusicAssistant mit dem BuiltIn-Snapcast Server, YouTube Music und TTS komplett in HomeAssistant laufen zu lassen und dabei eure neue Audioserver-Schnittstelle / MQTT Anbindung zu nutzen.

Es wäre wirklich super, wenn die neue Schnittstelle auch eine Installation von HomeAssistant mit MusicAssistant unterstützen würde.

**Prof.Mobilux** · 2025-08-11T05:41:02+02:00

Also ich habe gestern mal eine Testinstallation in einer LoxBerry VM gemacht.

Music Assistent per Docker lief in 5 Minuten! Docker installiert, Dockerimage des MusicAssistent gestartet, fertig. Lokale Musiksammlung per SMB direkt aus MusicAssistent eingebunden, TuneIn Account hinzugefügt. Hat in Summe 10 Minuten gedauert.

Meine Squeezelite Clients (Squeezelite Plugin auf LoxBerry) wurden sofort erkannt, nachdem ich die IP-Adresse auf den MusicAssistent Server umgeschrieben hatte. Nach 2 MInuten lief Musik, inkl. Sync auf Gruppen. Das hat mich schon beeindruckt!

Mögliche Quellen:

Mögliche Ausgabe-Clients - inkl. Sqeezelite (fehlt in der Liste, weil ich es schon hinzugefügt habe):

Aber wie vermutet: Man kann außer per Spotify Connect Plugin (und das ist Alpha) nicht auf den MusikAssistent Server streamen, z. B. per Airplay. Das ist aktuell für mich noch ein NoGo, weil ich es brauche

Als Idee dazu hätte ich:

shairport-sync --> ffmpeg --> Stream

Und die Streams als Wiedergabeliste in MusicAssistent anlegen. Über das MQTT Gateway dann entsprechend die Playliste mit dem shairport-Stream abzuspielen, wenn dort hingestreamt wird. Müsste man schauen wie stabil das läuft. Parallel schaue ich mir mal an, ob man dazu auch den MPD missbrauchen kann.

Ms4h 2.0

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar