Test/Support Adapter SqueezeboxRPC

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.

NEWS

Test/Support Adapter SqueezeboxRPC

Support us

1.0k
Online

31.5k
Users

79.2k
Topics

1.3m
Posts

NEWS

Test/Support Adapter SqueezeboxRPC

Support us

1.0kOnline

31.5kUsers

79.2kTopics

1.3mPosts

1.0k
Online

31.5k
Users

79.2k
Topics

1.3m
Posts