UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[hsteinme]

Eine Playlist lösche ich derzeit über

setState( 'xxx.cmdGeneral') , '"playlist", "clear"');

Kann es sein, dass ich eine bessere/schönere/andere/... Möglichkeit übersehen habe?

[OliverIO]

@hsteinme ne aktuell nicht. das ist der richtige Befehl.
Die Anzeige der Playlist habe ich mal begonnen, aber aktuell nicht fortgesetzt,
da ich das vom Template nicht so flexibel hin bekomme, das jemand sein eigenes Design da drauf legen kann.

[hsteinme]

@OliverIO
Okay, danke!

[killroy2]

@OliverIO
Bei 15+1 hast du doch auch ungerade Werte.
Kannst du die Rückmeldung nicht so berechnen wie das Kommando hin?
Also die Anzahl der anzuzeigenden Segmente ist das ganzzahlige oder gerundete Ergebnis der Fliesspunktberechnung:
Rückmeldung / ( 100 / (N_Segmente -1) )

Bei mehr als 100 Segmenten gibt es ein Problem, das wird korrekt von der Gui ausgeschlossen.

[OliverIO]

15+1 stimmt, auch keine geraden Werte
Das Problem ist, das der lms immer die Werte nach dem Komma abschneidet und dadurch bei hin und zurück nicht die gleichen Werte ankommen. Jetzt könnte man natürlich die Segmente passend mit unterschiedlichen Höhen darstellen, aber das sieht auch hässlich aus.

Ich könnte hier mal die verschiedenen Formeln aufschreiben, evtl. finden wir noch eine andere Lösung.

[killroy2]

Du kannst den Wert zum LMS selber runden und sicherstellen dass die Anzeige mit dem Wert die gleiche bleibt. Sollte nicht so kompliziert sein.

[OliverIO]

@killroy2 ob ich runde oder der lms es für mich macht ist eigentlich egal.
Das runden führt aber dazu, das auf Basis des zurück gemeldeten Wertes nicht mehr auf das Segment schließen kann, was eigentlich geklickt wurde.
das siehst du in der kleinen Excel, die ich oben eingeblendet habe.
Bei deinen Einstellungen ergibt ein Klick auf des 2 Segment einen Lautstärkepegel von 28,5714%
Durch die Rundung werden daraus dann 28% glatt.
Bei der Berechnung, was da leuchtet, ergeben aber 28% glatt nicht 2 sondern 1,96.
Hier könnte ich nun auch runden, aber ich habe noch nicht getestet, ob das für alle Fälle auch stimmt.
Parallel habe ich heute noch eine 2 Berechnungsmethode eingebaut, die aber auch wieder ihre Vor- und Nachteile hat.

[hsteinme]

@hsteinme sagte in Test Adapter SqueezeboxRPC v0.8.x Latest:

Wenn jemand das Badezimmer betritt, wird zufallsgesteuert eine Zufallsplaylist oder ein Favorit (= Radiosender) auf der Badezimmer-Squeezebox gestartet.

Meine Migration dieses Programms auf den ioBroker und den Squeezebox RPC Adapter ging "rasend schnell" - im Vergleich zu meiner früheren Implementation über die tcp/ip Command Line Schnittstelle. Den wesentlichsten Zeitgewinn brachte dabei - wie früher schon vermutet - der durch den Adapter gegebene bequeme Weg, den Favoriten-Baum zu durchwandern. Dafür sei dem Adapter-Autor nochmals herzlich gedankt.

Die Stromversorgung meiner Squeezebox Duet im Bad hängt an der Stromversorgung der Beleuchtung. Wird die Beleuchtung eingeschaltet, fährt die Squeezebox hoch und verbindet sich zum LMS. Das Zustandekommen der Verbindung wird durch einen geänderten Eintrag in squeezeboxrpc.0.Players.xxxx.Connected dokumentiert. Diesen Wechsel frage ich ab und starte zufallsgesteuert die Musikausgabe. Zu diesem Wechsel sind mir zwei Punkte aufgefallen:

• Es dauert lange, bis der Connected-Status aktualisiert wird, zuweilen bis zu 30 Sekunden. Kann ich durch Drehen an einem der Werte in den Timer-Settings der Konfiguration hierauf positiven Einfluss nehmen?

• Es kommt leider gelegentlich vor, dass trotz bestromter Squeezebox der Connected-Status nicht aktualisiert wird (gefühlt 10-15% der Einschaltvorgänge). In meinem Programm sehe ich hier keine Möglichkeit der Einflussnahme. Siehst Du, OliverIO, noch interne Stellschrauben im Adapter, die dieses Problem zumindest entschärfen könnten?

[OliverIO]

@hsteinme
Habe das gerade bei mir getestet.
Wenn der Player nur kurz disconnected ist, dann ist der Reconnect innerhalb ca 10 Sekunden wieder da.
Wenn der Adapter allerdings merkt, das der Player vom LMS offiziell als Disconnected geführt wird, dann werden alle Pollingabfragen gestoppt und erst die Regelmäßige Serverabfrage, die alle 30 Sekunden läuft, reaktiviert den Client im Adapter wieder.
Die 30 Sekunden kannst du in den Instanzsettings unter Timer-Settings / Serverrefresh (sec) default: 30 anpassen.
Auf meiner Todo-Liste habe ich noch eine Verbesserung stehen, die für bestimmte Ereignisse das Polling verbessert, in dem der LMS einen dann zeitnah aktiv informiert, wenn so etwas passiert. So könnte man das Polling bzw. den dadurch anfallenden Netzverkehr verbessern.
Allerdings sind dann wieder zusätzliche node-module notwendig, die den Speicherverbrauch weiter erhöht.
Bei mir laufen die Clients alle rund um die Uhr, von daher reichen bei mir die 30 Sekunden.

Aktiviere mal mittels dem History-Adapter auf dem Connected-Datenpunkt die Historie, dann siehst du genau, wann sich da etwas verändert und vergleiche den Zustand mit der Anzeige in der LMS-Gui im Dropdown oben rechts.

Allerdings reagiert die Gui-Aktualisierung im LMS etwas träger wie tatsächlich die Datenpunkt aktualisierung. Aber du siehst, ob der LMS den Client erkennt und mein Adapter nicht. Dann müssten wir da mal tiefer reinschauen

[OliverIO]

@killroy2 So die 0.8.26
ist draussen. Mit den erfolgten Anpassungen habe ich nun eine diverse Anzahl von Segmenten erfolgreich getestet. Weiterhin habe ich einen neuen Berechnungsmodus eingeführt (segstep=bisher, exact=neu). Details dazu befinden sich in der widget-Dokumentation zu volumebar

[killroy2]

@OliverIO said in Test Adapter SqueezeboxRPC v0.8.x Latest:

Bei deinen Einstellungen ergibt ein Klick auf des 2 Segment einen Lautstärkepegel von 28,5714%
Durch die Rundung werden daraus dann 28% glatt.
Bei der Berechnung, was da leuchtet, ergeben aber 28% glatt nicht 2 sondern 1,96.
Hier könnte ich nun auch runden, aber ich habe noch nicht getestet, ob das für alle Fälle auch stimmt.
Parallel habe ich heute noch eine 2 Berechnungsmethode eingebaut, die aber auch wieder ihre Vor- und Nachteile hat.

Wenn ich einen Wert 0.5 für Volume eingebe, rundet er auf.

Bekannt ist:
round ( 1/7 * anzuzeigendeBalken) ist gleich exakt dem Rückgabewert.

Statt über die Anzahl der Balken zu iterieren kann man die Suche um exakt berechneten Wert (1,2) beschränken.

[OliverIO]

@killroy2 welcher exakt berechnete Wert. Der einzige Kommunikationsweg zwischen Klick und Darstellung der Anzeige ist der Lautstärkewert,
und dieser wird nicht exakt weitergegeben

[killroy2]

In deinem Beispiel die 1,96

[killroy2]

Ich habe jetzt die 0.8.26 installiert. Per Default werden mir 10 Balken angeboten, das zeigt, das Update ist angekommen. Jetzt geht aber nichts mehr, der Balken ist immer dunkel.

[OliverIO]

@killroy2 said in Test Adapter SqueezeboxRPC v0.8.x Latest:

Ich habe jetzt die 0.8.26 installiert. Per Default werden mir 10 Balken angeboten, das zeigt, das Update ist angekommen. Jetzt geht aber nichts mehr, der Balken ist immer dunkel.

schau mal, ob in calctype was drin steht, ansonsten wähle dort segstep aus.

[killroy2]

hat gefehlt, damit funktioniert es.

[OliverIO]

@killroy2 ok, sehr gut. habe gerade noch eine initialisierung ergänzt, damit der volumebar nahtlos auch bei den anderen funktioniert, die ihn schon verwendet haben

[hsteinme]

@OliverIO: Danke für Deine ausführliche Rückmeldung.

Wenn der Player nur kurz disconnected ist, dann ist der Reconnect innerhalb ca 10 Sekunden wieder da. Wenn der Adapter allerdings merkt, das der Player vom LMS offiziell als Disconnected geführt wird, dann werden alle Pollingabfragen gestoppt ...

Ja, so steht es auch in der Command Line Interface Dokumentation:

• A new client is notified using "client new". "client disconnect" is sent when a client disconnects. Unless it reconnects (as signaled by "client reconnect") before a number of minutes, the client will be automatically forgotten by the server (as indicated by command/notification "client forget".)

Die Logs meiner Vorgängeranwendung sagen, dass genau 5 Minuten nach einem "client disconnect" der LMS den Zustand "client forget" ausruft. In der Zwischenzeit ankommende Verbindungen werden als "client reconnect" behandelt. Nach diesem Zeitpunkt kommende Verbindungen gelten als "client new".

... und erst die Regelmäßige Serverabfrage, die alle 30 Sekunden läuft, reaktiviert den Client im Adapter wieder.
Die 30 Sekunden kannst du in den Instanzsettings unter Timer-Settings / Serverrefresh (sec) default: 30 anpassen.

Diesen Parameter hatte ich heute Nachmittag schon auf 5 runter gedreht. Eine Verbesserung war für mich nicht erkennbar.

Auf meiner Todo-Liste habe ich noch eine Verbesserung stehen, die für bestimmte Ereignisse das Polling verbessert, in dem der LMS einen dann zeitnah aktiv informiert, wenn so etwas passiert.

D.h. der Adapter "sitzt seine Serverrefresh-Zeit vollständig ab" und fragt erst danach beim Server nach, ob es etwas Neues gibt. Er hat also in diesem Sinn keinen "Newsletter" des Servers abonniert. In meiner vorherigen Anwendung war dieser "Newsletter" über listen/subscribe Kommandos an den LMS bestellt, so dass die Anwendung zeitnah vom LMS bei z.B. neu ankommenden Verbindungen informiert wurde. Dies erklärt, warum sich beim Hochfahren des Clients in meiner neuen Anwendung die Wartezeit spürbar erhöht hat.

Aktiviere mal mittels dem History-Adapter auf dem Connected-Datenpunkt die Historie, dann siehst du genau, wann sich da etwas verändert und vergleiche den Zustand mit der Anzeige in der LMS-Gui im Dropdown oben rechts. [...] du siehst, ob der LMS den Client erkennt und mein Adapter nicht.

Guter Ansatz. Das werde ich in den nächsten Tagen mal angehen.

[OliverIO]

@hsteinme
ich schau mir zum einen die an ob es bei der server refresh zeit einen fehler gibt und dann bin gerade schon am schauen wie ich das mit telnet umgesetzt bekomme. das wird aber ein wenig dauern, da diese Woche schon ziemlich voll ist und ich ein wenig in Deutschland unterwegs bin.

[hsteinme]

Danke! Aber bitte keine Hektik: Die Hochfahr-Thematik gehört nicht zur Kategorie "lebensbedrohlich und dringend".