einheitliche kommandos für av geräte

[justme1968]

für presence würde ich als werte apeared und disapeared vorschlagen und die readings auch wirklich nur dann aktualisieren wenn sich der zustand ändert. dann sieht man wann das device zuletzt erschienen oder verschwunden ist.

[betateilchen]

in 71_LISTENLIVE werden die Werte absent und present aus dem zugehörigen PRESENCE übernommen und mit eventMap auf offline und online gemappt - rein aus optischen Gründen.
Und mit event-on-change-reading bleibt auch der letzte Änderungszeitpunkt erhalten.

Den offline/online Status verwende ich als STATE bei diesen Geräten. Power on/off als STATE macht m.E. nicht soviel Sinn, weil man AV-Geräte ja auch ansprechen kann, wenn sie "off" sind, zum Beispiel um sie einzuschalten.

Es ist mir übrigens völlig wurscht, wie irgendwann irgendwelche "einheitlichen" Kommandos heißen werden - ich bin darauf vorbereitet :)

Mein Modul wird eine "rc-translate" Funktion haben, mit der die einheitlichen Befehle in die modulspezifischen übersetzt werden. So kann ich zum einen meinen Ansatz mit den nach Funktionsgruppen zusammengefaßten Befehlen beibehalten (nützlich z.B. für Skripting) als auch auf "einheitliche" Befehle reagieren.

Wenn also ein (einheitlich festgelegtes) "on" über 95_remotecontrol kommt, wird das per rc_notify als "set llradio rc on" an llradio geschickt. Dort wird anhand von "rc" erkannt, dass der Rest erst übersetzt werden muss. aus "rc on" wird dann "power on" (power = funktionsgruppe, on = Befehl in dieser Gruppe) und letztendlich schickt Set() per HTML den Steuerbefehl "POWER" an das Gerät, um den Schaltvorgang auszulösen.

Sobald es also eine klare Definition für AV-Befehle gibt, muss ich lediglich diese interne Zuordnungstabelle anpassen. Vielleicht kann man die Zuordnungstabelle sogar als Forward-Deklaration an 95_remotecontrol übergeben (so wie die anderen Definitonen bei der Bereitstellung der Standardlayouts), dann kann remotecontrol gleich die richtigen Befehle schicken. Das habe ich aber noch nicht weiter geprüft.

[justme1968]

event-on-change sorgt nur dafür das kein event generiert wird. das datum des readings in der detail ansicht ändert sich trotzdem.

STATE sollte der anwender mit stateFormat überschreiben können. im modul sollte nur state verwendet werden.

gruss
  andre

[betateilchen]

STATE sollte der anwender mit stateFormat überschreiben können. im modul sollte nur state verwendet werden.

wird auch.

[betateilchen]

Um mal konkret zu werden - mir fehlen für alle mit Ziffern gekennzeichneten Tasten ein Symbol:
[...]
falls mal jemand Zeit und Lust hat :)

Lust hatte ich nicht, Zeit auch nicht. Aber trotzdem, ich habe 10 neue Buttons erstellt:

Code Auswählen Erweitern


black_btn_EQ.png
black_btn_FAV.png
black_btn_FMRADIO.png
black_btn_HOMEtxt.png
black_btn_IRADIO.png
black_btn_ITV.png
black_btn_PAGEDOWN.png
black_btn_PAGEUP.png
black_btn_REPEAT.png
black_btn_TVout.png


Die Buttons sind bereits eingecheckt und sollten morgen per update bereitgestellt werden.

[betateilchen]

jetzt fehlen eigentlich nur noch die Viertel-Kreis-Segmente, um einen Cursor-Ring darstellen zu können...

-----

Nachtrag - hier noch ein Bild von den neuen Buttons

(http://up.picr.de/15280530lq.png)

[Markus Bloch]

ich habe mal im Wiki die Readings mit einer Beschreibung und möglichen Werten gespickt. Ich hoffe das ist in eurem Interesse.

Vorschläge dazu:

- presence : hier fände ich online / offline "schöner" und auch logischer
- mute : mir gefiele on/off besser als yes/no (es handelt sich ja technisch gesehen um einen Schaltzustand wie bei power auch)

zusätzliche Readings:

currentMedia : "Name" der Wiedergabe"datei" kann alles sein: Datei vom Filesystem, Stream aus dem Internet, m3u-URL oder was auch immer

playing : mit den Werten playing / paused / stopped (z.B. um bei eingehenden Anrufen den Film anzuhalten)

Von mir aus gerne. Da Andre ja den Lead in diesem Thema übernommen hat soll er das entscheiden :-P

Viele Grüße

Markus

[justme1968]

ich hab mal das wiki mit einer version aktuallisiert die mir gefällt.

- presence wie bei PRESENCE
- mute mit on/off
- playStatus mit playing/paused/stopped
- currentMedia wie vorgeschlagen

gruss
  andre

[Markus Bloch]

Ja saubere Sache. Sieht schonmal gut aus. Jetzt bräuchten wir so eine Tabelle noch für die Set- und Get-Kommandos.

Gruß

Markus

[Markus Bloch]

Hab im Wiki mal wieder ein paar Vorschläge eingebaut.

Was meint ihr dazu?

Viele Grüße

Markus

[TeeVau]

Hallo,

ich möchte auch ein paar Punkte in die Runde werfen:

• Die Idee finde ich erst einmal gut! :-) Ich möchte aber anregen, den Aufbau der Befehle nicht zu sehr zu strukturieren.
  Meiner Meinung nach wird es irgendwann eher unübersichtlicher und auch sinnfreier.
  Als Beispiel wurde ja z.B. das ListenLive Modul angesprochen, dort finde ich aber z.B. solche übermäßigen Strukturen (Das Volume und mute zu audio gehört ist meiner Meinung nach klar, dass muss nicht durch einen Parameter kenntlich gemacht werden. Das Bild kann nicht lauter werden, das Menü ja auch nicht). Ich möchte es nicht als schlecht darstellen, der Modulauthor hat bestimmt seine Gründe dafür!
  Ich selber würde mich aber schwer damit tun, so eine Struktur in mein VIERA Modul einzubinden. Das bitte ich zu bedenken :-)
• Zu den "allgemeingültigen" set-Befehlen würde ich einen set-Befehl vorschlagen "remoteControl", für Geräte die es erlauben die Fernbedienungselemente zu simulieren. Hier wird es vermutlich nur schwer sein, eine allgemeingültige Benennung zu finden, die für alle Geräte zutrifft. Oft, oder zumindest bei meinem Modul, haben Funktionen ja einen Marken- oder Produktspezifischen Namen. Es macht in meinen Augen Sinn, diesen Namen auch beizuhalten.
• Wenn keiner was dagegen hat, würde ich in den nächsten Tagen mal eine Tabelle für die set-Befehle ins Wiki stellen, nach dem selben Muster wie die der Readings erstellt wurde. Einfach als Diskussionsgrundlage.
• Über STATE wurde ja schon mal gesprochen, aber die Diskussion ist irgendwie abgebrochen (oder aufgeschoben? :-)). Soll es dafür auch eine Vereinheitlichung geben? Ich habe mich damals an FS20 und die Guidlines orientiert. Bei mir wird z.B. nur on/off signalisiert. Aber vielleicht schiebt man das auch etwas auf und geht besser Schritt für Schritt vor ;-)
• Die Readings im VIERA Modul würde ich den Guidlines entsprechend anpassen, vor der Arbeit scheue ich mich nicht :-) Hat jemand eine Idee, wie mit den alten, dann absoleten Readings umgegangen werden soll? Für immer beibehalten finde ich unschön. Eine Migrationszeit wäre wohl das Beste. Optimal wäre, wenn man eine Logmeldung ausgeben könnte, dass das verwendete Reading obsolet ist. Aber ob das geht?! Oder ich muss mich mal mit der notice Funktion von FHEM auseinander setzen ;-)

Grüße, Tobias

[justme1968]

kur ein paar gedanken:

1. hier sollte man vielleicht einen mittelweg finden

3. ja bitte :)

4. STATE sollte man nicht direkt setzen sondern dem anwender per stateFormat und devStateIcon ermöglichen hier anzuzeigen was er möchte. das kann von text über album cover bis hin zur remote alles sein.

5. das wäre vielleicht auch ein beispiel für eine system notify funktion die ich gestern hier vorgeschlagen habe: Link.

zu den beiden sayText und showText die markus vorgeschlagen hat: wäre nicht ein einziges kommando z.b. message besser? dann muss man nicht mehr unterscheiden ob es ein audio oder video gerät ist.

gruss
  andre

[betateilchen]

Hallo Tobias,

Als Beispiel wurde ja z.B. das ListenLive Modul angesprochen, dort finde ich aber z.B. solche übermäßigen Strukturen (Das Volume und mute zu audio gehört ist meiner Meinung nach klar, dass muss nicht durch einen Parameter kenntlich gemacht werden. Das Bild kann nicht lauter werden, das Menü ja auch nicht). Ich möchte es nicht als schlecht darstellen, der Modulauthor hat bestimmt seine Gründe dafür!

Hat er, und ich erkläre Dir auch gerne, welche Gründe das sind.

Es mag ja sein, dass in Deinem Denken in dieser Sache die Möglichkeit nicht vorkommt, dass ein Gerät mehr als eine Lautstärkeeinstellung haben kann. Bei Deinem Fernseher mag das so sein, aber mein ListenLive-Geräte hat derer mindestens drei, die derzeit nutzbar sind: die Lautstärke bei normaler Medienwiedergabe und dann noch differente Lautstärken für die beiden programmierbaren Wecker. Wenn ich nun eine Funktion programmiere, die die Lautstärkenangabe "50%" oder "-10%" in die entsprechenden Steuerbefehle umsetzt, dann will ich diese Funktion nicht dreimal im Coding stehen haben, sondern immer wiederverwenden. Und dafür muss ich genau wissen, um welche Lautstärkeeinstellung es geht.

Ausserdem ist die einheitliche Gruppierung sehr hilfreich für den Benutzer, wenn es später um Skripting und mehr als nur die Simulation eines Tastendrucks auf der Fernbedienung geht.

kur ein paar gedanken:

1. hier sollte man vielleicht einen mittelweg finden

Den gibt es schon, und der ist z.B. in meinem Modul schon komplett implementiert. Ich nenne es einen translation-layer.

Man KANN ein einheitliches Kommando, z.B. MUTE (mit der standardisierten Aufgabe die laufende Wiedergabe stummzuschalten) per "set <device> rc mute" ansprechen und der translation-layer wird aufgrund des "rc" aufgerufen, um das einheitliche Kommando in das gerätespezifische Kommando "audio mute" zu übersetzen.

Wahrscheinlich könnte ich das Parsing sogar noch soweit umbauen, dass der translation-layer immer dann aufgerufen wird, wenn ein Befehl nicht zuerst gerätespezifisch ausgeführt werden kann, sodaß erst nach dem zweiten Check eine Fehlermeldung kommt. Dann könnte ich sogar auf das "rc" verzichten. Endgültig festgelegt ist das bei mir (auch gedanklich) noch nicht.

Momentan nutze ich den layer z.B. dazu, die Fernbedienungskommandos aus dem remotecontrol-Modul entsprechend zu verarbeiten, und zwar immer nur dann, wenn der ICON-Name des Fernbedienungsknopfes anders heißt, als der eigentliche Steuerbefehl.

Viele Grüße
Udo

[Markus Bloch]

4. STATE sollte man nicht direkt setzen sondern dem anwender per stateFormat und devStateIcon ermöglichen hier anzuzeigen was er möchte. das kann von text über album cover bis hin zur remote alles sein.

Das ist aus meiner Sicht eine Selbstverständlichkeit (via readingFn's), dennoch sollten wir uns auf einen Wert für das Reading "state" einigen, was ja den Standart-Status bekannt gibt. Ich würde hier ebenfalls wie Tobias vorgeschlagen hat, zum Schaltzustand (on oder off) tendieren. Ich habe diesen Punkt nochmal im Wiki ergänzt. Gerne können wir hier auch andere Sachen verwenden, aber ich denke das ist etwas, was jedes AV-Gerät in dieser Weise unterstützt. Natürlich kann der User dann mit StateFormat den Status nach belieben übersteuern.


Zum Thema remoteControl:

Den Befehl remoteControl halte ich ebenfalls für wichtig. Allerdings währe dann die Frage nach den Button-Benamungen der einzelnen Befehle die jedes Gerät ermöglichen. Ich hab gesehen, einige Module haben hier Großbuchstaben, andere Kleinbuchstaben. In den meisten Fällen sind es einfach die Kommandos so wie sie an das Gerät geschickt werden. Und bei der Vielzahl an Tastenbezeichnungen und gerätespezifischen Funktionen und Benamungen halte ich hier einen Translation-Layer für nicht sinnvoll. Man könnte sich hier auf die schreibweise der Befehle einigen (lowerCamelCaps, Großschreibungen, mit oder ohne Unterstrich) und bestimmte Grundbefehle wie Power, Volume, Mute. Alles weitere ist sehr geräteabhängig und es wird viele Tasten geben die es nur auf einer bestimmten Modellreihe gibt usw. Daher würde ich einen solchen Translation-Layer hier auf das minimalste beschränken, halte es aber dennoch für notwendig, gerade weil sonst solche Befehle bei jedem Modul ander heißen oder etwas anderes bedeuten, usw.

Viele Grüße

Markus

[betateilchen]

dennoch sollten wir uns auf einen Wert für das Reading "state" einigen, was ja den Standart-Status bekannt gibt. Ich würde hier ebenfalls wie Tobias vorgeschlagen hat, zum Schaltzustand (on oder off) tendieren.

Das halte ich für keine gute Idee. Die Frage, ob das Gerät überhaupt erreichbar ist (z.B. Presence) hat viel mehr Aussagekraft. Einen wirklichen Unterschied zwischen An und Aus gibt es z.B. bei ListenLive Geräte nicht.

Den Befehl remoteControl halte ich ebenfalls für wichtig [...] halte ich hier einen Translation-Layer für nicht sinnvoll.

Nochmal: der Translation Layer muss im entsprechenden Gerätemodul implementiert werden, nicht in der Fernsteuerung. Und spätestens wenn Ihr mal versucht, mehrere unterschiedliche Geräte zu "verwalten" werdet Ihr schnell feststellen, dass eine "harte Verdrahtung" nahezu unmöglich sein wird.

Der Befehl "next" kann z.B. geräte-/herstellerabhängig "skip" oder "forward" oder "next" oder "skipNext" heißen und trotzdem immer das gleiche Symbol nutzen.