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

[hsteinme]

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

Hat jemand Lust mit mir zu besprechen, wobei man bei der Entwicklung der Playlist achten sollte, [...]
Stufe 1: Nur Anzeige

• Anzahl der Playlist-Items
• Positonsnummer des aktuellen Items

[OliverIO]

@hsteinme
hab mir das verhalten vom LMS nochmal angeschaut und folgendes ist mir aufgefallen.
Man darf nicht nur den Status Connected anschauen, sondern auch Power.
Den verwaltet der LMS unabhängig voneinander, so dass
Ein Gerät aus sein kann (power=0), aber dennoch noch connected (connected=1)
Für den LMS kann erstaunlicherweise ein Gerät auch nicht connected (connected = 0) sein und dennoch an (power=1). Das habe ich im adapter aber korrigiert.

Für dein Skript musst du nach dem Status Power schauen. folgende Zustände können nun vorkommen

power=0,connected=0; gerät nicht verfügbar
power=1,connected=0; kann nicht mehr in iobroker vorkommen, LMS kennt das aber noch
Power=0,connected=1; player ist mit LMS verbunden, aber Soft ausgeschaltet
Power=1,connected=1, player verbunden und eingeschaltet

Da ich Power bei der Ereignissignalisierung noch nicht berücksichtigt hatte, habe ich das nun ergänzt, sowie die oben erwähnte Korrektur eingearbeitet.
Damit man sieht was sonst noch über die Ereignissteuerung läuft, werden alle eingehenden Daten nun im Debug-Level ausgegeben.
Dies steht nun in Version 0.8.29 zur Verfügung.

[hsteinme]

@OliverIO: Heißen Dank für die wieder mal schnelle Diagnose und Lösungsbereitstellung.

Zwei Logs aus meiner früheren Anwendung:

Rec 22.12.2019 07:58:17 Data Received (47/47):
                        xx:xx:xx:xx:ca:58 client disconnect
Rec 22.12.2019 08:03:17 Data Received (43/43):
                        xx:xx:xx:xx:ca:58 client forget
Rec 22.12.2019 08:03:17 Data Received (43/83):
                        xx:xx:xx:xx:ca:58 playlist stop
Rec 22.12.2019 08:14:35 Data Received (40/40):
                        xx:xx:xx:xx:ca:58 client new

Wurde einem Client der Strom entzogen, so reichte der Server nach kurzer Zeit ein Signal "client disconnect" hoch. Blieb der Client weiter stromlos, so kam nach 5 Minuten die Notification "client forget". Bei einer erneuten Stromzufuhr meldete dann der Server "client new".

Rec 22.12.2019 00:06:59 Data Received (47/47):
                        xx:xx:xx:xx:ca:58 client disconnect
Rec 22.12.2019 00:07:12 Data Received (46/46):
                        xx:xx:xx:xx:ca:58 client reconnect

Erhielt ein stromlos gewordener Client innerhalb der 5-Minuten-Galgenfrist wieder Strom, so wurde seine Reanimation mit dem Status "client reconnect" kundgetan.

Meine frühere Anwendung reagierte also simpel auf die Signale "client new" und "client reconnect", auf sonst nix.

Man darf nicht nur den Status Connected anschauen, sondern auch Power.

Das Signal "power 1" konnte ich bisher ignorieren.

folgende Zustände können nun vorkommen

power=0,connected=0; gerät nicht verfügbar
power=1,connected=0; kann nicht mehr in iobroker vorkommen, LMS kennt das aber noch
Power=0,connected=1; player ist mit LMS verbunden, aber Soft ausgeschaltet
Power=1,connected=1, player verbunden und eingeschaltet

Ja, dem ist so. Das konnte ich ebenfalls verifizieren.

Für dein Skript musst du nach dem Status Power schauen.

Ja, auch dem ist nun so. Ich habe es nun in meinem Skript geändert (ein Hoch auf den Erfinder der Replace-all-Funktion in Editoren).

Damit man sieht was sonst noch über die Ereignissteuerung läuft, werden alle eingehenden Daten nun im Debug-Level ausgegeben.

Schön, dann kann ich ab sofort darauf verzichten, einen Telnet-Client mit "listen 1" mitlaufen zu lassen.

Dies steht nun in Version 0.8.29 zur Verfügung.

Danke schön! Runter geladen, installiert, Upload angestoßen (!), getestet: Siehe da, es läuft alles bestens :blush: Daher konnte ich mir natürlich Zeitmessungen nicht verkneifen:

---------------------------------------
Auszeit    bis Power=1     Abbruch nach
---------------------------------------
   10         35            
   10         50
   10         14   
   10         31
   10         38
   10         38   
   10         37
   10         51
---------------------------------------

Auch wenn diese geringe Zahl an Testläufen nicht repräsentativ sein kann, so wage ich doch ein erstes Fazit:

• Die zuvor aufgetretenen großen Ausreisser nach oben wurden nicht mehr beobachtet.
• Auch die Werte im mittleren Bereich haben sich im Allgemeinen verkürzt.

Von daher hat der Wechsel "vom Abfrage-Modus auf den Lausch-Modus" wohl die erhoffte Wirkung erzielt :+1:

Übrigens: Bei meinem heutigen Handling mit LMS/Adapter/Skript habe ich erneut zweimal die Situation gehabt, dass nach dem Einschalten des Clients keine Power/Connected-Änderung an mein Skript gemeldet wurde. Da ich gerade parallel einen Telnet-Client zwecks LMS-Beobachtung mitlaufen hatte, konnte ich jedoch die "Unschuld" des Adapters belegen: Der LMS selbst hatte die Status-Änderung nicht über die listen-Schiene signalisiert.

[OliverIO]

@hsteinme Das ist schön das es jetzt funktioniert.

[hsteinme]

Mein Favorite-Refresh-Setting steht auf Standard, also auf 6 Stunden. Gelegentlich strukturiere ich meine SqueezeBox-Favoriten um. Da ich dann nicht bis zu 6 Stunden warten möchte, stellt sich die Frage, ob es eine Möglichkeit gibt, einen Favorite-Refresh manuell anzustoßen.

Der Adapter-Restart gehört nicht zu diesen Möglichkeiten. Das Favorite-Refresh-Setting runter und dann wieder rauf zu drehen, ist sicherlich eine Möglichkeit, aber nicht meine allerliebste.

[OliverIO]

@hsteinme
ja gibt es.
In den Objekten unter Server gibt es einen Kommandoknopf getFavorites

[hsteinme]

Upps! Hatte ich gesucht - und übersehen. Sorry & Danke!

[hsteinme]

Das Löschen von Favoriten hinterlässt "Leichen" im Favoriten-Objektbaum von SqueezeboxRPC. Ein Beispiel:

• Die Ausgangslage:
  

• Der Eintrag "Test eins" wird auf dem LMS gelöscht:
  

• Der Button squeezeboxrpc.0.Server.getFavorites wird gedrückt. Das Objektfenster im Browser wird zur Vorsicht geschlossen. Es wird ein neues Objektfenster im Browser geöffnet:
  

Man sieht nun:

• Der Eintrag "Test zwei" ist nach oben gerutscht, um den vorherigen Platz von "Test eins" einzunehmen.
• Auf dem bisherigen Platz von "Test zwei" bleibt jedoch sein alter Eintrag stehen (siehe Timestamps)

[OliverIO]

Ja, der objektbaum hinterlässt manchmal artefakte. Die Objekte existieren eigentlich nicht mehr, sondern kommen wahrscheinlich aus dem Browser Cache
Oben links gibt es für den objektbaum ein aktualisieren Knopf. Spätestens dann müssten diese Zombie Objekte weg sein. Wenn nicht, dann schauen wir weiter.

Technisch wird bei jedem aktualisieren im Hintergrund alle Favoriten states gelöscht und dann neu angelegt.

[hsteinme]

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

Die Objekte existieren eigentlich nicht mehr, sondern kommen wahrscheinlich aus dem Browser Cache
Oben links gibt es für den objektbaum ein aktualisieren Knopf. Spätestens dann müssten diese Zombie Objekte weg sein. Wenn nicht, dann schauen wir weiter.

Ja, dann lass uns mal bitte weiterschauen.

Der Refresh-Knopf brachte keine Heilung.

Nachdem zwei Stunden nach dem Löschvorgang vier verschiedene Browser auf demselben PC sowie zwei verschiedene Browser auf einem zweiten PC immer noch den Zombie im Objekt-Fenster anzeigten, habe ich dann meinen Knopf für das Auslesen des Favoriten-Objektbaums bemüht. Das Log zeigt dann folgendes an:

2020-02-04 16:59:46.144 - info: javascript.0 script.js.common.MultiMedia.SqueezeBoxFavorites: Debug Info: FavoriteId: 1.0
2020-02-04 16:59:46.144 - info: javascript.0 script.js.common.MultiMedia.SqueezeBoxFavorites: Debug Info: FavoriteName: DR+P8+Jazz .
2020-02-04 16:59:46.144 - info: javascript.0 script.js.common.MultiMedia.SqueezeBoxFavorites: Debug Info: FavoriteId: 1.1
2020-02-04 16:59:46.144 - info: javascript.0 script.js.common.MultiMedia.SqueezeBoxFavorites: Debug Info: FavoriteName: Test zwei
2020-02-04 16:59:46.144 - info: javascript.0 script.js.common.MultiMedia.SqueezeBoxFavorites: Debug Info: FavoriteId: 1.2
2020-02-04 16:59:46.144 - info: javascript.0 script.js.common.MultiMedia.SqueezeBoxFavorites: Debug Info: FavoriteName: Test zwei
2020-02-04 16:59:46.145 - info: javascript.0 script.js.common.MultiMedia.SqueezeBoxFavorites: Debug Info: FavoriteId: 10.0
2020-02-04 16:59:46.145 - info: javascript.0 script.js.common.MultiMedia.SqueezeBoxFavorites: Debug Info: FavoriteName: Ö1 .

Das scheint also kein reines Anzeigeproblem zu sein.

Hier zum Quercheck mein Code-Schnipsel, der obige Logeinträge erzeugt:

    AnfangsLaenge = FavoritesAccessKey.split('.').length;    
    TrefferListe  = $(FavoritesAccessKey + '.*.id');
    TrefferListe.each(function (Key, Position) {
        Tmp = Key.split('.');
        if(Tmp.length == (AnfangsLaenge + 2)) {
            if (getState(NachbarKey(Key, 'isaudio')).val) {
                if (getState(NachbarKey(Key, 'type')).val == 'audio') {
                    Id = getState(Key).val;
                    Log(true, 'FavoriteId: ' + Id);
                    Name = getState(NachbarKey(Key, 'Name')).val;
                    Log(true, 'FavoriteName: ' + Name);

Technisch wird bei jedem aktualisieren im Hintergrund alle Favoriten states gelöscht und dann neu angelegt.

Vielleicht läuft ja in dieser Ecke etwas schief. Wäre schön, wenn Du da nochmal rein schauen könntest. Besten Dank im Voraus.

[OliverIO]

@hsteinme ich hab etwas gefunden, was temporär zu Differenzen führt und nun in 0.8.31 behoben.
Die Favoriten sind nur im refresh gelöscht worden und nicht wenn man individuell abfragt.
jetzt wird es jedes mal gelöscht.

[hsteinme]

@BoehserWolf said in Neuer Adapter SqueezeboxRPC:

Musste nach dem Update 1x den Upload anschieben damit die neuen Widgets übernommen wurden - nur zur Info.

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

Ja weiß ich, ich glaube wenn man über den normalen Updatemechanismus von iobroker aktualisiert, wird das automatisch gemacht. Ich werde einen Hinweis in die Doku mit aufnehmen

Ich habe keinen Upload-Hinweis in der README.md gefunden. Habe ich da was übersehen?

[OliverIO]

@hsteinme ne stimmt, war noch nicht drin. habe es gerade eingebaut. wird dann beim nächsten release dann auch in der onlinedoku landen.

der befehl lautet

iobroker upload squeezeboxrpc

[hsteinme]

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

ich hab etwas gefunden, was temporär zu Differenzen führt und nun in 0.8.31 behoben

Danke schön!

Ich habe nun folgendes getan

• Update SqueezeboxRPC über die github-Adresse
• sudo iobroker upload squeezeboxrpc
• Version im Adapter-Reiter überprüft:
  ** 0.8.31
• Im LMS wie vor zwei Tagen die Favoriten Test eins und Test zwei angelegt
• Favorit Test zwei gelöscht
• Button squeezeboxrpc.0.Server.getFavorites gedrückt
• Browser geschlossen
• Browser erneut geöffnet
• Im Objects-Reiter squeezeboxrpc.0.Favorites.* überprüft:
  ** Test eins ist nicht mehr vorhanden
  ** Test zwei hat dessen Platz eingenommen mit aktuellem Timestamp
  ** Ein zweiter Test zwei Eintrag mit älterem Timestamp steht weiterhin auf dem früheren Platz von Test zwei
• Per Javascript den Favoritenbaum ausgelesen:
  ** Zwei Einträge für den Favoriten Test zwei werden gefunden

Was habe ich wo falsch gemacht?

Übrigens: Auch nach einem etwa 20 Minuten nach der Favorit-Löschung erfolgten Restart des ioBroker ist der veraltete Eintrag von Test zwei immer noch vorhanden.

[hsteinme]

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

habe es gerade eingebaut

:+1:

[OliverIO]

@hsteinme ok, der löschbefehl vom iobroker scheint nicht so zu funktionieren wie er soll.
muss da nähers recherchieren.

[OliverIO]

@hsteinme ok, einen klein stück bin ich weiter gekommen, aber auf ein weiteres Problem gestossen
Das Löschen funktioniert wieder richtig (ich meine früher hat das auch funktioniert, aber zwischenzeitlich nicht mehr)
ich denke am iobroker befehl wurde geschraubt.

das nächste Problem was ich sehe ist,

ausgangslage:
ich habe im LMS 3 untereinträge
12.1=fav1
12.2=fav2
12.3=fav3

lösche ich den 12.2 fav2 im LMS und lese die favs neu ein,
dann sind korrekter weise nur noch
12.1 und 12.2 im iobroker da, aber wie heisen die?
12.1=fav1
12.2=fav2

wie gesagt, von meiner seite aus wird nun alles ordentlich gelöscht.
lege ich den status nun neu an und übergebe auch den wert fav3
steht trotzdem fav2 drin.

da muss ich erst einmal einen nachvollziehbaren test aufbauen und im forum posten.
da scheint noch ein Fehler zu sein.

[OliverIO]

ok, es scheint am browser zu liegen.
die states habe sich geändert und nach schliessen des Browser tabs und neu öffnen, erscheint der richtige wert.
ich mach mal neues release für meine letzte änderung

[OliverIO]

Neue Version 0.8.32
Fehler beim Umgang mit dem löschen von Favoriten behoben.
ggfs. kann es noch zu Fehlern in der Browseransicht im iobroker Objektbau geben.
Das ist aber rein visueller natur und kann durch schließen und öffnen des Browser-Tabs behoben werden.

[hsteinme]

@OliverIO: Jetzt läuft es bestens :+1:

Ganz herzlichen Dank für Deine Bemühungen: für Deine Diagnosen, für Deine Behebungen und insbesondere für Dein Drumherumprogrammieren um die schwächelnde deleteChannel-Funktion des ioBrokers.

Übrigens: Ein Blick in die Forumsvergangenheit zeigt, dass Dein Adapter nicht der erste ist, der sich über deleteChannel "wundert".