[Snapcast] - support Thread ab 2022

Begonnen von Beta-User, 28 Juni 2022, 13:50:12

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

wie ihr vielleicht mitbekommen habt, bin ich grade am Rumexperimentieren mit dem Thema, wie der Sound von einem MPD denn eigentlich am "geschicktesten" und flexibelsten auf die Ausgänge eines Yamaha-Receivers geschickt werden kann.

Dabei bin ich über die Module Snapcast und OpenMultiroom von @unimatrix "gestolpert", der aber leider seit langem nicht mehr hier im Forum aktiv gewesen zu sein scheint. Da Snapcast jetzt "anfängt zu zucken", habe ich mich in Absprache mit Rudi daher als ersten Schritt mal als MAINTAINER für Snapcast eingetragen, das erste update von mir 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.

Irgendwelche Kenntnisse im Modul dürft ihr (noch) nicht erwarten, wobei das in der Bedienung/Konfiguration auf der FHEM-Seite erst mal nicht wirklich schwierig ausschaut. "Spaßiger" finde ich die Konfiguration auf der FHEM=Snapcast-Server-Seite iVm. pulseaudio. Aber da lichtet sich so langsam aber sicher der Nebel...

Es wäre klasse, wenn sich wenigstens einer derjenigen auch als Tester zur Verfügung stellen würde, die das heute im Einsatz haben, dann würde ich die jeweilige Entwickler-Version ggf. vorab hier im Forum platzieren. Sonst müßte ich darauf ausweichen, das nach eigenen Tests dann eben direkt ins svn zu schubsen. Wer an derartigen Tests nicht teilnehmen will, sollte daher ggf. vorsichtshalber das Modul vom update ausnehmen (ggf. erst nach dem heutigen update).

Wer Fragen oder Anregungen hat, möge diese bitte hier platzieren und/oder für "spezielle Themen" auf separate Threads ausweichen, wer die Pflege stattdessen lieber selbst (statt meiner oder ergänzend) übernehmen möchte, darf sich selbstredend melden.

Weitere Pläne und Gedanken:
- Die kommende Version wird dann eine gewisse PBP-Konformität herstellen, anschließend wird es voraussichtlich gepackaged.
- Falls es im Ausgangsthread irgendwelche (noch) offenen Punkte gegeben haben sollte, könnt ihr das gerne hier platzieren, ich schau dann, ob da was zu machen ist...
- Mittelfristig würde ich mir gerne OpenMultiroom ansehen und die direkte Steuerung der jeweiligen Verstärkerhardware noch mit da reinknödeln. Macht irgendwie m.E. nicht allzuviel Sinn, die Lautstärke softwaremäßig zu ändern, wenn man das (bei vernünftigen Ausgangspegeln aus der Software) auch in Hardware haben kann...

Soviel erst mal für's erste,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#1
So,

dann hier also mal eine erste Version für mutige Tester, und dazu gleich eine erste Fassung des erweiterten OpenMultiroom-Moduls :) .

Bitte sichert eure aktuell vorhandene(n) Fassung(en) (Module sind typischerweise zu finden in /opt/fhem/FHEM), bevor ihr euch ans Testen macht. Am einfachsten eine Kopie machen und die halt z.B. mit der Endung .svn oder .old versehen.

Danach die hier angehängten Dateien in das Verzeichnis packen, und die Rechte anpassen (anzuzeigen mit ls -l; chown ist euer Freund, Soll ist typischerweise fhem:dialout) und dann FHEM neu starten (bei einem simplen reload hagelt es vermutlich eine Reihe Warnings wegen der nun fehlenden Prototypen).

Die Änderungen an Snapcast sind eher unter der Haube zu finden, funktional hoffe ich, dass alles noch funktioniert wie gewohnt:
- diverse Attribute werden nicht mehr zwangsweise vergeben/angelegt
- PBP meckert nur noch auf Level 3, mal sehen was davon noch auf einfachem Weg wegzubekommen ist (Falls jemand wissen will, was das bedeutet: Die file nach http://perlcritic.com/ hochladen, Level anpassen und 'Analzye ...' drücken)...
- Verboselevel von manchen Log3-Anweisungen

Es würde mich ausgesprochen freuen, wenn die Bestätigung auch von dem einen oder anderen der bisherigen Nutzern käme, dass alles erst mal weiter funktioniert wie gewohnt und keine "seltsamen Einträge" im Log zu finden sind. Dann würde ich das vollends "aufhübschen" und dann einchecken.

OpenMultiroom
Ist eine Art Erweiterung zum Snapcast-Modul, das es erlaubt, auch den (jeweils aktuell) dahinterliegenden Medienplayer zu steuern (derzeit beschränkt auf MPD, es sollte aber möglich sein, das auf "alles" auszuweiten, das "typische Medienplayer-Kommandos" versteht (z.B. auch Instanzen des Spotify-Moduls?). Weiter bringt es die Möglichkeit mit, Fernbedienungs-Codes (auch als Tastenfolgen) auszuwerten und dann als Kommando an den Player zu schicken
Da oft/meistens (?) eine Koppelung zwischen einer Snapcast-Instanz und einem Verstärker bestehen wird, der ggf. gesondert angesteuert werden müßte, dachte ich mir, es sei den Versuch wert, einen solchen (samt optionaler Angabe eines "inputs") auch noch zu integrieren.

Auch hier ist die Zahl der notwendigen/zwangsweisen Attribute erst mal gesunken, sinnvollerweise müßten wohl "mr" und "soundMapping" gesetzt werden (siehe Wiki), wer die Verstärker-Option testen will, gibt dann noch in "amplifier" den Namen des Verstärkers an, wer den input-Kanal mit Schalten will, setzt den - getrennt durch einen Doppelpunkt - dahinter (funktioniert derzeit ggf. nur bei Wechsel des streams).

Habe das mehr oder weniger (eher letzteres) kurz angetestet und bin mal gespannt, ob das allg. Interesse findet...

Viel Spaß jedenfalls beim Testen und Danke vorab!

Gruß Beta-User

EDIT: Per Perltidy aufgehübschte Fassungen, funktional unverändert.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rcmcronny

Hallo,

habe beide mal eingespielt. OpenMultiroom nutz ich aktuell aber nicht. Snapcast sieht erstmal gut aus, keine offensichtlichen Fehler. Mal gucken wie es sich die Tage verhält.

(Und hier auch abonniert :) )

Ronny

Beta-User

Zitat von: rcmcronny am 04 Juli 2022, 14:25:28
Snapcast sieht erstmal gut aus, keine offensichtlichen Fehler. Mal gucken wie es sich die Tage verhält.
:) Dann bin ich erst mal beruhigt und warte, ob du noch irgendwas an Auffälligkeiten oder komischen Log-Einträgen findest (es sollten bei verbose=3 weniger geworden sein).

Hatte schon vermutet, dass die Ankündigung untergegangen war, aber irgendwie ist es m.E. auch nicht geschickt, die alten Support-Threads dann endlos weiterzuführen, wenn ein Maintainer-Wechsel stattgefunden hat.

Zitat
OpenMultiroom nutz ich aktuell aber nicht.
Das ist auch kein "Muss", den Punkt hätte ich vielleicht deutlicher klarstellen können?

Hier trotzdem etwas OT der Hinweis, falls jemand da mit einsteigen will und z.B. auch die TTS-Ausgaben mit reinmischen:
@pldemon hat ein paar patches für Text2Speech geliefert, mit denen man z.B. gleich das Ausgabegerät mit angeben kann (die wurden ins svn übernommen). Er nutzt das u.A. auch dazu, gleich einen Player anzusteuern, der das per raop-sinks verteilt, siehe https://forum.fhem.de/index.php/topic,119278.msg1137044.html#msg1137044, aber die {options}-Methode sollte man z.B. auch dazu verwenden können, die vielen Text2Speech-Instanzen aus der OpenMultiroom-Darstellung im Wiki abzulösen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rcmcronny

Hi,

bisher paßt alles bei mir weiterhin.

Ne OpenMultiroom schau ich mir mal an, war klar für mich das es optional ist. War eine reine Info, das mein Feedback nur für snapcast.pm gilt :)

Ronny

chicco

Hallo Beta-User,

ich nutze das Modul seit 3 Monaten weil ich in meiner neuen Wohnung den Sound zwischen Küche und Wohnzimmer aufteilen muss. In der alten Wohnung war alles zentral in der Wohnküche.
Ich habe dann auch einen Fehler gefunden und habe den lokal bei mir gefixt. Jetzt wollte ich den Fix im alten Snapcast-Thread posten... und siehe da, du hast das Modul übernommen.

Fehlerbeschreibung:
Wenn man in der Snapcast-Android-App die Lautstärke von einer Gruppe ändert, crasht fhem.
Dann kommt ein Array von json-Strings (ein String für jeden Client in der Gruppe) im Modul an und wenn das dann decoded werden soll, kommt kein Hash dabei raus -> Fehlermeldung:
Not a HASH reference at ./FHEM/96_Snapcast.pm line 243

Ich nehme an, du willst den Fix in deine Version einbauen.
Was brauchst du von mir?
Meine geänderte Snapcast.pm?
Oder ein diff?

Deine Version habe ich noch nicht getestet. Will ich dann gerne machen, aber vielleicht ist es sinnvoller das zu tun wenn mein Fix eingebaut ist.

Und wenn das Modul jetzt wieder einen Maintainer hat, will ich doch gleich mal einen Feature-Request in die Runde werfen: Gruppensteuerung
Habe selbst schon mit dem Gedanken gespielt das anzugehen, aber noch nicht die Zeit gehabt so tief in das Modul einzusteigen  :-\

Gruß
chicco

Beta-User

#6
Moin,

dann mal willkommen an Bord!

Hatte gestern mittag noch eine Aktualisierung ins svn geschubst, bei der sieht die Zeile zumindest anders aus (jetzt: #233) - der Stand war der hier im Form vorab gepostete :) .

Also bitte einfach deine Version sicherheitshalber wegspeichern und ein normales update machen.

Hier gleich die nächste Iteration: gepackaged (sonst keine neue Funktionalität, kann aber sein, dass das eine oder andere Warning gefixt ist).
Da dabei (leider) auch was schief gehen kann, würde ich empfehlen, das vorab mal auf einen Testsystem auszutesten...

Die laufen bei mit auch auf dem Hauptsystem, aber ich bin leider noch etwas mit meiner neuen Hardware beschäftigt, da kommt via Snapcast im Moment leider nur "choppy sound" raus (geht 2x durch Pulseaudio).

Mit Gruppensteuerung habe ich mich daher noch nicht intensiver auseinandergesetzt, aber vielleicht schilderst du mal, was du genau erreichen willst und schaust dir auch OpenMultiroom man an - ich bin mir nämlich nicht sicher, ob das nicht bereits (indirekt) einige features enthält, die in diese Richtung gehen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#7
Zitat von: chicco am 09 Juli 2022, 20:00:43
Dann kommt ein Array von json-Strings (ein String für jeden Client in der Gruppe) im Modul an und wenn das dann decoded werden soll, kommt kein Hash dabei raus -> Fehlermeldung:
Not a HASH reference at ./FHEM/96_Snapcast.pm line 243

[...]
Was brauchst du von mir?
Meine geänderte Snapcast.pm?
Oder ein diff?
Nochmal zur Sicherheit: Was macht dein Fix? Verhindert er "nur" den crash? (dann sollte meine Variante schon reichen.) Oder wird das Array nacheinander ausgewertet?

Wenn letzteres: Bitte einfach anheften, was du "einfach" zur Verfügung stellen kannst, diff -u wäre super (gg. die svn-Version, die die Basis war (bitte auf jeden Fall mit nennen)). Ansonsten geht auch die Vollversion :) .

EDIT: Formatierung war irgendwie kaputt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

chicco

Hi,

ich habe das Array zerlegt und bin den Rest der Funktion dann in einer Schleife durch das Array gelaufen.
Wobei das mit der Schleife wahrscheinlich unnötig ist, denn wenn ich das richtig in Erinnerung habe, steigt die Funktion im ersten Schleifendurchlauf immer irgendwo mit einem "return ..." aus und der Rest der Schleife ist hinfällig. Das war dann aber egal weil auch immer ein Snapcast_getStatus() ausgelöst wird und dadurch alle Clients aktualisiert werden.

Ich hänge dir einfach mal meine beiden Snapcast-files an, einmal die originale und die von mir veränderte. Dazu ein diff -uw

Bei der Gruppensteuerung dachte ich an sowas wie
set SnapServer mute {groupname/groupid} true/false
oder
set SnapServer volume {groupname/groupid} xy

OpenMultiroom hatte ich damals bei der Snapcast-Einrichtung nur kurz angeschaut. Vielleicht schau ich das nochmal genauer an...

Gruß
chicco

Beta-User

OK, Danke!

Mein "Zwischenfix" war leider nicht ausreichend, um das Gruppenproblem zu umschiffen, ergänzter Code ist in Vorbereitung, muss aber erst getestet werden. Im Moment habe ich aber Zweifel, ob der bereits ausreicht, alle "batch"-Fälle sauber zu verarbeiten (zum Ganzen vgl. https://www.jsonrpc.org/specification#batch)

*Augenreib* - es ist wirklich verwunderlich, dass sich all die Jahre keiner wegen dieses Themas gemeldet hatte, oder übersehe ich was?!?



Bzgl. Gruppensteuerung bin ich am Sondieren, wie man das am Geschicktesten angeht. Das mit dem "Gruppenvolume" scheint gar nicht auf direkten Weg vorgesehen zu sein (siehe den Hinweis auf "batch" bei https://github.com/badaix/snapcast/blob/master/doc/json_rpc_api/control.md#requests-and-notifications) und auch danach bei "Requests" findet sich kein Gruppen-volume-set in dieser Doku...
Muss man wohl über eine Schleife erledigen, mal sehen :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

chicco

#10
Das mit dem json-batch habe ich gelesen, aber nicht ganz verstanden - kann es also nicht ganz beurteilen ob mein Fix alle batch-Fälle sauber verarbeitet.
Als ich den Fehler gefunden habe war ich auch verwundert, dass das noch niemand gemeldet hat - das Snapcast-Modul gibts ja immerhin schon ein paar Jahre...

Bzgl. Gruppenvolume habe ich mal geforscht wie das in Snapdroid und Snapweb gelöst ist.
Einmal hab ich das hier gefunden (bin mir aber nicht sicher ob das jetzt zu Snapdroid gehört):
https://github.com/badaix/snapcast/blob/master/control/setVolume.py
Da ist auf jeden Fall eine Schleife durch die Clients einer Gruppe und für jeden Client wird volume einzeln gesetzt.

Bei Snapweb hab ich das hier gefunden:
https://github.com/badaix/snapweb/blob/master/page/snapcontrol.ts
Da gibts Funktionen getGroupVolume() und setGroupVolume().
Bei get kann man sehen, dass die GroupVolume ein Mittelwert der einzelnen Clientvolumes ist.
Bei set ist auch wieder eine Schleife durch die einzelnen Clients und die einzelnen Clientvolumes werden prozentual relativ verändert.

An der Schleife führt wohl kein Weg vorbei...

Beta-User

#11
Puh,

(hoffentlich) ein gewisser Fortschritt...

Anbei vorab eine Aktualisierung. Die gute Nachricht:
FHEM scheint nicht mehr zu crashen, wenn man irgendwelche Gruppenaktionen an der Snapdroid-App ausführt. Allzu intensiv habe ich aber noch nicht getestet.

Die schlechten Nachrichten:
- Der Code ist aus vielerlei Gründen* ziemlich umgebaut;
- ich habe keine Ahnung, ob jetzt alles noch funktioniert wie vorher;
- Der Umbau ist noch nicht abgeschlossen**...

Tendiere aber wegen der crash-Prävention dazu, gleich den großen Schnitt zu machen und diese Version zeitnah einzuchecken, falls euch oder mir nicht noch was Schlimmes auffällt (was nicht direkt auch behoben werden könnte).

Zitat von: chicco am 13 Juli 2022, 00:03:13
Das mit dem json-batch habe ich gelesen, aber nicht ganz verstanden - kann es also nicht ganz beurteilen ob mein Fix alle batch-Fälle sauber verarbeitet.
Ganz verstanden habe ich das vermutlich auch noch nicht, denn das, was jetzt an vermeintlichen batch-volume-Anweisungen rausgeht, scheint nicht den Erwartungen des Snapcast-Servers zu entsprechen (**erster Punkt für Nacharbeit), obwohl keine direkte Rückmeldung zu kommen scheint (dafür aber eine auf Anweisungen von der App aus, die ausgeführt werden?)

Was dein Code macht, habe ich dann nicht im Detail untersucht, sondern einfach erst mal eine Vorrangbehandlung für decodierte*** Arrays reingebastelt. Ich bezweifle aber, dass die alle Fälle erfasst, und habe halt mal (inhaltlich nicht weiter im Detail auf Funktionalität geprüft) reingenommen, was ich "einfangen" konnte (=> ** Teil II)

Zitat
Als ich den Fehler gefunden habe war ich auch verwundert, dass das noch niemand gemeldet hat - das Snapcast-Modul gibts ja immerhin schon ein paar Jahre...
Die Verwunderung bleibt nicht an der Stelle stehen: Das Modul ist (bzw. *war) ausschließlich (?) auf IP-V4-Clients zugeschnitten, "id" war erst am Horizont angedeutet, und irgendwie bin ich auch nicht sicher, ob das Rückwärtsmatching mit mehreren Clients auf einer IP-Adresse je funktioniert hat. Jedenfalls hagelte es beim FHEM-Start eine Reihe von "mag ich nicht"-Meldungen wegen der Reading-Namen.

*Na jedenfalls beabsichtige ich, das ganze konsequent auf "id"-Bezüge umzustellen, so dass auch IP-V6-Clients korrekt adressiert werden.

ZitatBzgl. Gruppenvolume
Dazu habe ich jetzt mal eine Schleife + batch-Kommando gebaut, es funktioniert nur aus irgendwelchen Gründen noch nicht. Das versendete JSON selbst sieht für meine Augen ok aus.
Eine mögliche Ursache könnte sein, dass man alle clients aufführen muss, die in der Gruppe sind. Das klappt u.A. deswegen noch nicht, weil die Schleife bisher nur clients erfaßt, die es auch als FHEM-Devices gibt. (* die volume-Werte sind aber am Server-Device da, so dass der Bezugspunkt halt ggf. einfach geändert werden muss/kann).

***apropos JSON: das ist jetzt auch von decode_json/encode_json weg auf die "nicht-Zeichensatz-konvertierende" Variante. Scheint zumindest nicht schlechter zu funktionieren.

=> wie ihr seht, ist noch einiges zu tun, aber ein paar große weitere Schritte sind gemacht :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Beta-User am 14 Juli 2022, 13:22:52
Tendiere aber wegen der crash-Prävention dazu, gleich den großen Schnitt zu machen und diese Version zeitnah einzuchecken, falls euch oder mir nicht noch was Schlimmes auffällt (was nicht direkt auch behoben werden könnte).
done.

Habe gg. der Version von gestern noch eine etwas veränderte Gruppen-funktion versucht, leider (bisher) auch erfolglos...

Falls jemand eine Idee hat: her damit... Werde mir als nächstes jedenfalls nochmal die internen Referenzierungen vornehmen, aber das ist dann alles nicht mehr ganz so dringlich.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

So, die erste Gruppenfunktion funktioniert jetzt - man kann im "Zentralgerät" das volume der Gruppen setzen. Für absolute Kommandos wird eine virtuelle Lautstärke ermittelt und die als Referenz verwendet.

Ansonsten wundert mich etwas, dass es hier so still ist? Keine Probleme oder im Urlaub?!?

("Keine Probleme" interessiert mich auch, da waren doch einige größere Umstellungen drin und ich stochere bei manchem noch im Nebel...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rcmcronny

Moin,

hast Du es schon eingecheckt und kommt es mit dem Update oder muss man getrennt runterladen ?
Ich versuche das extra runterladen auf ein notwendiges Maß zu reduzieren und update dafür öfters (jeden Früh mache ich ein Check und lasse mir die Infos zukommen, da sehe ich dann ob es sinnvoll ist bzw was ich erwarten kann :D)

Für Snapcast mach ich aber eine Ausnahme, wenn es nötig ist :)

Achja, ansonsten rennt alles und ich bastel da eher im Herbst wieder rum wenn das Wetter schlechter wird. Aktuell ist eher genießen wie es läuft und nix ändern ,was was kaputt macht und man dann das Wetter nicht genießen kann :D

Ronny

Beta-User

Moin,

das kommt mit dem regulären update, da ich gg. der letzten Version keine neuen Probleme erwarte. Wenn es "kritischer" wäre, wäre es am 1. oder 2. Beitrag angepinnt.

Syntax für Gruppenvolume:
set <Snapcast-Server> volume <group-id> xy
Wobei xy eine Zahl zwischen 0 und 100 sein kann oder ein relativer (+7). Kann sein, dass up/down auch geht, soweit habe ich (noch) nicht getestet - war dann auch draußen 8) .

Doku folgt bei Gelegenheit, und ansonsten geht es mit der Entwicklung (abgesehen von eventuellen bugfixes) auch erst dann weiter, wenn's grade paßt (und ich eine Idee habe, was erreichbar sein könnte).... Jedenfalls gibt's jetzt Code, der die aktuellen Gruppenmitlieder(-ids) ermittelt, von daher kommen Gruppenumbenennung und addToGroup removeFromGroup als nächstes auf dem gedanklichen Zettel...

Genießt das Wetter!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tamash

Hi beta-user!

ich würde dein modul gerne nutzen/testen.

kannst du mir vielleicht nur kurz sagen auf welcher codebasis du weitergearbeitet hast?

LG
Tom

Beta-User

Hi tamash,

die aktuellste Modulfassung kommt mit dem regulären update, falls erforderlich kann ich dir auch sagen, wie man die ohne "alles andere" bekommt (was ich aber nicht empfehlen würde, weil es (ungeprüft) uU. Probleme geben könnte, wenn fhem.pl "zu alt" ist).

Was in dieser Version allerdings (noch) nicht (ordnungsgemäß) funktioniert, ist das Ändern einer Gruppenlautstärke; damit werden immer alle Clients angesprochen, nicht nur die in der Gruppe (es gibt aber keinen Absturz oder so). Ursache ist noch nicht ganz klar, ich tippe auf Encoding-Probleme.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tamash

#18
hi!

danke danke. nicht notwendig....wenn zieh ich deine version eh über ein normales update.
die frage war eher von welcher version du angefangen hast weg zu arbeiten. damals ergab sich ja leider ein recht hohe fragmentierung dieses moduls.

um etwas konkreter zu sein: ist zb. dieser PR https://github.com/1337sup3rh4x0r/fhemmodules/pull/3 mit in deiner version?

danke für deine mühe und LG
Tom

edit: change commit to PR

Beta-User

#19
 ;D na ja....

"Nicht direkt" wäre die "korrekte" Antwort 8) .

Zitat von: Beta-User am 14 Juli 2022, 13:22:52
*Na jedenfalls beabsichtige ich, das ganze konsequent auf "id"-Bezüge umzustellen, so dass auch IP-V6-Clients korrekt adressiert werden.
Falls ich keinen neuen Bug damit reingeknödelt habe, funktioniert das ganze jetzt noch 1-2 Stufen generischer ;) .  Das Ganze war aber einfacher zu realisieren, indem dann gleich ein ganzer Funktionsaufruf dahintergebastelt wurde, von daher ist der Code (nicht nur) an dieser Stelle kaum wiederzuerkennen...

Vielleicht prinzipiell ein paar Anmerkungen:
- Basis war die letzte svn-Version, die Rudi auf Bitten einiger User eingecheckt hatte. Das war afaik der Stand des genannten github-Repos per 03.08.2020, also vor genau 2 Jahren, wobei der letzte commit dahin nach "master" noch deutlich länger her ist. Von daher "müßte" eigentlich alles wesentliche drin gewesen sein.
- Die habe ich dann PBP-konform(er) umgebaut und dabei "weggeschossen", was mir so an "Problemchen" beim Testen über den Weg gelaufen ist. Dazu gehörten:
-- diverse Warnings und Meldungen aus fhem.pl wegen "unsauberer" Reading-Namen (die u.a. auch ihre Ursache in mehreren Snapclient-Instanzen auf einem System hatten ;) )
-- Abstürze wegen "Gruppenkommandos", wobei ich da nicht 1:1 die von chicco gezeigte Lösung übernommen habe, sondern den Code auch so umgestaltet, dass man ggf. den Funktionsaufruf für "Array-Rückmeldungen" auch so umbauen kann, dass der für "normale updates" auch paßt, mal schauen.

Wie dem auch sei: Es ist vermutlich der für alle schnellere Weg, eine Sicherheitskopie von der gerade verwendeten Modul-Fassung zu machen und dann die svn-Version (iVm. einem relativ aktuellen sonstigen FHEM) zu verwenden. Ich _glaube_, damit keine neuen Probleme für irgendjemanden zu generieren, aber wie immer liegt der Teufel im Detail...
Wichtig: wer noch irgendeine "Uralt-Version" rumfliegen hat, sollte FHEM nach dem Tausch der Module neu starten, sonst hagelt es im mindesten Falle einge warnings im Log.

Ansonsten: Alles vorab austesten kann ich leider nicht, schon alleine deswegen, weil ich noch keine besonders vertiefte Vorstellung davon habe, wer das wie nutzt. Ich gedenke aber eventuell auftretende echte Probleme asap zu fixen (was u.A. auch der Grund für den sehr schnellen commit ins svn war!). Bei neuen Funktionen kann es ggf. etwas länger dauern, bis ich mich da dransetze. Die Gruppenfunktion ist übrigens u.a. vermutlich auch deswegen etwas tricky zu fixen, weil ich das encoding der "originalen" id's möglichst nicht anfassen will...
Wenn dann irgendein "altbekanntes" (aber irgendwo schon gelöstes) Problem auftaucht, sollte es sich auch schnell integrieren lassen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tamash

wow! super! vielen dank für die ausführliche antwort.

alles klar. ich werd die version demnächst mal antesten und dich wissen lassen ob und wo ich in probleme laufe.

vielen dank nochmals.
LG

chicco

So, jetzt bin ich endlich mal dazu gekommen das Modul (und mein gesamtes fhem) zu updaten.

Aber im Modul ist irgendwie der Wurm drin  :(

Wenn ich in Snapweb/Snapdroid bei einem Client die Lautstärke ändere oder mute/unmute, kommt in fhem im Snapclient-device die Änderung mit einer Verzögerung von ca. 1-3 Minuten an. Oder die Änderung kommt gar nicht an.
Nur wenn ich in Snapdroid die Gruppenlautstärke ändere, kommen alle Änderungen sofort in den fhem-devices an. Vermutlich wird da ein Snapcast_getStatus() ausgelöst.

Wenn ich in fhem ein Snapclient-device mute/unmute setzen will, sehe ich in Snapweb/Snapdroid gar keine Änderung, egal wie lange ich warte. Auch im fhem-device wird der Wert nicht geändert, es scheint als würde der Befehl gar nicht ausgeführt. Im Logfile sehe ich keinen Fehler.
Wenn ich in fhem bei einem Snapclient-device die Lautstärke ändere, funzt es nur beim Wohnzimmer-Client, hier kommt die Änderung sofort in Snapweb/Snapdroid an. Bei allen anderen Clients passiert nichts, keine Änderung in Snapweb/Snapdroid und auch im fhem-device wird die Lautstärke nicht geändert. Ich wüsste jetzt nicht, dass der Wohnzimmer-Client irgendwie anders definiert ist als die restlichen Clients.

Immerhin funzt das setzen der Gruppenlautstärke aus fhem heraus. Hierbei werden die Clients dann auch automatisch unmuted, was mir aber eher nicht gefällt.
Schön wäre noch ein Gruppen-mute/unmute. Aber bitte nicht in der Form, dass per Schleife alle Clients gemuted/unmuted werden, sondern mehr so wie in Snapweb/Snapdroid, wo die Clients ihren eigenen mute-Status behalten wenn die Gruppe gemuted/unmmuted wird.
Hintergrund ist folgender: beim Wohnzimmer-Client habe ich das mute-reading per notify gekoppelt und schalte so automatisch den Verstärker ein/aus wenn der Client gemuted/unmuted wird. Der Verstärker hat beim einschalten aber immer eine Verzögerung von ca. 5 Sekunden. Auf die 5 Sekunden-Verzögerung würde ich gerne verzichten wenn man nur mal kurz die Mukke muten will und dann kurz darauf wieder unmuted.

Aber erstmal den Wurm aus dem Modul raus bekommen...
Ich bin dann mal zurück auf meine gesicherte snapcast.pm von vor dem Update  ;)

Gruß
chicco

Beta-User

Danke für die Rückmeldung.

Wird etwas dauern, bis es konkretere Antworten zu den einzelnen Punkten gibt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tamash

#23
Hi!

Ich hab mich nun auch etwas mit der offiziellen Version des Moduls beschäftigt.

Stoße auch auf mehrere Problem. Aber eins nach dem anderen.

1. Mute/Unmute Client in der form set SnapServerDevice mute <clientid> <true/false> muted immer. egal ob false oder true mitgegeben wird.

verbose 5 eines set mute false commands:
2022.10.21 14:58:42 5: snap: mute command received
2022.10.21 14:58:42 5: Snap: mute command received for 74d4351b2dbd
2022.10.21 14:58:42 5: Snap: group members for arg. 74d4351b2dbd are  within clients_1c697a01922d_group clients_e1495597-98f0-4a02-b24c-ffa0d7ba68df_group clients_b827ebbe36a3_group clients_489985a5-266f-4cd7-810e-f4c1cb39423a_group clients_00bb607ee181_group clients_1c697a01922d_2_group clients_b827ebcd1644_group clients_6f6a1cd0-fea4-46ce-a36b-c6687d0e1841_group clients_74d4351b2dbd_group clients_d1bc52c1-ff66-470c-901d-a2701aee6a41_group
2022.10.21 14:58:42 4: SNAP setClient: Tr.SnapcastServer, id 74d4351b2dbd, param mute, val false
2022.10.21 14:58:42 4: SNAP setClient still there: Tr.SnapcastServer, paramsetid 74:d4:35:1b:2d:bd
2022.10.21 14:58:42 5: DevIo_SimpleWrite Tr.SnapcastServer: {"params":{"volume":{"muted":true,"percent":100},"id":"74:d4:35:1b:2d:bd"},"method":"Client.SetVolume","id":47,"jsonrpc":"2.0"}

2022.10.21 14:58:42 4: Snapcast single line is: {"id":47,"jsonrpc":"2.0","result":{"volume":{"muted":true,"percent":100}}}
2022.10.21 14:58:42 5: client: 74d4351b2dbd, key: volume, value: Client.SetVolume


2. Mute/Unmute über Snapdroid spiegelt sich im _muted Status im FHEM nicht wieder
3. Auf meinem Test-Snapdroid Client lässt auch das Volume nicht ändern. Der zeigt sich aber überhaupt etwas seltsam im FHEM (MAC: 00:00:00:00:00)
Edit: zu 3.:
Das würde sich - auf den ersten Blick/auf die Schnelle - durch ersetzen der Zeile 857 mit

    if ( $client =~ m/^([0-9a-f]{12}([#_]*\d*|$))$/i or $client =~ /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i ) {

lösen lassen.

Für den Moment muss ich daher leider auf die alte Version zurück rollen.

Wäre super wenn du Zeit und Motivation findest da mal rein zu sehen.
LG
Tom

Beta-User

Sorry, dass das in meiner Prio-Liste etwas nach hinten gerutscht ist. Konkrete Vorschläge wie die von tamash helfen :) ...

Habe etwas an der regex zu Nr. 3 rumgefeilt und hoffentlich auch gefunden, warum das mit dem mute Client (Nr. 1) nicht so richtig wollte.

Muss das erst noch testen, aber dann sollte es wieder ein update geben, damit erst mal das raus ist.

Zu Nr. 2 bzw. der Verzögerung ganz allgemein habe ich noch keine Idee, vermutlich brauche ich eine Anleitung zum Nachstellen, falls es nicht (auch) mit der regex zu tun hat. Die dürfte bei IPV6-Clients helfen, wenn es also Unterschiede gibt zwischen einzelnen Geräten, kann es an der internen Adressierung (IP-V4 vs. IP-V6-Adresse) liegen.

Das "mute"-Verhalten finde ich insgesamt (historisch) seltsam gelöst und tendiere dazu, das mittelfristig (wieder) von der Lautstärke zu entkoppeln; für Gruppen muss ich mir da sowieso dann die Struktur der Daten dazu ansehen, ob man da was sieht/speichern kann (oder ein "toggle" an die Gruppe senden oä.).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

So, zumindest kurz angetestet - es scheint jedenfalls nicht schlechter zu funktionieren wie bisher, daher eingecheckt.

"mute" sollte sich jetzt wieder umstellen lassen, wobei ich das nur an den Client-Devices ausgetestet habe.

Was weiter dauert, ist die Aktualisierung, wenn man "extern" die Lautstärke ändert oder muted. Bin leider grade nicht allzu tief im Thema drin, gehe aber davon aus, dass wir keine "stehende Verbindung" haben, über die ggf. dann direkt eine Aktualisierung mitgeteilt wird, sondern (in relativ langen Abständen) halt pollen.
Ggf. müßte man über das Intervall (einstellbar) diskutieren, ich bin da aber für Vorschläge offen, falls jemandem was einfällt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tamash

Hi Beta-User!

Vielen Dank für die neue Version!

Mute/Unmute aus FHEM funktioniert jetzt wieder.
Die fehlende Aktualisierung der Readings bei externen mute/volume Änderungen kann ich auch beobachten.
Was noch nicht geht bei mir ist das steuern von Clients die die neue UUID ID haben (zb. 6f6a1cd0-fea4-46ce-a36b-c6687d0e1841). Also Punkt 3 aus meinem letzten Post.

LG
Tom

Beta-User

Zitat von: tamash am 31 Oktober 2022, 07:07:55
Was noch nicht geht bei mir ist das steuern von Clients die die neue UUID ID haben (zb. 6f6a1cd0-fea4-46ce-a36b-c6687d0e1841). Also Punkt 3 aus meinem letzten Post.
Ging das bei dir mit der Umstellung der regex (bzw. dem "or"-Zweig)? Dann habe ich da was "falsch optimiert"...
Leider hat bei meinem letzten Kurztest mein IP-V6-Client (das Handy) (unabhängig von FHEM) Probleme beim Abspielen eines streams gehabt, so dass ich den Teil nicht wirklich antesten konnte, und leider habe ich grade noch ein paar andere Baustellen, die für mich etwas höhrere Prio haben.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

chicco

Hallo,

Zitat von: tamash am 31 Oktober 2022, 07:07:55
Was noch nicht geht bei mir ist das steuern von Clients die die neue UUID ID haben (zb. 6f6a1cd0-fea4-46ce-a36b-c6687d0e1841). Also Punkt 3 aus meinem letzten Post.
Das geht bei mir auch nicht.
Weder in der Form

set SnapServer volume <id-handy> xy
set SnapServer mute <id-handy> true/false

noch in der Form

set SnapClientHandy volume xy
set SnapClientHandy mute true/false

Bei mir haben die Snapdroid-Clients in fhem übrigens eine MAC.

Zur fehlenden Aktualisierung der Readings bei externen mute/volume Änderungen, @Beta-User:
Bei der alten Modul-Version (also bevor du übernommen hast) wurde bei einer externen Änderung immer die Methode Snapcast_Read() ausgeführt, hier wurde im unteren Bereich dann immer Snapcast_updateClient() aufgerufen und dort wird letztendlich Snapcast_getStatus() aufgerufen, dadurch wurden die Readings aktualisiert.

Habe dein Modul ein bisschen debugged.
In Read() habe ich 2 Logmeldungen eingebaut:

        if ( $update->{method} =~ m{\AClient\.}x ) {
            Log3( $name, 4, "calling updateClient()" );
            Log3( $name, 4, "s: $s" );
            updateClient( $hash, $s, 0 );
            return;
        }

Für $s wird im Log nichts ausgegeben.

In updateClient() habe ich auch 2 Logmeldungen eingebaut:

sub updateClient {
    my $hash    = shift // return;
    Log3( $hash->{NAME}, 4, "executing 1 updateClient()" );
    my $c       = shift // return;
    Log3( $hash->{NAME}, 4, "executing 2 updateClient()" );

executing 1 wird im Log ausgegeben, executing 2 nicht.
Da steigst du direkt im Kopf der Methode per return aus.
Warum $s in Read() leer/undef ist, habe ich nicht weiter untersucht, dazu fehlt mir der Überblick über das Modul. Ich denke, da solltest du ansetzen...

Gruß
chicco

Beta-User

#29
Vorab mal Danke für die Analyse.

Muss mir den Datenfluss auch nochmal zu Gemüte führen, aber "eigentlich" ist in den genannten Methoden - jedenfalls soweit bei oberflächlicher Betrachtung erkennbar - gar nichts relevantes geändert, und dass der Code "nach hinten" dann aussteigt, wenn es keinen zu analysierenden content gibt (es sollte ein Hash sein bzw. die Referenz auf einen solchen), ist m.E. auch (formal) korrekt nicht das eigentliche Problem.

Was im Modul allerdings zwischenzeitlich ja grundsätzlich geändert ist, ist die Referenzierung auf die Id statt der IP-Adresse. Und in dem Zusammenhang ist mir Zeile 470 ins Auge gestochen: Das Löschen (das stand schon immer da!) macht jedenfalls im Moment für mich keinen allzu großen Sinn, sondern zerstört nur diese einzige (!) eindeutige Zuordnungsmöglichkeit und könnte daher eben auch in der Folge für Probleme sorgen, weil das erst wieder aufgebaut werden muss...

Falls jemand Muße zum Testen hat: Bitte diese Zeile 470 einfach mal Auskommentieren (# davor).

EDIT: Das gestrichene war Unfug...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tamash

Zitat von: Beta-User am 03 November 2022, 14:08:10
Ging das bei dir mit der Umstellung der regex (bzw. dem "or"-Zweig)? Dann habe ich da was "falsch optimiert"...
Leider hat bei meinem letzten Kurztest mein IP-V6-Client (das Handy) (unabhängig von FHEM) Probleme beim Abspielen eines streams gehabt, so dass ich den Teil nicht wirklich antesten konnte, und leider habe ich grade noch ein paar andere Baustellen, die für mich etwas höhrere Prio haben.

Erstmal sorry für die extrem späte Antwort.
Leider muss ich die Frage etwas umständlicher beantworten als mir lieb ist :)

Benutzte ich die selbe 'if (regex1) or (regex2)' zeile einfach in Snapcast_getId() in deiner Modulversion ändert das für mich nichts. (funktioniert also nicht)
Verwende ich sie hingegen in meiner (alten) Version (github) dann funktioniert auf Clients mit neuer ID alles wie auf Clients mit alter ID.

:(

Beta-User

Kannst du das mal mit der aktuellen Version versuchen und verbose auf 4 setzen? (Vermutlich sollte das an der zentralen Snapcast-Instanz sein).

Dann sollte zumindest mal im Logfile klarer stehen, welche ID da ermittelt wird.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rspecht

Hallo Zusammen,

ich versuche grade Hydraplay mit FHEM zu verheiraten. Dazu stehe ich nun am Problem damit Streams änderbar sind und Volumes nicht.

Ändere ich einen Stream (z.B. mit set SystemAudioSnapcastServer stream OrangeAudio1A MOPIDY-1) eines Clients kommt folgendes ins LOG:
2023.01.12 17:03:14 2: client: 3cdfef5c-bcee-8301-5025-71461c325cde
2023.01.12 17:03:14 2: key: stream
2023.01.12 17:03:14 2: value: Group.SetStream


Mache ich genau das gleiche für Volume ( set SystemAudioSnapcastServer volume OrangeAudio1A 90) passiert nichts mit folgender Meldung:
2023.01.12 17:03:24 2: client: unknown client
2023.01.12 17:03:24 2: key: volume
2023.01.12 17:03:24 2: value: Client.SetVolume


Andersrum gehts direkt. Ändere ich im Hydraplay die Lautstärke dann bewegt sich der Slider im FHEM instantan mit.

Meine Servermodul:
defmod SystemAudioSnapcastServer Snapcast 192.168.0.198 1705
attr SystemAudioSnapcastServer room Audio,System
attr SystemAudioSnapcastServer verbose 4
attr SystemAudioSnapcastServer volumeStepSize 5

setstate SystemAudioSnapcastServer opened
setstate SystemAudioSnapcastServer 2023-01-12 17:23:45 clients 5
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_group 3cdfef5c-bcee-8301-5025-71461c325cde
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_id OrangeAudio1A
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_ip 192.168.0.76
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_latency 0
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_mac 02:42:6d:9f:60:03
setstate SystemAudioSnapcastServer 2023-01-12 15:18:59 clients_OrangeAudio1A_module SystemAudioSnapcastOrange1E
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_muted false
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_name OrangeAudio1
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_nr 1
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_online true
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1A_origid OrangeAudio1A
setstate SystemAudioSnapcastServer 2023-01-12 17:19:28 clients_OrangeAudio1A_stream_id MOPIDY-0
setstate SystemAudioSnapcastServer 2023-01-12 16:53:55 clients_OrangeAudio1A_volume 48
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_group 853de234-455d-6f8a-5bf5-11708abb4096
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_id OrangeAudio1B
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_ip 192.168.0.76
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_latency 0
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_mac 02:42:6d:9f:60:03
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_muted false
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_name OrangeAudio1
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_nr 2
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_online true
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1B_origid OrangeAudio1B
setstate SystemAudioSnapcastServer 2023-01-12 16:50:46 clients_OrangeAudio1B_stream_id MOPIDY-0
setstate SystemAudioSnapcastServer 2023-01-12 16:53:41 clients_OrangeAudio1B_volume 100
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_group 20210aef-f7d3-e48d-35d9-03ae5996f2b7
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_id OrangeAudio1C
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_ip 192.168.0.76
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_latency 0
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_mac 02:42:6d:9f:60:03
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_muted false
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_name OrangeAudio1
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_nr 4
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_online true
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1C_origid OrangeAudio1C
setstate SystemAudioSnapcastServer 2023-01-12 16:50:47 clients_OrangeAudio1C_stream_id MOPIDY-0
setstate SystemAudioSnapcastServer 2023-01-12 16:53:32 clients_OrangeAudio1C_volume 41
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_group 577e5ac2-0934-eb04-7ff5-8bb7e8efdb84
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_id OrangeAudio1D
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_ip 192.168.0.76
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_latency 0
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_mac 02:42:6d:9f:60:03
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_muted false
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_name OrangeAudio1
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_nr 3
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_online true
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_OrangeAudio1D_origid OrangeAudio1D
setstate SystemAudioSnapcastServer 2023-01-12 16:50:48 clients_OrangeAudio1D_stream_id MOPIDY-0
setstate SystemAudioSnapcastServer 2023-01-12 16:53:54 clients_OrangeAudio1D_volume 100
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_group 730a1686-75b9-c32f-07cc-91eb200e0d09
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_id b827eb3d0493
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_ip 192.168.0.59
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_latency 0
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_mac b8:27:eb:3d:04:93
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_muted false
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_name raspisnd1
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_nr 5
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_online true
setstate SystemAudioSnapcastServer 2023-01-12 14:44:46 clients_b827eb3d0493_origid b8:27:eb:3d:04:93
setstate SystemAudioSnapcastServer 2023-01-12 15:17:41 clients_b827eb3d0493_stream_id MOPIDY-0
setstate SystemAudioSnapcastServer 2023-01-12 16:51:26 clients_b827eb3d0493_volume 50
setstate SystemAudioSnapcastServer 2023-01-12 14:44:47 streams 4
setstate SystemAudioSnapcastServer 2023-01-12 14:44:47 streams_1_id MOPIDY-0
setstate SystemAudioSnapcastServer 2023-01-12 14:44:50 streams_1_status playing
setstate SystemAudioSnapcastServer 2023-01-12 14:44:47 streams_2_id MOPIDY-1
setstate SystemAudioSnapcastServer 2023-01-12 14:44:47 streams_2_status idle
setstate SystemAudioSnapcastServer 2023-01-12 14:44:47 streams_3_id BLUETOOTH-0
setstate SystemAudioSnapcastServer 2023-01-12 14:44:47 streams_3_status idle
setstate SystemAudioSnapcastServer 2023-01-12 14:44:47 streams_4_id BLUETOOTH2-1
setstate SystemAudioSnapcastServer 2023-01-12 14:44:47 streams_4_status idle


Einer der Clients:
defmod SystemAudioSnapcastOrange1A Snapcast client SystemAudioSnapcastServer OrangeAudio1A
attr SystemAudioSnapcastOrange1A alias Desktop
attr SystemAudioSnapcastOrange1A room Audio,System
attr SystemAudioSnapcastOrange1A volumeStepSize 5
attr SystemAudioSnapcastOrange1A volumeStepSizeSmall 1
attr SystemAudioSnapcastOrange1A volumeStepSizeThreshold 5
attr SystemAudioSnapcastOrange1A webCmd volume:stream
attr SystemAudioSnapcastOrange1A widgetOverride volume:slider,0,1,100,1 stream:select,MOPIDY-0,MOPIDY-1

setstate SystemAudioSnapcastOrange1A defined
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:15 group 3cdfef5c-bcee-8301-5025-71461c325cde
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:15 id OrangeAudio1A
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:15 ip 192.168.0.76
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:15 latency 0
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:15 mac 02:42:6d:9f:60:03
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:15 muted false
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:15 name OrangeAudio1
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:15 online true
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:15 origid OrangeAudio1A
setstate SystemAudioSnapcastOrange1A 2023-01-12 15:19:14 state defined
setstate SystemAudioSnapcastOrange1A 2023-01-12 17:19:28 stream_id MOPIDY-0
setstate SystemAudioSnapcastOrange1A 2023-01-12 16:53:55 volume 48

Beta-User

Wird leider etwas dauern, bis ich mich kümmern kann/werde. (Schon klar, dass ich das hier schon ein paar Mal verlautbart habe, aber ist im Moment halt leider so, Snapcast ist aber nicht vergessen...!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rspecht

#34
Ich hab nun in 96_Snapcast.pm beim sub Snapcast_Encode folgendes vor dem return eignefügt:
  if(!($method eq "Server.GetStatus")) {
Log3 $name,4, "Snapcast_Encode returns now: $json";
  }


Dadurch kann ich wenigstens etwas debuggen...
Funktioniert nicht: set SystemAudioSnapcastOrange1B volume 10
4: Snapcast_Encode returns now: {"jsonrpc":"2.0","params":{"volume":{"percent":10,"muted":false},"id":"unknown client"},"id":2049,"method":"Client.SetVolume"}

Funktioniert: set SystemAudioSnapcastOrange1B stream MOPIDY-1
4: Snapcast_Encode returns now: {"jsonrpc":"2.0","params":{"id":"853de234-455d-6f8a-5bf5-11708abb4096","stream_id":"MOPIDY-1"},"id":1332,"method":"Group.SetStream"}

Zum einen sehe ich damit beim Stream auf "Group" umgemappt wird. Zum anderen geht was mit den Client IDs schief. Das ummappen soll ja so sein - wieso?
Bei der Clientid müsste ich mal bei der Encode Funktion (encode_json) durchsteigen... evtl. hab ich heute Abend wieder Zeit. Mit Kids und Job ist das doch schwierig :)

ein paar weitere Debugmeldungen hätt ich noch - wenn es in Snapcast set Client geht passt noch alles:
4: Snapcast_setClient called: Hash: HASH(0x4cb8680) - ID: OrangeAudio1B - Param: volume - Value: 10 - Name: SystemAudioSnapcastServer - Method Client.SetVolume - Paramset: HASH(0x5b219c0) - Cnummer: 1
4: Snapcast_setClient called: Hash: HASH(0x4cb8680) - ID: OrangeAudio1B - Param: stream - Value: MOPIDY-1 - Name: SystemAudioSnapcastServer - Method Group.SetStream - Paramset: HASH(0x7ebe0a8) - Cnummer: 2


Edit:
in  sub Snapcast_setClient($$$$) bei Zeile $paramset->{id} = Snapcast_getId($hash,$id); liegt wohl der Fehler...
Wenn ich in Snapcast_getID() die Abfrage if($client=~/^([0-9a-f]{12}(\#*\d*|$))$/i) auskommentiere rennt alles. Was hat man sich da gedacht?


sub Snapcast_getId($$){
  my ($hash,$client) = @_;
  my $name = $hash->{NAME};
  Log3 $name,4, "Snapcast_getId: $name - Client: $client";
  #for test... if($client=~/^([0-9a-f]{12}(\#*\d*|$))$/i){ # client is  ID
Log3 $name,4, "Client is ID";
    for(my $i=1;$i<=ReadingsVal($name,"clients",1);$i++){
      if ($client eq $hash->{STATUS}->{clients}->{"$i"}->{id}) {
        return $hash->{STATUS}->{clients}->{"$i"}->{origid};
      }
    }
  #}
  Log3 $name,4, "Client is no ID!";
  return "unknown client";
}


Grüße

Beta-User

Bin maximal verwirrt...

Zum einen ist das anscheinend nicht die aktuelle Version aus dem svn, die rspecht da verwendet hat.

Zum anderen werden da "nicht-technische" Kenner verwendet, sowas wie "OrangeAudio1B" habe ich bisher bei mir nicht, nur die ID's die die Server-Instanz automatisch zeigt (also sowas wie "84a93e695051_2" oder "7abfe1b9-659e-4448-8de7-647c6404de37").

Damit klappt auch das Ändern per volume-Setter sowohl an der Client-Instanz wie auch am Gerät selbst, sogar dann, wenn dafür gar keine Snapclient-Instanz in FHEM exisitert...

Vielleicht müssen wir mal über Konventionen reden, ich habe wohl was verpaßt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files