Test/Support Adapter SqueezeboxRPC

OliverIO

ja, musste ich leider.
Eigentlich sollte das schon länger (letztes Jahr?) so sein. War aber nicht an allen Stellen wirksam.
Problem ist mit in Datenpunkten nicht gültige Zeichen (letztes Jahr war es #, weiter oben war es []). Daher wandle ich alle nicht gültigen Zeichen nun in _ um.

Regex gegen welches validiert wird ist

/[^\d\w_]+/gm;

Ich muss dran denken, bei so grundsätzlichen Änderungen besser darauf hinzuweisen.

OliverIO

@aufschlagzuender sagte in Test/Support Adapter SqueezeboxRPC:

Ich habe keine VIS, bzw. verwende ich Jarvis als Visualisierung

Hast du dann den neuen sendTo Befehl zum Abruf der Playlist ausprobiert?

hsteinme

Ich habe ein Skript im Einsatz, das das Abspielen einer Squeezebox startet, sobald ein Präsenzmelder eine menschliche Anwesenheit meldet.

if presence reported {
	.Power = 1
	.cmdGeneral  = playlist clear
	.Volume = 70
	.cmdGeneral = randomplay 2
	.state = 1
}

Leider erreicht diese Routine nicht immer ihren Zweck. Meine eigenen Debug-Logs belegen, dass der Präsenzmelder korrekt meldet und dass die obige Routine korrekt durchlaufen wird - auch in den Fällen, wo die Squeezebox nicht startet.

Eine anschließend eingefügte Prüfroutine zeigt auf, dass die Musik nicht startet, wenn vom Adapter das AckFlag für .state nicht auf true gesetzt wird.

Daher meine Frage an Dich, Oliver: Welches Kriterium veranlasst den Adapter, das Ack-Flag zu setzen oder halt nicht zu setzen?

Eingesetzte Adapter-Version: 1.5.2

OliverIO

@hsteinme

so wie es eigentlich auch vorgesehen ist.
wenn du bspw den play/stop/pause datenpunkt mit der bezeichnung state beschreibst (mit ack=false),
dann wird zunächst intern der befehl an den LMS/Lyrion-Server abgesetzt.
Der Adapter pollt kontinuierlich den Status vom Server.
Hat dann LMS/Lyrion in seinen Meldungen selbst den Status verändert, dann wird über das Polling das registriert und der state-Datenpunkt aktualisiert, allerdings dann mit dem ack=true flag, da ja nun die Information vom Gerät bestätigt wurde.

Das Polling erfolgt in unterschiedlichen Datenzusammenstellungen in unterschiedlichen Zeitabständen.

Wenn du da ein Fehlverhalten feststellst, dann bitte hier nochmal schreiben. Der Playstatus sollte aber minimal jede Sekunde abgefragt werden.

hsteinme

@oliverio Danke, Oliver, für Dein schnelles Feedback.

Naja, ein Fehlverhalten liegt hier in jedem Fall vor. Zweck meiner gestrigen Anfrage war halt, festzustellen, ob der Adapter oder LMS hierfür verantwortlich ist. Nach Deiner obigen Erklärung sehe ich nun klar die Verantwortung bei LMS bzw. dem dahinter liegenden Squeeze Client.

Stellt meine o.e. Prüfroutine fest, dass kein Ack = true zurückgekommen ist, so wird .state mehrmals im Abstand einiger Sekunden erneut auf 1 gesetzt - jedoch bleibt dies auch ohne Erfolg.

Jetzt bin ich ziemlich ratlos, wie ich beim LMs (oder dahinter) das Problem weiter analysieren kann.

OliverIO

@hsteinme

Ich teste das mal

OliverIO

@hsteinme

ich habe mal getestet.
ich habe mit dem history adapter die aufzeichnung des datenpunkts state gestartet.
das kreuzchen für "Nur Änderungen aufzeichnen" habe ich deaktiviert, um evtl wiederholtes schreiben des datenpunkts mitzubekommen.
zunächst habe ich direkt in der LMS Oberfläche Play/Pause gedrückt. Das sind die Einträge ohne ack=false, da ja im iobroker nie was eingetragen worden ist, sondern der status direkt vom lms kommt
die nächsten paar einträge habe ich dann selbst manuell den datenpunkt state beschrieben, das sind dann die ack=false einträge, welches dann vom lms entsprechend bestätigt wurde und hier als ack=true sichtbar ist.

einen Eintrag kann ich mir allerdings nicht erklären ist der einzelne stop==2 Eintrag, den ich nicht selbst ausgelöst habe, sondern wahrscheinlich als Reaktion auf das zuvor angeforderte pause==0 Kommando. das trat aber nur das einzige mal auf, hat aber auf die nachfolgende Funktionalität keinen Einfluss.

timestamp	value	acknowledged
4/15/2025 3:20:46 PM.218	null	true
4/15/2025 3:21:11 PM.624	1	true
4/15/2025 3:21:24 PM.771	0	true
4/15/2025 3:21:36 PM.330	1	true
4/15/2025 3:21:43 PM.040	0	true
4/15/2025 3:22:18 PM.449	1	false
4/15/2025 3:22:18 PM.536	1	true
4/15/2025 3:22:33 PM.373	0	false
4/15/2025 3:22:33 PM.865	0	true
4/15/2025 3:22:40 PM.567	2	true
4/15/2025 3:23:04 PM.824	0	false
4/15/2025 3:23:21 PM.261	1	false
4/15/2025 3:23:21 PM.841	1	true
4/15/2025 3:23:42 PM.740	0	false
4/15/2025 3:23:42 PM.908	0	true
4/15/2025 3:24:08 PM.744	2	false
4/15/2025 3:24:09 PM.722	2	true
4/15/2025 3:24:21 PM.493	1	false
4/15/2025 3:24:22 PM.188	1	true
4/15/2025 3:24:31 PM.678	0	false
4/15/2025 3:24:31 PM.801	0	true

Aus meiner Sicht funktioniert hier alles ordnungsgemäß.
Evtl kannst du ebenfalls mit history das mal nachvollziehen?

hsteinme

@oliverio Danke für Dein Bemühen, Oliver!

Evtl kannst du ebenfalls mit history das mal nachvollziehen?

Das hatte ich letzte Woche auch schon getan - ohne neue Erkenntnisse.

Aus meiner Sicht funktioniert hier alles ordnungsgemäß.

Das sehe ich - seit Deiner Eläuterung hier - auch genau so.

OliverIO

@hsteinme

evtl mal zu deinem skript, kannst du das mal zeigen. das folgende ist ja wahrscheinlich nur pseudocode?
Evtl kann man da was optimieren, weil sich manche von der bedeutung überschneiden (power,randomplay,state, da würde einfach nur randomplay reichen)

randomplay ist wahrscheinlich falsch, da als nächster parameter nur einer der folgenden zulässig ist, kann aber durch plugins auch erweitert werden
tracks|albums|contributors|<wbr>year

auch playlist clear ist eigentlich nicht notwendig, weil wenn du direkt etwas anwählst ohne das du explizit sagst, das es der playlist hinzugefügt werden soll, die playlist geleert wird

if presence reported {
	.Power = 1
	.cmdGeneral  = playlist clear
	.Volume = 70
	.cmdGeneral = randomplay 2
	.state = 1
}

hsteinme

Aber gern doch:

/**************************************************************************
 * Reaktion auf Start-Signal für eine SqueezeBox
 **************************************************************************/
function BearbeiteStartSignal(SqBoxNr) {
    var Spiel;
    var Art;
    
    if(parScharfGeschaltet) {
        if(getState(MySqueezeBoxIds[SqBoxNr] + '.Pause').val == false) {
            setState(AccessKeys[SqBoxNr] + '.Power' , 1);
            Log(true, MySqueezeBoxes[SqBoxNr] + ': Power = 1');
            setState(AccessKeys[SqBoxNr] + '.cmdGeneral', '"playlist", "clear"');
            Log(true, MySqueezeBoxes[SqBoxNr] + ': playlist clear');
            setState(AccessKeys[SqBoxNr] + '.Volume', getState(MySqueezeBoxIds[SqBoxNr] + '.AnfangsLautstaerke').val);
            Log(true, MySqueezeBoxes[SqBoxNr] + ': Volume = ' + getState(MySqueezeBoxIds[SqBoxNr] + '.AnfangsLautstaerke').val);

            Art = parLosTopf[getRndInteger(0, parLosTopf.length - 1)]
            switch(Art) {
                case artFAVORITE:
                    Spiel = MyFavoriteIds[getRndInteger(0, MyFavoriteIds.length - 1)];
                    setState(AccessKeys[SqBoxNr] + '.cmdPlayFavorite', Spiel);
                    Log(false, MySqueezeBoxes[SqBoxNr] + ': Favorit-Id = ' + Spiel);
                    break;
                case artTRACKS:
                case artALBUMS:
                case artARTISTS:
                case artYEAR:
                    Spiel = '"randomplay", "' + ArtKommandos[Art] + '"';
                    setState(AccessKeys[SqBoxNr] + '.cmdGeneral', Spiel);
                    Log(true, MySqueezeBoxes[SqBoxNr] + ': ' + Spiel);
                    break;
            }

            setState(AccessKeys[SqBoxNr] + '.state', statePLAY);
            Log(true, MySqueezeBoxes[SqBoxNr] + ': play');

            for (var Count = 0; Count < 4; Count++) {
                setTimeout(CheckStateVolume, 3000 + Count * 1000, SqBoxNr);
            }
        }         
    }
}

Einige Erläuterungen:

parScharfGeschaltet regelt, ob überhaupt bei einer Präsenzmeldung Musik eingeschaltet werden soll oder nicht.
.Pause definiert (nächtliche) Pausenzeiten, zu denen der Präsenzmelder ignoriert werden soll.
Über parLosTopf wird "ausgelost", ob ein zufälliger Favorit (was bei mir immer ein Radiosender ist) oder eine nach Titel, Alben, Interpreten oder Jahren zufällig ausgesuchte Playlist gestartet wird.

/**************************************************************************
 * Ausgabe einer Art-Option für randomplay
 **************************************************************************/
function SetzeArtKommandos() {
    ArtKommandos[artTRACKS] = 'tracks';
    ArtKommandos[artALBUMS] = 'albums';
    ArtKommandos[artARTISTS] = 'contributors';
    ArtKommandos[artYEAR] = 'year';
}

CheckStateVolume überprüft, ob die angesteuerten .Volume und .state Anweisungen umgesetzt worden sind. Falls nicht, werden diese Anweisungen erneut losgeschickt.
Log(true, ...) nimmt nur dann einen Logeintrag vor, wenn ein skriptinternes Debug-Flag gesetzt ist.

OliverIO

Probier mal so
ich habe mal die doppelt gemoppelten Befehle (also play Befehle, welche die anderen bereits beinhalten) entfernt.

Ich bin jetzt da gerade nicht so firm. achte darauf, das du auf jedenfall von getState/setState immer nur die synchronen Versionen verwendest. Wenn asynchron ohne await garantiert nicht, das der Befehl dann schon fertig ist, wenn das die asynchronen versionen sind, dann noch await davor schreiben (und sobald in einer funktion await verwendet wird muss diese auch mit async versehen werden.)

Falls das Problem anhält, probier mal ein await sleep(1000) zwischen den setStates zu setzen.
die 1000 ist 1 Sekunde. Die Zeit kannst du auch noch variieren. Nicht das das schnell hintereinander setzen von States da irgendwas durcheinanderbringt im LMS. Aber das reduzieren der setStates hilft evtl auch schon.

@hsteinme sagte in Test/Support Adapter SqueezeboxRPC:

/**************************************************************************
 * Reaktion auf Start-Signal für eine SqueezeBox
 **************************************************************************/
function BearbeiteStartSignal(SqBoxNr) {
    var Spiel;
    var Art;
    
    if(parScharfGeschaltet) {
        if(getState(MySqueezeBoxIds[SqBoxNr] + '.Pause').val == false) {
            setState(AccessKeys[SqBoxNr] + '.Volume', getState(MySqueezeBoxIds[SqBoxNr] + '.AnfangsLautstaerke').val);
            Log(true, MySqueezeBoxes[SqBoxNr] + ': Volume = ' + getState(MySqueezeBoxIds[SqBoxNr] + '.AnfangsLautstaerke').val);
 
            Art = parLosTopf[getRndInteger(0, parLosTopf.length - 1)]
            switch(Art) {
                case artFAVORITE:
                    Spiel = MyFavoriteIds[getRndInteger(0, MyFavoriteIds.length - 1)];
                    setState(AccessKeys[SqBoxNr] + '.cmdPlayFavorite', Spiel);
                    Log(false, MySqueezeBoxes[SqBoxNr] + ': Favorit-Id = ' + Spiel);
                    break;
                case artTRACKS:
                case artALBUMS:
                case artARTISTS:
                case artYEAR:
                    Spiel = '"randomplay", "' + ArtKommandos[Art] + '"';
                    setState(AccessKeys[SqBoxNr] + '.cmdGeneral', Spiel);
                    Log(true, MySqueezeBoxes[SqBoxNr] + ': ' + Spiel);
                    break;
            }
  
            for (var Count = 0; Count < 4; Count++) {
                setTimeout(CheckStateVolume, 3000 + Count * 1000, SqBoxNr);
            }
        }         
    }
}

hsteinme

Danke, Oliver!

ich habe mal die doppelt gemoppelten Befehle (also play Befehle, welche die anderen bereits beinhalten) entfernt.

Das gehe ich mal am langen Wochenende an.

auf jedenfall von getState/setState immer nur die synchronen Versionen

Im Script kommen weder asyync noch await vor.

probier mal ein await sleep(1000) zwischen den setStates zu setzen

Das hatte ich mir auch schon überlegt und ebenfalls für das kommende Wochenende eingeplant.

Ich melde mich demnächst wieder.

hsteinme

@oliverio sagte in Test/Support Adapter SqueezeboxRPC:

ich habe mal die doppelt gemoppelten Befehle (also play Befehle, welche die anderen bereits beinhalten) entfernt.

Jau, Oliver, Deine Aufräumaktion ist der Bringer. Bei fast zwei Dutzend Testläufen gab's nur Erfolgserlebnisse. Auch hier sieht man's also mal wieder: Weniger kann mehr sein Ich hatte wohl mit meiner "Kommandoschwemme" den LMS ins Schwimmen gebracht.

Ich sage Dir nochmals ganz herzlichen Dank für Deine Unterstützung. Ich finde es toll, wie tief Du in die von mir geschilderte Problematik meines Skripts eingestiegen bist. Das was Du hier im Forum leistest - nicht nur in "Deinen" Adaptern, sondern auch in anderen Themen - ist schon phantastisch.

OliverIO

Neue Version 1.6.2

Neues Widget browser (aktuell nur alpha zum testen)
Behebung von Meldungen aus dem Adapter-Checker

In diesem Release ist ein neues widget enthalten:

Browser

Dies zeigt Musik, Alben, Interpreten, Radiosender, Apps usw. vom Server an. Durch Klick auf ein Element kann in der Hierarchie tiefer gegangen werden, durch Klick auf den Pfad ganz oben kann wieder höher gegangen werden.
Falls Verfügbar, sind für einzelne Elemente weitere Aktionen verfügbar (Play, Add Playlist,...)

Da die Implementierung auf Seiten des LMS/Lyrion-Servers zwar funktioniert, aber mit extrem vielen und undurchsichtigen Sonderfällen versehen ist, stand dieses widget sehr lange auf dem Plan.
Als technisches Vorbild stand das Material-Theme-Plugin für den LMS.
Da der LMS/Lyrion-Server aber mit Plugins erweiterbar ist, konnten alle Fälle berücksichtigt werden. Daher bitte ich euch das einmal durchzutesten. Insbesondere mit den Unterbereichen, wo ihr Plugins installiert habt.

Das widget ist aktuell mit erweiterten Debugging-Ausgaben ausgestattet. Für Tester diese beiden bitte in der widget Konfiguration aktivieren. Diese geben dann nochmal extra Informationen in der Browserkonsole (
F12) aus, die dann helfen, Fehler oder fehlende Implementierungen herauszufinden und zu ergänzen.

Wer mit testen möchte, dann bitte die Ergebnisse hier einfach im Thread hinterlassen. Auch Wünsche für weitere Funktionen bitte ebenfalls hier dokumentieren.

Folgendes ist aktuell noch nicht eingebaut:

Eingabefelder innerhalb der Hierarchie
Der Hauptmenüpunkt "Extras"

daPanic

Moin,

irgendwie stehe ich gerade auf dem Schlauch.
Ich habe auf dem Server, auf dem auch der IOBroker läuft meinen Lyrion Server laufen.
Alle meine Boxen (Squeezeboxen und Booms) laufen soweit.
Jetzt wollte ich das Player Widget testen und in der Doku steht ich soll es mit der Instanz verbinden. Wie mache ich das?
Ich kann ja nur auf Datenpunkte zugreifen.

OliverIO

@dapanic

ja korrekt.
wähle einen beliebigen datenpunkt aus der instanz aus.
der rest macht das widget und extrahiert dann die instanz aus dem datenpunkt

daPanic

Hm, was mache ich falsch?
Dieses Widget habe ich eingebunden.

Suche mir dann irgendwas aus dem Baum von einem Player.

Nehme mal das Attrubut "POWER". Übernehme es dann im Widget ins ainstance

Und hier würde ich jetzt irgendwas erwarten...

OliverIO

@dapanic

und was steht jetzt in aInstance?
Nach Auswahl von Power sollte sowas drin stehen.
Alternative einfach

squeezeboxrpc.0

direkt eintragen.

daPanic

@oliverio said in Test/Support Adapter SqueezeboxRPC:

squeezeboxrpc.0

Da steht dann
squeezeboxrpc.0.Players.Boom.Power

Habe mal squeezeboxrpc.0 eingestellt, aber das Feld bleibt weiterhin leer.
Gibt es eine Mindesgröße? Ich habe 350x350 eingestellt.

OliverIO

@dapanic

dann schaue bitte mal in die browserkonsole mit F12
nach Fehlermeldungen.

Es gibt keine Größenbeschränkung.

NEWS

Test/Support Adapter SqueezeboxRPC

Neue Version 1.6.2

Support us

875
Online

31.6k
Users

79.4k
Topics

1.3m
Posts

NEWS

Test/Support Adapter SqueezeboxRPC

Neue Version 1.6.2

Support us

875Online

31.6kUsers

79.4kTopics

1.3mPosts

875
Online

31.6k
Users

79.4k
Topics

1.3m
Posts