"get <SONOSPLAYER> RadiosWithCovers" greift auf alte Daten zurück

Begonnen von CQuadrat, 15 Oktober 2018, 10:48:03

Vorheriges Thema - Nächstes Thema

CQuadrat

Hallo Zusammen,

ich habe das seltsame Phänomen, dass der Aufruf von
get <SONOSPLAYER> RadiosWithCovers dazu führt, dass im Reading "Radios" eine Liste abgelegt wird, die schon lange nicht mehr aktuell ist.

In der iOS Sonos-App habe ich (mittlerweile) ganz andere Radiosender. Wie kann das sein? Wie bekomme ich diese Liste aktuell?

Meinem Verständnis nach sollten doch beide Listen (App und Reading) identisch sein.


Danke und Gruß

Christoph
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

Reinerlein

Hi Christoph,

zunächst mal liefert ein

get <SONOSPLAYER> RadiosWithCovers
nur eine asynchrone Antwort im Reading "LastActionResult".

Wenn du das Attribut "getListsDirectlyToReadings" gesetzt hast, dann wird das Ergebnis direkt in das Reading "Radios" geschrieben. Dann steht in "LastActionResult" etwas von "DirectlySet".

Ist das Attribut bei dir vielleicht verschwunden? Was steht denn nach dem Aufruf in "LastActionResult"?
Alternativ gab es am Anfang ja (ohne das Attribut "getListsDirectlyToReadings") eine Variante mit UserReadings. Fall du diese Variante verwendest: Ist da etwas verschwunden?

Grüße
Reiner

CQuadrat

Die Attribute habe ich erst die Tage gesetzt.

Muss ich danach neustarten oder genügt auch "attr Sonos disable 0->1->0"?

Bei notwendigem Neustart kann ich frühestens heute Abend nochmal probieren.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

Reinerlein

Hi Christoph,

das mit dem Disable sollte reichen, da nur der SubProzess neustarten muss...
Was steht denn im Reading "LastActionResult", wenn du das Get aufgerufen hast?

Grüße
Reiner

CQuadrat

Hallo Reiner,

in LastActionResult steht:
GetRadiosWithCovers: DirectlySet

Im Reading "Radios" stehen wieder "alte" (und auch ungültige) Radiosender, die ich gar nicht mehr in der Sonos-App sehe.

Das Reading hatte ich noch vor dem Get mit deletereading gelöscht und zeigt nach dem Get einen aktuellen Zeitstempel.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

Reinerlein

Hi Christoph,

das ist schon komisch.
Hast du irgendeine Art von "Event-on-*" oder sowas aktiviert?

Das Löschen eines solchen Readings bitte nur machen, wenn der SubProzess tot ist. Für die Überprüfung auf einen neuen Wert ziehe ich immer "auf beiden Seiten" Informationen heran.
Bedeutet, dass ich im SubProzess eine Kopie aller aktuellen Readingswerte halte, um nur wirklich veränderte Werte überhaupt an das Fhem-Modul zu übertragen.
Deswegen ist es auch gefährlich, wenn man diese event-on-* Dinger aktiviert hat...

Aber eigentlich sollte dabei kein alter Wert nochmal gesetzt werden (dieses Konzept ist ja genau für andersherum da :) )...

Ich bin da gerade etwas überfragt...

Grüße
Reiner

CQuadrat

Ein event-on-change-reading hatte ich in der Tat gesetzt. Habe ich jetzt aber gelöscht.

Danach nochmal ein Get und wieder die alten Werte im Reading "Radios".

Dabei ist mir aufgefallen, dass sich der Zeitstempel des Readings zunächst nicht aktualisiert hat. Erst nachdem ich das Reading wieder gelöscht habe, wurde es (wieder) durch ein Get geschrieben.

Diese Aussage verstehe ich nicht: "Für die Überprüfung auf einen neuen Wert ziehe ich immer "auf beiden Seiten" Informationen heran."

Ich habe drei Sonos im Einsatz. Bei allen ist das Reading "RadiosVersion" identisch und verweist auf den "zentralen" Sonos. Ist das von Relevanz?


FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

Reinerlein

Hi Christoph,

mit "beide Seiten" meinte ich den SubProzess und den Fhem-Modul-Teil.

Da die Radiosender (wie auch Playlisten und Favoriten) globale Listen sind, sind sie bei allen Playern gleich. Eigentlich wären sie am Besten am zentralen Sonos-Device aufgehoben, um diesem Umstand gerecht zu werden. Allerdings braucht man sie manchmal am Playerdevice selbst, deshalb diese Duplizierung.

Die Versionsnummer ist die Unterscheidung für den Automatismus (Attribut "getRadiosListAtNewVersion" und die Artverwandten). Daran wird festgemacht, ob diese Listen aktualisiert werden müssen.

Hast du mal versucht dieses Attribut zu setzen, um zu schauen, ob die Liste automatisch neu geholt wird?

Grüße
Reiner

CQuadrat

Okay, die Attribute sind/waren auch gesetzt.

Aber ich konnte den Fehler etwas einkreisen:
Ergänze ich per Sonos-App einen neuen Radiosender taucht er im Reading auf. Allerdings scheint das Löschen nicht zu funktionieren: alte und ungültige Sender bleiben in der Liste.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

CQuadrat

Hallo Reiner,

kann ich das Reading irgendwie komplett löschen? Gibt es einen Hash den ich auf "" setzen kann, um dann komplett neu einzulesen?


Viele Grüße

Christoph
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

Reinerlein

Hi Christoph,

also im Prinzip ja:
1. SubProzess beenden (mit disable=1 am Sonos-Device)
2. Reading entfernen (aber auch das Versionsreading dazu)
3. SubProzess wieder starten

Beim Start des SubProzesses werden die Readings-Werte an den SubProzess übertragen, damit dieser weiß, was alles aktualisiert werden muss/müsste...

Ich konnte das Problem noch nicht finden, habe aber auch ein komisches Verhalten festgestellt, da das Reading bei mir auch nicht automatisch aktualisiert wird... habe aber halt noch nichts gefunden...

Grüße
Reiner

Reinerlein

Hi Christoph,

ich habe mal ein bißchen rumgespielt:
In meiner Sonos-App (iOS) werden die gespeicherten Radiosender überhaupt nicht mehr direkt angezeigt. Das was man auf der ersten Seite (Mein Sonos) sieht, sind die Favoriten, aufgeteilt nach Playlisten, Sender und Alben.

Wenn man einen Radiosender antippt, und unter "mehr" dann auf "Meinen Radiosendern hinzufügen" antippt, dann taucht dieser Sender auch in den Radios auf. Dann wird er auch bei mir in Fhem angezeigt...

Ist das bei dir vielleicht auch nur eine solche Verwirrung?

Grüße
Reiner

CQuadrat

So, bin eben erst wieder dazu gekommen, mich damit zu beschäftigen.

Ich habe jetzt alle reading gelöscht (mit deletereding) und dann die Radios neu eingelesen.

Das Problem besteht weiterhin. Neue Sender tauchen zwar auf aber alte, von mir bereits in der SONOS-App gelöschte Sender, tauchen wieder auf.

Ich würde die gerne wegbekommen, da da viele ungültige Sender darunter sind.

FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue