Ms4h 2.0

[hismastersvoice]

Habe ich heute Nacht auch gemacht
Kann ich so 1:1 bestätigen...

Radio und lokale Quelle lief, was ich aber nicht hin bekommen habe, ist das Spotify auf Sonos oder AirPlay wiedergegeben wird.
Muss ich heute mal noch schauen.

Auch das Anouncement habe ich kurz mit Testfiles getestet, aber da lief noch nichts sync und eher langsam (Raspi 4).
Schau ich mir auch in Ruhe noch an.

Airplay2MA
ffmpeg brauchen wir eh um die Durchsage von der LoxoneApp .wav in ein mp3 umzuwnadeln.
Nachteil dürfte auch wieder das Verwalten ein Thema sein, wenn man zB nicht alle Geräte freigeben will.

[Prof.Mobilux]

Spotify und Sonos und Airplay Clients hab ich leider nicht (mehr) zum Testen. Müsste ich mir erst mit shairport-sync was bauen. Ich hab dafür SnapCast getestet und auch das lief sofort als Server/Client. Und man sieht auch die einzelnen Snapcast-Clients - wenn ich es richtig gesehen habe, kann man die auch zu separaten Gruppen etc. zusammenfassen. Wäre also wirklich was als Alternative zu squeezelite.

hismastersvoice Wie geht das mit den Announcements?

Ich mache mich mal daran ein Grundgerüst als LoxBerry Plugin zusammenzubauen, an dem wir dann arbeiten können.

Und das Team hätten wir dann auch komplett:

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	@Prof.Mobilux
Equalizer	@hismastersvoice
Dokumentation und Testing	@Meininger

[nufke]

feel free to add me to the table under a label called "App" (whatever it means ;-)

[hme0354]

Ihr könnt mich auch bei Testing und Doku dazutun

[Meininger]

Hallo,

Habe gestern Abend auch eine testinstallation auf meinem Homeassistant Raspberry (5) gemacht, lief wirklich problemlos durch. Den Server kurz mein Netzlaufwerk mit der ganzen Musik gezeigt, da hat er kurz dran geschnüffelt und zack war die Musik bereit zum abspielen. Nach aktivieren des Dlna plugin wurden auch meine ganzen Player erkannt (aktuell Volumio installationen auf verschiedener Hardware)
Einzig mit dem Radio plugin bin ich nicht so recht happy geworden, default sind da nur Streams mit niedriger Qualität hinterlegt, Anbieter unvollständig, aber da muss ich noch mal genauer schauen. Auch wurden keine Cover Bilder der aktuellen Titel angezeigt, was ich mit lyrion eigentlich ganz nett finde. Aber wie gesagt, da bin ich noch nicht ganz durch.
Spotify habe ich, das kann ich testen, qobuz nutze ich auch ab und an in den Wintermonaten.


Gruß Sascha

[Labmaster]

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.
...

Schade, genau das sind eigentlich Komponenten die ich als extrem wichtig erachten würde.
Wie wir ja auch am Tel schon öfter mal besprochen haben, sollten gerade im Immobilienbereich (was halt kein Smartphone Gedöhns sein sollte) alles möglichst robust und für die Ewigkeit ausgelegt sein. Ich wäre nach wie vor sehr vorsichtig damit sich drauf zu verlassen, dass Loxone an den Gateway Schnittstellen nichts verändert und wer will als Hausbesitzer dann schon immer wieder nacharbeiten.

Auch so ein System um einen Loxberry rum zu bauen halte ich für gewagt. So eine System sollte man eher möglichst schlank, straff und Resourcen schonend aufsetzen und nicht mit zusätzlichen Hintergrund Tasks Störeinflüsse hinzufügen.
Ich habe jedenfalls auch mit der MS4H Hardware lange gebraucht bis 32 Kanäle gleichzeitig auf Dauer ohne Quirks ordentlich gelaufen sind.
Aber das ist wieder ein ganz anderes Thema.

Auch das Thema was wir schon mal mit den EQ hatten wird wieder ein Thema werden, der 10band EQ ist von der Qualität einfach Bescheiden und benötigt auch mehr Resourcen.
Ich hoffe dass der MS4H in seiner jetzigen und sehr gut funktionierenden Form noch lange weiter Bestand hat, auch wenn es dann eventuell nicht mehr offiziell von dir gepflegt werden kann.
Jedenfalls stimmen mich die hier bisher eingebrachten Vorschläge für eine neue Variante alles andere als optimistisch.

[Labmaster]

Noch eine Frage zur Verwendung von MQTT.

Bisher ist z.b. bei mir alles so eingerichtet, dass der Loxberry für unterstützende Aufgaben zuständig ist, also z.B. fürs Wetter Plugin, Anwesenheitserkennung ...
Ich möchte aber im Haus keine weiteren OS Systeme haben die für Basis funktionen notwendig sind, also für Licht, Zugang, Beschattung, Heizung und Musik.
Wie auch schon geschrieben, läuft der bisherige Musikserver auf einer eigenen Hardware um vor allem keine weiteren nicht deterministischen Lasten auf dem System zu haben. (hat sich bisher extrem bewährt)

Wenn nun ein neuer Musikserver intern MQTT benötigt, ein Loxberry weiterhin (abkömmlich) extern zu laufen hat, wie würde man das im neuen Musikserver mit Messages zu/von Loxone machen ?

[hismastersvoice]

hismastersvoice Wie geht das mit den Announcements?

Über HomeAssist... Kenne keine andere Möglichkeit.
Eine Rest API gibt es nicht dafür.

[Prof.Mobilux]

Labmaster Ich denke zum LoxBerry müssen wir ein paar Dinge klarstellen.

Der LoxBerry ist im Endeffekt eine WebUI. Es laufen dort kaum Hintergrunddienste, die wirklich Ressourcen benötigen. Er wurde für einen Pi1 entwickelt und läuft noch heute auf einem Pi Zero. Er unterscheidet sich damit auch in keinster Weise vom heutigen MS4H - der ebenfalls eine WebUI mitbringt und bei dem im Hintergrund ein Gateway zum LMS läuft. Natürlich mal stark vereinfacht gesagt.

Es gibt nur einen Dienst, der bei hoher Last auch viele Ressourcen benötigt: Und das ist das MQTT Gateway zur Anbindung an den Miniserver. Das wird nur zum Problem, wenn man Debmatic oder Zigbee auf dem LoxBerry laufen lässt und hier tausende Topics per MQTT synchronisiert werden. Für einen MusicServer spielt das keine Rolle.

Du kannst genauso wie heute einen dedizierten Musicserver auf LoxBerry Basis aufbauen. Wenn Du keine anderen Plugins installierst, ist der LoxBerry genauso schnell oder langsam wie Dein heutiger MS4H. Das unterscheidet sich nicht. Beide Systeme verwenden DietPi als OS.

MQTT: Der heutige MS4H kommuniziert per TCP mit dem LMS und per UDP mit dem Miniserver. Und intern nutzt er JSON-Files. Der "neue" MS4H wird per Websocket mit dem MusicAssistent (quasi der "neue" LMS) kommunizieren und per MQTT die Daten weitergeben. Vom Ressourcenbedarf macht das keinen signifikanten Unterschied. Der MQTT-Broker läuft intern auf dem LoxBerry und wenn dort keine weiteren Plugins installiert werden, ist er ausschließlich für den MS4H da.

Ich sehe hier überhaupt kein problem den LoxBerry als Basis für einen dedizierten MS4H herzunehmen. Der Ressourcenbedarf zum MS4H ist identisch, weil die Basis vom Prinzip her identisch ist (Apache, Skripting, Gateways). Und ja: Auch ich wprde auf einem MS4H auf LoxBerry Basis dann nichts weiter als den MS4H installieren.

Zukunftssicherheit: Den heutigen MS4H kannst Du per VI/VO aus Loxone heraus steuern. Damit bist Du - solange Loxone die Virtual Inputs/Ouputs nicht abdreht, von Loxone's APIs unabhängig. Jeden Taster, den Du in Loxone einbinden kannst (Touch, KNX, 24V) kann auch den MS4H bedienen. Heute schon und auch zukünftig. Es braucht die AudioServer Schnittstelle dazu nicht.

Der LMS hat noch 2-3 Core-Entwickler. Die kommen ehemals von Logitech und machen die Arbeit freiwillig. Logitech hat sich vom LMS zurückgezogen. Haben diese Entwickler keine Lust mehr, ist der LMS tot. Viele Plugins sind schon heute verwaist und Buggy. Neue Feature skommen eh schon seit Jahren nicht mehr hinzu. Das ist eine extreme Schwachstelle.

Andere Projekte haben längst an LMS vorbeigezogen und eine weit aus größere Entwicklergemeinde. Der nun von uns ausgesuchte MusicAssistent ist Teil der HomeAssistent Entwicklergemeinde.

Aber es steht Dir ja auch frei den heutigen MS4H einfach weiter zu nutzen. Solange der LMS funktioniert, funktioniert auch der heutige MS4H.

[Labmaster]

Nur zu meinem Verständnis, hätte ich dann zwei MQTT Broker im Netzwerk, also den vom "normalen" Loxberry (welcher halt bisher für Gimmicks zuständig ist) und dann den lokal auf dem Musikserver welcher aber nur für lokal Dinge auf dem Musikserver zuständig ist und dann per UDP oder Http mit dem Miniserver kommuniziert ?

[Prof.Mobilux]

Wenn du das so haben möchtest - ja. Das wäre der Standard, wenn du den zweiten LB installierst. Oder du nutzt einen gemeinsamen Broker. Auch das geht.

Und es ist auch möglich den Music Assistent getrennt vom Plugin auf separater Hardware laufen zu lassen. Auch das ist möglich - wenn auch in meinen Augen nicht notwendig.

Oder nur die Zonen auf separater Hardware. Oder einen Teil davon. Auch das geht.

[Labmaster]

Bei einem Musikserver finde ich es wichtige, dass dieser eben möglichst autonom betrieben werden kann.
Bei uns wird der MS4H praktisch nur über die (spezielle "Labmaster") T5 Tastenbedienung) bedient bzw. teils auch über PM.
Eine anderweitige Bedienung (Webseite des LMS) gibt es wirklich nur in Ausnahemfällen, falls man mal ganz speziell z.B. einen Podcast hören möchte.
Der MS4H ist sowas von unauffällig und dabei immer präsent und immer in Betrieb (und das auf 32 Kanälen und über 17 Zonen), seit Jahre wirklich eines der zuverlässigsten System im ganze Haus. Genau so wie es sein muss.

Auf eine eher unsicher und pseuso gefakte Einbindung (Musik- oder Audioserver Gateway) in Loxone kann ich komplett verzichten, da bau ich mir lieber eine sehr angepasste Bedienung mit Loxoen Standard Boardmitteln.

Ich sehe bisher auch noch keine wirklichen Probleme mit dem LMS, auch bei den Plugins nicht, was braucht man denn schon an Plugins ? (bei mir laufen Spotify, Airplay, Podcast, Youtube bisher ohne Probleme)

Mit Systemen wie HA kann ich mich gar nicht anfreunden (auch wenn ich diese auch testweise am laufen hatte/habe), alleine wenn ich da mal zwei drei Tage nicht drauf schaue und dann schon wieder 5 Updates sehe bekomme ich Pilze. Das hat mit einer soliden robusten Haussteuerung gar nix zu tun sondern ist m.M. nach nur was für Leute die Smarthome als Hobby sehen. Klar, so war ich in jungen Jahren auch mal, aber irgednwann hat man dann anderen Interessen und sowas nervt dann nur noch.

Aus diesem Grund versuche ich immer alles so straff und dediziert wie möglich zu bauen. Möglichst keine OS Systeme und wenn es sich vermeiden lässt auch möglichst wenig Kommunikationkanäle welche über IP laufen.

[Gagi]

Soo....

was nicht alles passiert wenn man im Urlaub ist und nicht die ganze Zeit e-mails liest, bzw. ins Forum schaut.

Music-assistant als Basis find ich super und auch dass man die bestehnden Squeezelite Zones einfach weiter verwenden kann. Das kommt meinem Setup zu gute, in dem alle Zonen extern mit orange-pi zeros betrieben werden. Damit koennen wir weiterhin eine monolitisches setup und auch ein distributed setup supporten.

Bzgl. des Gateways und dem Audioserver support. Ich denke die meisten von uns wollen natuerlich dass es mit der neuen Audioserver API funktioniert, aber selbst falls das nicht klappen sollte, koennen wir weiterhin das alte MusicServer API unterstuetzen, natuerlich auch nur solange wie Loxone da nicht den Hahn abdreht. Bisher seh ich allerdings nicht dass sowas geplant ist. Ich wuerde hoffen das Loxone sowas ein bisschen im vorraus ankuendigen wuerde um ihre Bestandskunden nicht zu verkraueln... Aber evtl. ist da auch nur wieder der Wunsch der Vater des Gerdankes.

Bei der Kommunikation des Gateways mit dem Music-assistant bin ich mir noch etwas unsicher, ich wuerde da statt MQTT eigentlich direkt per websockets kommunizieren. Ansonsten muessten wir ja wirklich alle Infos nochmal per MQTT schicken, also zB der kompletten tree aller lokalen Audio files inkl. Meta-Daten etc.
Aber das ergibt sich bestimmt noch wenn wir etwas tiefer gehen und die Details anschauen.

Als Basis wuerde ich aktuell wohl eher meinen eigenen Stand verwenden, da ist der Code zwar nicht so clean, dafuer sind da aber eigentlich schon fast alle Features des Audio/Music-Servers abgedeckt inkl. Media-Browsing, Spotify, Suche und Durchsagen.

Labmaster Ich bin vollkommen bei dir dass ein System im Haus stabil laufen soll. Der Prof hat ja schon ein paar Sachen erklaert. Ich denke am Ende koennte der MS4H 3.0 ziemlich flexibel werden und hoffentlich auch genauso stabil wie der jetzige MS4H.
Nur weil der T5-Support und der KNX-Support momentan out of scope sind, bedeutet das ja nicht dass man das ganze nicht noch dazu bauen kann. Wie immer sollte man etwas kleiner Anfangen und moeglichst das liefern was die meisten Leute auch wirklich brauchen.

[tobsch]

hismastersvoice & Prof.Mobilux wirklich sehr cool was ihr hier plant - ich halte music assistant auch für eine sehr gute, zukunftssichere basis und freue mich drauf.
Sagt mal, ein Verbesserungsvorschlag: Ihr habt euch ja schon auf git geeignet: Warum stellt ihr das ganze nicht unter eine passende Open Source Lizenz und öffnet eine Github Org für das Projekt? Ich glaube ihr findet hier sicher ein paar Mitstreiter die Lust haben ebenfalls etwas beizutragen (Zähle mich da rein) und ich glaube es kostet in dem Falle wenig extra Aufwand.
Ihr könntet eine offene Roadmap machen und Github Issues ist mittlerweile sehr gut für Projektmanagement.

Vielleicht kann man das Projekt auch stärker modularisieren - ich bin nicht super tief im Thema aber zB die reine Audioserver Anbindung könnte ja fast ein eigener Service sein (wie eben https://github.com/rudyberends/loxon...rver/tree/main) der in einem Docker Container "wasweissichwo" läuft.

Ganz Alterntive Route: Kann man das ganze nicht vielleicht sogar als Plugin für MusicAssistant umsetzen? Es gibt ja schon ein kleines Plugin Ökosystem...

Was meint ihr?

[Prof.Mobilux]

Ist schon der Fall.

[tobsch]

Da hab ich noch mehr ergänzt als Du schon kommentiert hast :-) Was denkst Du zur Plugin Idee (aus meinem Edit)?