[Snapcast] - support Thread ab 2022

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

Vorheriges Thema - Nächstes Thema

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