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

[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".

[OliverIO]

@hsteinme
Muss dich leider entäuschen :)
Die ersten Tests sind gerade erfolgreich abgeschlossen worden.
Connect und Reconnect werden adhoc registriert.

Aber dennoch noch nicht veröffentlichungsreif.
Da ich hier mit den Netzwerk-Sockets spiele muss ich erst ausführlich testen, das ich hier keine Speicherlecks rein bekommen.
Aber sieht generell gut aus.

[hsteinme]

:+1:

Dann werde ich die vereinbarten Vergleichsmessungen zur (Re)Connect-Erkennung erst mal sein lassen, da Du eh schon eine Lösung in der Hinterhand hast.

Wie gesagt:

die Reaktionsgeschwindigkeit und die Hilfsbereitschaft des Entwicklers im Forum haben mich sehr beeindruckt

[OliverIO]

@hsteinme
so in der Version 0.8.28 habe ich die Funktionalität eingebaut.
Das Server und die Playerobjekte werden nun aktualisiert, sobald signalisiert wird, das ein Player connected oder disconnected.
ggfs. musst du die Funktion erst in den Adapter Settings unter Reiter Performance aktivieren.

Bei mir hat es Funktioniert, da das bei andern nicht unbedingt der Fall sein muss (man kann nicht alle Fälle vorausdenken).
Bitte aktiviere zusätzlich noch in den Settings Reiter Debug Settings die Einstellung "Create debug output for server" und stelle nach Speichern der Konfiguration in der Instanzübersicht in der Expertendarstellung den Log-Level der Instanz auf "debug".
Dort solltest du dann einmal sehen, ob sich der Adapter mittels Telnet mit dem LNS verbindet.
Im Log sieht das dann wie folgt aus:

squeezeboxrpc.0	2020-01-09 00:21:34.576	debug	(16011) doTelnet recieved reconnect for : 00:27:00:be:00:b7
squeezeboxrpc.0	2020-01-09 00:21:02.032	debug	(16011) doTelnet recieved disconnect for : 00:27:00:be:00:b7
squeezeboxrpc.0	2020-01-09 00:20:13.265	debug	(16011) doTelnet connected to server!

Wenn Fehler auftauchen, dann bitte diese hier melden.

[hsteinme]

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

so in der Version 0.8.28 habe ich die Funktionalität eingebaut.

Danke schön für die schnelle Bereitstellung, OliverIO!

ggfs. musst du die Funktion erst in den Adapter Settings unter Reiter Performance aktivieren.

"ggfs."? In welchem gegebenen Fall?

"in den Adapter Settings"? Meinst Du die Instanzen Settings? Im dortigen Reiter performance settings sehe ich jedoch nur zwei altbekannte Optionen zu den Playlist-Infos und zu den anderen LMS Servern. Mehr ist bei mir nicht zu finden.

*Bitte aktiviere zusätzlich noch in den Settings Reiter Debug Settings die Einstellung "Create debug output for server" und stelle nach Speichern der Konfiguration in der Instanzübersicht in der Expertendarstellung den Log-Level der Instanz auf "debug".

Das habe ich getan.

Dort solltest du dann einmal sehen, ob sich der Adapter mittels Telnet mit dem LNS verbindet.
Im Log sieht das dann wie folgt aus:

Derartige Einträge sehe ich bei mir nicht, auch nicht nach einem stop/start von ioBroker.

[OliverIO]

@hsteinme
dann bitte auf der commandozeile folgenden befehl eingeben:

iobroker upload squeezeboxrpc

[OliverIO]

@OliverIO Alternativ bzw als erstes kannst du auch noch <strg> + <f5> auf der Konfigurationsseite machen, falls im browsercache noch die alte seite gespeichert ist