[Neues Modul] Snapcast

[unimatrix]

Hallo,
ich habe ein Modul zur Steuerung des Snapcastservers erstellt: https://github.com/badaix/snapcast

Snapcast ist ein Multiroomaudiosystem, hierbei wird Sound über TCP Verbindungen im Netzwerk an eine oder mehrere Clients verteilt und vollkommen synchron wiedergegeben. Es ist eine einfache Alternative zu einer äquivalenten Lösung mit Hilfe von Pulseaudio. Durch die JSON RPC Schnittstelle wird gewährleistet, dass FHEM immer den genauen Zustand des Servers, der Streams und aller Clients kennt. Diese Infos werden alle als Reading bereitgestellt. Weiterhin können die Clients über entsprechende Set-Befehle gesteuert werden, z.B. in ihrer Lautstärke, oder welchem Stream sie zuhören.

Das Modul nutzt DevIo.pm, hat keine blockierenden Elemente und benötigt kein Polling. Eine kleine Doku befindet sich im commandref Format am Ende des Moduls.

Ich würde mich über Tester und Feedback freuen, gerne auch Anregungen für Erweiterungen.

Ein typisches Setup ist es, Snapcast gemeinsam mit mehreren MPD oder Mopidy Instanzen auf einem Server laufen zu lassen (dieser Server kann auch ein PI sein o.ä.) und dann in jedem Raum einen Client laufen zu lassen. Es kann auch ein Client auf dem Server selbst laufen (also lokale Soundausgabe). Es gibt Linux- und Android Clients.

Eine Diskussion zum Thema Multiroom und weiteren Ideen rundherum findet sich auch hier: https://forum.fhem.de/index.php/topic,59135.0.html

Die jeweils aktuellste Version findet ihr in meinem GIT: https://github.com/unimatrix27/fhemmodules/blob/master/96_Snapcast.pm

Sollte sich Interesse zeigen, und die gröbsten Bugs raus sein, werde ich mich gerne darum bemühen, das Modul in das SVN zu bekomemen. Bis dahin werde ich größere Änderungen hier bekannt geben.

Viel Spaß!

[jeckyllhavok]

Hi,
sehr geil, bin genau nach so etwas auf der Suche.
Werde ich gleich mal testen und berichten

VG

jeckyllhavok

[LeoSum]

Super Modul!

Ich würde noch einen Vorschlag machen:

Die Readings einzelner Clients werden momentan mit fortlaufender Nummer folgendermaßen angelegt:

clients_1_stream
clients_1_name
clients_2_stream
clients_2_name

Wenn der Snapserver neugestartet wird, kann es sein, dass die client Reihenfolge eine andere ist. Wenn man Notifies hat, die auf bestimmte Reading Änderungen reagieren, müssen diese auf die neue Client Nummer angepasst werden. Ich würde daher vorschlagen, anstelle der fortlaufenden Nummer die macadresse des clients im Namen der Readings zu verwenden.

Desweiteren sollten bei einem Update nicht mehr vorhanden clients aus der Reading Liste gelöscht werden.

Gruß
Leo

[unimatrix]

Das ist richtig, das kann so nicht bleiben. Bei Snapcast selbst ändert sich allerdings auch gerade einiges. Jeder Client wird eine feste ID bekommen. Die wird meistens der MAC entsprechen.

Habe heute ein Update gemacht. Es gehen jetzt auch Volume Steps.

[unimatrix]

Folgende Änderungen sind seit heute auf dem GIT verfügbar:

- Die Clients in den Readings werden nicht mehr nur nach Nummer aufgeführt, sondern nach ID. So bleiben die Readings immer gleich und man kann entsprechende notifies bauen
- Man kann pro Snapcast Client eine virtuelles Modul definieren. Dies ist dafür gedacht, dass man das ganze besser in bestehende Visualisierungslösungen einbauen kann, außerdem können so clientspezifische Attribute definiert werden.

Die durchnummerierten Readings plane ich mittelfristig zu entfernen. Sie sollten nicht mehr genutzt werden.

Doku ist im Modul unten als HTML für die Commandref.

[LeoSum]

Super, ich werde das am Wochenende testen!

Ich antworte mal hier auf eine ursprünglich im anderen (Multiroom Project) Thread gestellte Frage, das gehört eher hier her:

Hallo, kann ich nicht reproduzieren. Das Modul hält eine offene Verbindung zum Snapcast Server und sollte eig. alle Readings updaten, die auch vom Server upgedated werden. Das betrifft ja gerade auch solche Updates, die von einem anderen Client, z.B. vom Android Client aus, angetriggert werden. Wenn ich bei mir im Android Client z.B. Mute und UnMute dann sehe ich das sofort in den Readings.

Ein Extra GetStatus wollte ich eigentlich vermeiden. Kannst du das Problem genauer beschreiben?

Ich meinte damit nicht, dass über Android gemacht Änderungen in FHEM nicht angezeigt werden. Das funktioniert wie du sagtest wunderbar!

Mein Problem ist folgendes, wofür ich den zusätzlichen GetStatus Befehl an entsprechender Stelle eingefügt habe:
Wenn ich über FHEM einen set befehel an einen snapclient sende, ändert sich das reading in FHEM nicht.
Ich vermute, dass der socket direkt nach dem Schreiben nicht direkt gelesen werden kann oder sowas. Im Android controller kommt die änderung (bspw. Mute oder Volume) aber direkt an.

Das hatte ich in meinem kümmerlichen Versuch ein Snapcast Modul zu schreiben damals auch festgestellt und mit dem mauellen GetStatus nach dem Setten gelöst.

Was spräche denn gegen ein zusätzliches GetStatus? Schlechter Stil?

[unimatrix]

Jetzt verstehe ich was du meinst. Ich nehme an, dass dein snapcast server nicht innerhalb des Timeouts, den ich verwende (0,1 Sekunden) ein Result sendet, sonst würde das nämlich sehrwohl sofort im Reading angezeigt. Das war sowieso eine Fummellösung. 0,1 Sekunden ist kurz, aber auch so lange will ich FHEM nicht blocken. Ich werde das auf vollständig asynchrone Kommunikation umstellen, das erfordert aber noch ein wenig Logik drumherum, und dann wird das auch bei dir funktionieren. Das mit dem getStatus braucht man dann nicht und ich mag solche Lösungen nicht. Das soll von vorne herein richtig gehen

[LeoSum]

Alles klar.
Dann verschweige ich dir, dass ich bis du die saubere Lösung umgesetzt hast, diese Zeile in alle deine Versionen einfügen werde

Ich bin froh, dass sich jetzt jemand, der offenbar Ahnung von der Materie hat mit diesem Modul befasst. Meins war mehr eine unsaubere Behelfslösung.

Auch toll, wie du Vorschläge berücksichtigst und sofort umsetzt! Danke!

[unimatrix]

Habe eben ein größeres Update eingecheckt. Das meiste unter der Haube:

- Die Kommunikation ist jetzt vollständig asynchron. Das Modul merkt sich, welcher Request mit welcher ID an den Snapcast-Server ging und verarbeitet die Antworten dann asynchron, egal wie lange der Server braucht und in welcher Reihenfolge er antwortet.
- Das Mute Toggling funktioniert jetzt. Einfach "set <name> mute" eingeben, ohne true oder false.
- Das Problem, dass das Modul nicht funktionierte, wenn man sehr viele Streams definiert hatte, sollte der Vergangenheit angehören.

Insgesamt habe ich eine Menge geändert, so dass sich natürlich auch neue Bugs eingeschlichen haben könnten. Daher bitte ich nach wie vor um Nachsicht. Ich bin mir aber sicher, dass der Weg so richtig ist. Ich plane auch keine nennenswerten Erweiterungen im Moment so dass ich dieses Modul wohl hoffentlich bald als 1. Stable-Version herausgeben kann.

[drdownload]

Ich hätte noch eine Frage:

was ist denn der Hintergrund, dass Clients es für einen Client 2x Readings gibt:
clients_7802f821777a_nr = 1
clients_1_id = 7802f821777a

und noch zwei Verbesserungsvorschlage:
Eine Liste der Clients und Streams jeweils als Dropdown beim Zuweisen
Beide Listen auch als Array in einem Reading

[unimatrix]

Neue Version online.

Änderungen:

- die alten Readings nach dem Schema clients_1_id gibt es nicht mehr. Das war noch ein Überbleibsel.
- Feature Volume Constraint implementiert. Details in der Commandref am Ende des Moduls.
- Code aufgeräumt
- kleinere Bugs beseitigt

@drdownload: Das mit dem Dropdown mach ich rein. Weiss aber gerade noch nicht wie das geht. Was meinst du mit Array? Ein Reading, wo alle Clients drin sind. Mit was für Infos? Das kann ja sehr lang werden.

Die Volume Constraints kann man leicht testen. Einfach mal folgendes Attribut anlegen (für ein Client-Modul, nicht für das Servermodul)

attr <snapcast_client_name> constraints standard|24:00 50

Damit ist die Lautstärke grundsätzlich auf 50% limitiert. Jetzt kann man auch in der App die Lautstärke nicht mehr höher stellen.

[unimatrix]

Info: Das Modul ist ab jetzt auch im SVN

[maylow]

Super, Danke für die Arbeit.

[unimatrix]

Es gab noch ein paar Bugs, aber die sind jetzt raus. Ich denke das Modul ist jetzt ziemlich stabil. Auf zum nächsten Modul...

[unimatrix]

Für all diejenigen, die Snapcast z .B. auf einem Rechner einsetzen, auf dem auch KODI läuft, habe ich den Snapcast Client etwas "gehackt", damit das Sounddevice freigegeben wird, wenn der Client auf Mute gesetzt wird. So kann man den Client immer laufen lassen, und muss ihn nur muten, wenn man was anderes benutzen will. Das ist nur eine Quick & Dirty Lösung, aber zumindest schonmal ganz hilfreich.
https://github.com/unimatrix27/snapcast/tree/develop

[drdownload]

Wow, coole Idee.

Btw. unter Android ist es kein Problem allerdings führt die Kombi aus Snapcast Stream und DTS Passthrough dafür natürlich zu Audiomüll (ich habe allerdings ein Notify, dass sobald Kodi play als state hat den Snapcast-Client mutet)

[unimatrix]

das mit dem Notify dachte ich mir ja auch, aber ist es dann nicht schon zu spaet? Es müsste ja gemuted werden, bevor KODI auf das Device zugreift.

[drdownload]

Auf Android ist es egal, da ist das Maximum 0,x Sekunden mit beiden Audioquellen gleichzeitig.

Habe gestern auch einen RPi2 Client installiert, da kann Snapcast abstürzten wenn Kodi sich die Audiodevice nimmt.

[LeoSum]

Ist das Modul auch zur neuen 0.11 Version von Snapcast kompatibel, oder muss das neue JSON Format für Gruppen erst im FHEM Modul umgesetzt werden?

Sprich: sollte ich mit dem Update auf 0.11 noch warten?

Gruß
Leo

[drdownload]

Hi, nachdem es gröbere Umstellungen im JSON gab mit den Gruppen ist es leider nicht kompatibel (derzeit)

[drdownload]

Alright, nachdem ich FHEM neu gestartet habe und alle Clients die im Netz rumgeschwirrt sind auch auf 0.11 upgedated, kriege ich wieder readings und keinen json error.

[LeoSum]

Hey, danke für die Rückmeldung!

Heißt das, du kannst nach dem Update der Clients und des Servers mit der "veralteten" Version dieses Moduls auch weiterhin Lautstärke einstellen, Streams schalten und Muten?

[fume]

Hallo

Ich habe das Modul einmal aktiviert, aber leider bekomme ich keine Readings ausser "state opened"

Ausgabe auf Loglevel 5

Code Auswählen Erweitern

2017.05.28 10:07:17 3: Opening MySnap device localhost:1705
2017.05.28 10:07:17 5: SW: {"id":2,"method":"Server.GetStatus","jsonrpc":"2.0"}
2017.05.28 10:07:17 3: MySnap device opened
2017.05.28 10:07:18 5: snap: partial command received

Meine Snapcast Version ist 0.11.1.

[MarkusRobertAllen]

Hallo,
ich verwende für meine günstige LIDL WlanBox SILVERCREST 18 W SMRS 1 das SIRD Modul, um Musik auszugeben. Die Nachteile sind, dass ich die Lautsprecherausgabe von FHEM nicht auf die Box leiten kann, wie es wohl mit SONOS funktioniert (nur gelesen, da ich kein SONOS System besitze). Aus der Beschreibung von SNAPCAST habe ich nun herausgelesen, dass Text2Speech (FHEM) mit Snapcast funktionieren könnte oder interpretiere ich zu viel hinein?

Grüsse

[LeoSum]

@ MarkusRobertAllen: Snapcast wird nicht mit deiner Silvercrest Box reden, sondern nur mit Snapcast clients.

@ fume: Ich habe heute versucht auf 0.11.1 zu updaten. Leider ist die aktuelle Version dieses Moduls nicht mit der neuen Snapcast Version kompatibel, da sich das JSON format, mit dem informationen mit dem Server ausgetauscht werden geändert hat. Dies bedarf ein Update des Moduls. Bis das geschehen ist, müsstest du auf Version 0.10 zurückgehen.

[fume]

Danke für die Info.
Da ich im Moment keine Zeit habe für 6 Clienten + Server + Handys neu zu installieren,
werde ich mich einfach gedulden, und weiter die Android Steuerung verwenden.

[LeoSum]

ich habe das Modul angepasst für 0.11 und als pull request für unimatrix eingereicht. Nicht schön gecodet, aber bei mir funktioniert es nun mit einem 0.11 server und den clients noch auf 0.10.

Solange er die Änderungen nicht annimmt, können alle die eine funktionierende Version für 0.11 probieren wollen, diese hier finden:

https://github.com/1337sup3rh4x0r/fhemmodules/blob/59a9d0abcaf05571d07be947e0f040567932423d/96_Snapcast.pm

Wenn noch Fehler drin sind könnt ihr das gerne hier berichten.

Gruß
Leo

[Sheep]

Hallo,

zu erst mal großes Lob für das Modul. Funktioniert Eins A (im großen und ganzen).

Ich probier gerade etwas damit rum, und bin auf zwei Probleme gestoßen:

- in der $hash->{AttrList} fehlt am Ende ein Leerzeichen:
"streamnext:all,playing constraintDummy constraints volumeStepSize volumeStepSizeSmall volumeStepSizeThreshold"
-> müsste denke ich sein "streamnext:all,playing constraintDummy constraints volumeStepSize volumeStepSizeSmall volumeStepSizeThreshold "
Sonst wird das Attribut volumeStepSizeThreshold mit dem Standard Attribut on-change-reading zusammengewürfelt, und es gibt ein neues Attribut volumeStepSizeThresholdon-change-reading  Siehe auch Bild im Anhang.

- Dann habe ich auch das Problem, dass sich die SnapClient-Readings nicht updaten, wenn ich im Client-Modul zB die Lautstärke änder (wie auch schon von LeoSum beschrieben). Das Server-Modul übernimmt die Änderungen, und auch an die "echten" Clients wird es weiter gereicht. Nur die Readings FHEM-Snapclient bleiben alt  Woran könnte das denn liegen?? Modul-Version ist die aktuelle von GitHub, und Snapcast ist sowohl Client als auch Server v0.11

Ansonsten spitzen Arbeit 


MfG

Sheep

[bennebartsch]

Funktioniert das Modul noch? Bei mir kommen leider gar keine Readings rein...

[tamash]

Hallo!

Wird dieses Modul noch gepflegt.
Bei mir kommen leider keine Readings rein.

Ich verwende Snapcast Server/Client Version 0.15.0.

LG

[pinguin]

Hallo zusammen,

auch wenn die Frage schon mehrfach gestellt wurde, stelle ich sie auch noch einmal Wird das Modul noch gepflegt bzw. noch weiterentwickelt? In der Version aus dem Repo funktioniert das Modul nicht mehr. Nach meiner Fehleranalyse müssen sich die JSON-Aufrufe geändert haben. Über das Modul (Client) wird zum ändern der Lautstärke die folgende JSON-Abfrage ausgeführt:

{"id":9,"method":"Client.SetVolume","jsonrpc":"2.0","params":{"volume":120,"client":""}}

Laut Dokumentation (https://salsa.debian.org/debian/snapcast/blob/master/doc/json_rpc_api/v2_0_0.md#clientgetstatus) müsste der Aufruf jedoch folgendermaßen aussehen:

{"id":8,"jsonrpc":"2.0","method":"Client.SetVolume","params":{"id":"24:18:1d:57:b6:5f","volume":{"muted":false,"percent":74}}}

Dies habe ich auch mit telnet erfolgreich getestet.

Hier noch das Listing von meinem Client:

Internals:
   CFGFN     
   DEF        client MySnap 24181d57b65f
   FUUID      5dd265ab-f33f-d3cb-7ec7-292334ee6a93ee5d
   ID         24181d57b65f
   MODE       client
   NAME       SnapcastHandyTorsten
   NR         803
   SERVER     MySnap
   STATE      defined
   TYPE       Snapcast
   name       SnapcastHandyTorsten
   READINGS:
     2019-11-18 10:34:35   state           defined
Attributes:
   volumeStepSize 5
   volumeStepSizeSmall 1
   volumeStepSizeThreshold 5

Habe ich etwas nicht richtig gelesen? Kann mir jemand helfen?

Danke schon im vorraus und viele Grüße

Torsten

[twenta]

Vielleicht mal hier die weiterentwickelte Version testen (nicht von mir)?
https://github.com/boredomwontgetus/fhemmodules/blob/master/96_Snapcast.pm

[pinguin]

Hallo twenta,

jippie !!! Ganz lieben Dank für die schnelle Antwort. Hab es auch gleich getestet und siehe da... funktioniert auf Anhieb. Endlich kann ich die einzelnen Clients auch über FHEM steuern

Vieleicht kann ja jemand mal einen Verweis im Wiki erwähnen? Ich hätte das im github nie gefunden.


Viele Grüße

Torsten

[tamash]

hi!

Dieses Repo ist auf meinem Mist gewachsen. Ich hab leider nicht die Rechte das wiki zu editieren.

Es gibt auch noch einen offenen pull-request auf die repo von der ich eigentlich geforked habe.
https://github.com/1337sup3rh4x0r/fhemmodules/pull/3


Freut mich das es jemand nützlich findet.

LG
Thomas

[rcmcronny]

Nur als Info: Ich nutze diese Version von Dir auch, das enthaltenen Snapcast Modul geht ja leider nichtmehr ^^

Ronny

[rcmcronny]

@RudolfKoenig

Könnte man das nicht funktionierende Snapcast.pm Modul mit dem korrigierten Modul von
https://github.com/boredomwontgetus/fhemmodules/blob/master/96_Snapcast.pm

im FHEM Repo aktualisieren ?

Ich habe Unimatrix als Maintainer mal abgeschrieben, ich denke aber nicht, das eine Antwort kommt, er war seit Feb 2019 nichtmehr im Forum.

Ronny

[rakete123]

Das wäre wirklich sehr cool, wenn das möglich wäre.

[Beta-User]

FYI:

Hallo zusammen,

in Absprache mit Rudi habe ich das Modul Snapcast als MAINTAINER übernommen, das erste update kam heute morgen. Das war noch "ungefährlich" und bringt erst mal die commandref auf den "id"-Standard, so dass die Beschreibungen zu Attributen etc. dann direkt unter dem Eingabefeld eingeblendet werden.

Werde mich bei Gelegenheit dann aber etwas weiter unter das Auto legen, so dass es sein kann, dass künftige Updates auch mal "schwierig" werden; wer das Modul also nutzt und jegliche Gefahr bannen will, sollte es vom update ausnehmen ...

Fragen oder Anregungen bitte dann im neuen Support-Thread melden: https://forum.fhem.de/index.php/topic,128206.0.html.

Beta-User

Würde mich freuen, wenn jemand von den "alten Hasen" ggf. Interesse hätte, Mitzutesten und ggf. auch die Fertigstellung (?) von OpenMultiRoom zu unterstützen .

Grüße, Beta-User

[rcmcronny]

Hi,

sehr cool. Ich nutze es ja (naja primär als Wecker im FHEM) aber teste gern mit. Habe gesehen, das heute schon ein Update kam und finde es gut, das die Lösung wieder jemanden hat der sich ihr annimmt.
Wenn ich was tun kann, einfach melden.

Ronny

[Beta-User]

Hi zurück,

es gibt also tatsächlich noch mind. einen, der es aktiv nutzt, sehr schön.

Werde noch etwas brauchen, bis die Audio/pulseaudio-Konfiguration vollends steht und die ersten Test mit meiner überarbeiteten Modulfassung auch "durch" sind, wird ich die im anderen Thread angehängt.

Prinzipiell kannst du mir auch gerne den Weg (mit) weisen, wie denn sinnvollerweise was zu konfigurieren ist, 1:1 klappte jedenfalls bei mir die Konfiguration nicht so wie im Wiki zu Openmultiroom beschrieben... (Ich vermute u.a. ein Rechte- und/oder Reihenfolgeproblem). Thread dazu ist hier.

[tamash]

Oh, das freut mich sehr. Danke, Beta.
Hier wird das Modul vom ganzen Haushalt jeden Tag benutzt. Ohne diesem Modul würde es vermutlich niemand schaffen Musik/Radio abzuspielen.

LG
Tom