Sonos-Update: Neues Feature "disable"

[Reinerlein]

Hallo zusammen,

ich habe gerade eine neue Version eingecheckt, die folgende Änderungen hat:

• Beim Anlegen der neuen Devices werden die Aliasnamen nun mit der Funktion im Team erweitert
• Der Mechanismus zum Starten des SubProzesses wurde angepasst, um auf Synology-Begebenheiten Rücksicht zu nehmen
• Die Coverdarstellung für einige Spotify-Titel wurde korrigiert, indem eine andere Spotify-API verwendet wird
• Bei Playlist-Covern wird nun das Cover des ersten Titels mit AlbumArt angezeigt
• Bei Favourite-Covern werden nun Album-Favoriten auch mit Cover dargestellt (das Cover des ersten Titels mit AlbumArt)
• Ein Album aus der lokalen Bibliothek konnte mittels "StartFavourite" nicht korrekt gestartet werden (es wurde nicht als Liste übertragen, sondern als Titel gestartet)
• LogLevel für die "Connection accepted"-Meldungen auf 3 hochgesetzt
• Es gibt jetzt ein Attribut "disable" am Sonos-Device. Wird es auf 1 gesetzt, wird der SubProzess beendet und verarbeitet somit keine Sonos-Nachrichten mehr. Wird es auf 0 gesetzt (oder gelöscht), wird der SubProzess wieder gestartet.

Eine wichtige Neuerung ist das "disable"-Attribut am Sonos-Device. Wird es gesetzt, wird der SubProzess beendet, wird es wieder zurückgesetzt oder gelöscht, wird der Prozess wieder gestartet.
Damit kann man das Modul mal kurz außer Funktion setzen, wenn man neue Sonos-Komponenten in das System integrieren möchte...

Außerdem kann man sich nun auch eine ReadingsGroup für Playlisten machen, in denen nur das Cover zu sehen ist, solange sich der erste Titel der Playlist unterscheidet...

Ab jetzt im SVN oder ab nachher im Update...

Grüße
Reinerlein

[Reinerlein]

Hallo zusammen,

mit diesem Update hatte sich ein Fehler im Speak-Aufruf eingeschlichen.
Dort sollte eine Fehlermeldung generiert werden, wenn man die beiden notwendigen Attribute am Sonos-Device noch nicht gesetzt hatte.

Dieser Mechanismus war leider fehlerhaft, sodass immer eine Fehlermeldung kam.

Das habe ich korrigiert... jetzt im SVN oder ab Morgen im Update...
Sorry für diese Unannehmlichkeit.

Grüße
Reinerlein

[Loredo]

   
• LogLevel für die "Connection accepted"-Meldungen auf 3 hochgesetzt

Zitat aus dem FHEM Wiki zur Modulentwicklung:

Damit bietet es sich an im Modul Meldungen, die im normalen Betrieb nicht benötigt werden, beim Aufruf von Log3 mit dem Level 4 oder 5 anzugeben.

[Reinerlein]

Hallo Loredo,

mal ganz ehrlich: Über was diskutieren wir hier eigentlich?
Es werden allgemein 5 Loglevel angeboten. Ich nutze die vollständig, um die diversen Abstufungen bei der Fehlersuche besser unterscheiden zu können. Mir sind da drei Level deutlich zu wenig. Und ja, es sind von mir festgelegte Abstufungen...

Und nochmal: Was stört dich daran, an deinem Sonos-Device *einmal* den Verbose-Level auf 0 zu setzen?
Dann wirst du mit keiner Meldung (ausser einer Startmeldung) im laufenden Betrieb auf der Konsole belästigt...
Für das Log der einzelnen Devices in das Standard-Fhem-Log kannst du diese ja auch noch runtersetzen, die loggen aber sowieso seltener etwas.

Für mich sind die Level-3 Meldungen wichtig, die möchte ich bei mir immer sehen. Für dich nicht. Soweit, so gut... schalte sie bei dir ab, und gut ist...

Um es mal mit anderen Modulen zu vergleichen: Auf Level drei teilt mir Homematic mit, das es geschaltet wurde (das ist vergleichbar mit der Sonos-Meldung, dass ein Transport-Event eingetreten ist).
Auf demselben Level sagt mir mein wiederkehrender Save-At-Job, dass er ausgeführt wurde (das ist vergleichbar mit den Thread-Status-Mitteilungen des Sonos-Moduls)
Es gibt also eine ganze Menge Informationen auf dem allgemeinen Level drei. So auch hier...

Wenn man das Modul das erste mal verwendet, kann man auf Level drei super erkennen, ob es soweit läuft, und auf Änderungen am Player reagiert. Wenn es läuft, und einen die Meldungen nerven, schaltet man sie halt ab.

Grüße
Reinerlein

[Loredo]

mal ganz ehrlich: Über was diskutieren wir hier eigentlich?

Mich stören dabei 2 Dinge:

   
• Du hältst dich nicht an den Standard und weichst somit vom gewohnten/erwarteten Verhalten ab. Das steht komischerweise im krassen Gegensatz dazu, dass du es dem User beim Anlegen von readingsGroups etc kräftig unter die Arme greifst (was ich prinzipiell gut finde), ihm hier aber zumutest manuell ein Verbose auf 0 setzen zu müssen, damit das Logfile nicht zugemüllt wird.
• Die Änderung des Verbose-Attributs erfordert einen FHEM Neustart, da er bei deinem Modulen nicht zur Laufzeit beachtet wird (oder teilweise werden kann, wie du ja schon gesagt hast). Einen Neustart machen zu müssen ist für mich hier ein No-Go, wenn die Standardeinstellung zu geschwätzig ist.

Die Beispiele, die du aufführst, sind schon alle valide. Aber du loggst in Level3 deutlich mehr also nur Events. Die "Connection established" Meldungen sind meiner Ansicht nach zyklisch auftretend und werden nicht durch ein normales Event ausgelöst (außer vielleicht durch einen ablaufenden internen Timer).


Ja, bei mir ist Ruhe seit ich neben dem verbose=0 auch noch einen Neustart gemacht habe (aber darauf muss man halt erstmal kommen und es auch machen können in dem Moment). Ich sage auch nicht, dass ich mit gar keinen Ausgaben wie jetzt aktuell nicht leben könnte, ich sage nur, dass die Sonos Module sich hier nicht dem Standard gemäß verhalten und mich das irritiert hat. Ich kann nur vermuten, dass es anderen auch so geht, ging oder gehen wird.

[Reinerlein]

Hi Loredo,

nun gut, dafür gibt es ja mittlerweile das disable-Attribut welches als einziges "live", also sofort wirkt.

Wenn man das aktiviert hat (und der SubProzess kurz danach beendet ist), kann man alle anderen Attribute ebenfalls anpassen. Beim Deaktivieren (oder löschen) des "disable"-Attributs wird der SubProzess wieder angestartet, und erhält dann auch die neuen Attribut-Werte, da er ja neu angestartet wurde.

Das Problem an Standards ist halt, dass sie sich ständig ändern...

Grüße
Reinerlein

[Loredo]

Das disable-Attribut ist ein guter Kompromiss für den Subprozess, ja.
Die LogLevel an sich ins damit allerdings leider noch immer falsch. Ich würde ja gerne die ein oder andere Meldung im Log sehen, aber andere sind eben überflüssig für den normalen Betrieb. Daher bleibt mir halt nix anderes übrig als im normalen Betrieb auf sämtliche Meldungen zu verzichten, damit mein Logfile nicht zugemüllt wird. Sehr schade.

[Loredo]

Ich habe jetzt einmal mit dem Attribut "disable" gespielt.
Leider sind die Devices hinterher nicht mehr "available" und sie kommen auch nicht wieder "hoch".


Beim Lesen der Readings sind mir einige Diskrepanzen aufgefallen:

Internals:
   DEF        RINCON_B8E93722EB1001400_MR
   NAME       Sonos_Bedroom
   NR         262
   NTFY_ORDER 50-Sonos_Bedroom
   STATE      appeared
   TYPE       SONOSPLAYER
   UDN        RINCON_B8E93722EB1001400_MR
   CHANGETIME:
   Helper:
   Readings:
     2015-01-25 17:27:15   presence        disappeared
     2015-01-25 11:11:58   state           appeared
     2015-01-19 06:45:09   transportState  PLAYING
Attributes:
   stateVariable Presence

Wie man sieht, ist STATE hier auf appeared, während Presence auf disappeared steht und folgerichtig steht auch in der readingGroup später "Player disappeared" und das Gerät lässt sich nicht steuern.


pingType war auf default, explizit auf syn setzen hilft jedoch auch nichts. Aktuelles Update von gestern (sprich heute via Update-Funktion) habe ich eingespielt.


Was mache ich nun schon wieder falsch? 

[Reinerlein]

Hi Loredo,

hmm...

Kurze Vorgangserläuterung;
Wenn du "disable" aktivierst, wird erst der SubProzess beendet, und dann der State des Sonos-Device auf "disabled" gesetzt (erst das Reading "state", und dann "STATE" selber).

Anschließend wird bei jedem Player-Device das Reading "presence" auf "disappeared" gesetzt.

Durch das Beenden des SubProzesses wurde auch der pingCheck-Thread beendet, und könnte keinen Player mehr als abwesend erkennen. Daher der direkte manuelle Weg...

Beim Löschen/Deaktivieren des Attributs "disable" wird der Prozess wieder angestartet, wie es beim Start von Fhem auch durchgeführt wird.

Manchmal ist der Port für den SubProzess dann noch nicht erreichbar. Dann wird mit einem 30Sekunden Timeout gewartet, und ein weiterer Versuch gestartet. Das ganze wird insgesamt 10mal versucht. Dann gibt er auf. Nach meinem Wissen gab es noch nie eine Wartezeit größer 1 Minute (also 2mal). Dann kommt noch die Wartezeit des DevIO-Verbindens dazu, die sich bei 1 Minute u.U. gerade verpasst hat, sodass die Verbindung von Fhem zum Prozess dann auch mal 2Min dauern kann...
Das kann man aber im Log auch sehen...

Wieso bei dir jetzt der state auf appeared steht, das Reading presence aber nicht, kann ich mir auch nicht erklären.
Der State wird ja beim discovern der Player als Folge von presence gesetzt, und sollte dann den gleichen Inhalt wie presence haben (zumindest, wenn, wie bei dir, das Attribut "stateVariable" auf "Presence" steht).

Es kann halt nur sein, dass der SubProzess einfach noch nicht läuft, bzw. nicht verbunden ist...

Wir bräuchten hier mal tiefere Logausgaben. Im ersten Schritt erstmal auf 4, und dann sowohl die Fhem-Logs, als auch die Konsolenausgabe des SubProzesses.
Damit kann man zumindest mal versuchen nachzuvollziehen, was er eigentlich tut, bzw. getan hat...

Ich sollte auf jeden Fall noch was einbauen, damit der state der Player mit aktualisiert wird, wenn stateVariable auf Presence steht...

Grüße
Reinerlein

[Reinerlein]

Hi Loredo,

ich habe jetzt das Setzen vom state aller Sonosplayer-Devices (bzw. auch STATE, wenn das Attribut "stateVariable" auf "Presence" steht) beim Setzen von "disable" mit eingebaut.

Das löst jetzt nicht dein Problem, sondern korrigiert nur die Readings bzw. den STATE...

Jetzt im SVN oder Morgen im Update.

Grüße
Reinerlein

[Loredo]

Danke dir!


Mit Bezug auf meinen anderen Post wo ich erwähne, dass Sonos in eine Structure einbinden möchte: Hier zeigt sich jetzt gerade wieder, dass ein logisch kombiniertes Reading aus state, transportState und presence praktisch wäre. Ich habe aktuell stateVariable auf transportState gesetzt, aber leider gibt transportState natürlich nicht den Status wieder, wenn das Gerät ausgeschaltet ist (oder disable=1 gesetzt ist).


... also ich finde ja immernoch, dass STATE/state/presence/transportState/stateVariable hier eine größere Baustelle sind    *pfeif* 

[Reinerlein]

Hi Loredo,

aber du kannst doch auch stateFormat verwenden. Wie gesagt, "stateVariable" existiert hauptsächlich aus legacy-Gründen (und weil ich denke, dass es einen Tick performanter sein dürfte).
Seit es stateFormat gibt, wird es eigentlich auch unterstützt...

Wenn es nicht klappt, dann ist das ein Bug, und wir sollten uns drum kümmern

Grüße
Reinerlein