einheitliche kommandos für av geräte

[Markus Bloch]

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.

Da geb ich dir Recht ;-) nur wir sollten uns auf ein Befehlsset einigen, wo wir das anwenden (eben genau bei Befehlen wie play, pause, volumeUp,...) und wie diese Kommandos heißen, weiterhin sollten wir festlegen wie Tasten zu bezeichnen sind, die nicht in diesem allgemeinen Befehlsset erfasst sind (z.B. die VIERA Taste im VIERA Modul). Aktuell sind da zu krasse Unterschiede um die Tastenkommandos so 1:1 zu belassen.

Viele Grüße

Markus

[betateilchen]

weiterhin sollten wir festlegen wie Tasten zu bezeichnen sind, die nicht in diesem allgemeinen Befehlsset erfasst sind

das wird nicht funktionieren, erstens gibt es davon zu viele und zweitens ist der Markt dynamisch.

[Markus Bloch]

deswegen soll das ja auch nur ne richtlinie für neue Benamungen sein. Wie die genau heißen ist ja völlig egal, nur sollen die Bezeichnungen lowerCamelCaps sein ohne Unterstriche (meiner Meinung nach) und nicht in kompletten Großbuchstaben, usw.

[betateilchen]

nur sollen die Bezeichnungen lowerCamelCaps sein ohne Unterstriche (meiner Meinung nach)

*dafür*

[Markus Bloch]

grundlegend gleiche Befehle wie Zahlentasten, Cursortasten, Play, Stop, Forward, Back, etc. kann man ja generell festlegen, wie die zu heißen haben, der Rest währe dann dem Modulautor überlassen unter der Grundlage, dass neue Befehle einem Schema XY entsprechen.

[TeeVau]

Guten Abend,

Zu State:
Mir ging es, wie Markus geschrieben hat, um das reading state. Irgendwas muss da ja nun drin stehen durch den Modulauthor. Direktes schreiben in state habe ich nicht im Kopf gehabt. Ich würde ebenfalls zu on/off tendieren, ist ja auch sehr verbreitet in FHEM. Precense ist recht neu, weshalb es nicht unbrauch sein muss. Hier würde es sich ja mit stateFormat einfügen lassen.

Zur Gruppierung der Befehle
betateilchen, du schreibst immer von Fernbedienung, reden wir von dem selben? Ich habe das Augenmerk auf die Module für verschiedene Geräte, dessen set-Befehle und readings vereinheitlicht werden sollen. Und das ganz unabhängig vom Modul remotecontrol.
Das mit den verschiedenen Lautstärken leuchtet mir schon ein, allerdings sehe ich keinen Sinn in einer übermäßigen Gruppierung:
Bei dir kann es natürlich nicht nur einen Befehl "set xxx volume 12" geben, leuchtet mir ein.
Aber wieso muss es "set xxx audio volumeWecker1 12" sein? Das "audio" ist doch überflüssig, da Volume klar definiert, dass es um audio geht. Der set-Befehl muss eben nur eindeutig sein, für das zu steuernde. Wie gesagt, wollte ich es auch nur zu bedenken geben.
Es hat letztendlich auch was mit Programmierphilosophie zu tun, wo es nicht immer ein besser/schlechter oder richtig/falsch gibt.

Dein Beispiel zum Modul remotecontrol habe ich z.B. nicht mit einem translation-layer gelöst, sondern damit, dass mein Modul das Layout erstellt. Somit kann ich, als Author, dem Nutzer eine Möglichkeit bieten ein notify und das Layout zu erstellen, ohne dass er selber programmieren muss. Das war der Sinn, weshalb Markus die Funktion eingebaut hat.

set-Befehl remoteControl
Öhm...ich würde das remoteControl nicht unter so starken Restiktionen legen. Das ist ja letztendlich der Weg zum Gerät, der in den meisten Fällen Geräte und Herstellerspezifisch ist, zumindest gehe ich davon aus. Quasi ein "raw" Kanal, da würde man ja auch keine Nomenklatur festlegen.
Meiner Meinung nach ist das einzigst sinnvolle, dass man die Schreibweise festlegt, da würde ich wie bei allen anderen Spezifikationen auch auf lowCamelCaps setzen. Der Modulauthor muss das entsprechend handeln und ggf. per Code wieder in eine Namenskonvention umbauen, die auch das Gerät versteht. Im Focus sollte hier sein, dass es für den Anwender einheitlich und einfach ist und nicht, dass sich der Modulauthor arbeit spart, oder?

zum Modul remotecontrol
Ich finde keinen richtigen Faden, da hier meiner Auffassung nach oft über Gerätemodule gesprochen wird und über Fernbedienung bzw. remotecontrol Modul. Das remotecontrol Modul hat hier eigentlich gar nix zu suchen, oder sehe ich das falsch? Damit kann ich ja eigentlich alles Steuern, da es nur ein notify erzeugt. Der einzigst sinnvolle Umgang mit dem Modul remotecontrol ist, dass der Modulauthor für Geräte das Layout und notiy selber in seinem Gerätemodul zur Verfügung stellt, worauf dann das Modul remotecontrol zugreifen kann.
Einheitliche set-Befehle für alle AV Geräte, damit das remotecontrol Modul "einfach so" verwendet werden kann, wird man nicht hinbekommen, dafür ist die AV-Welt zu unterschiedlich :-)

[TeeVau]

Habe den Artikel im Wiki mal mit ein paar Vorschlägen gefüllt.

[Markus Bloch]

Sieht gut aus, ich hab hier den Parameter Volume noch einmal etwas präzisiert.

Viele Grüße

Markus

[betateilchen]

Aber wieso muss es "set xxx audio volumeWecker1 12" sein?

Du hast das Prinzip falsch verstanden. "set xxx audio volumeWecker1 12" würde es ja nicht heißen, sondern "set xxx wecker1 volume 12" weil alle Steuerfunktionen für den Wecker wieder in einer eigenen Befehlsgruppe "wecker1" eingeordnet sind, so auch die Lautstärke.

Dein Beispiel zum Modul remotecontrol habe ich z.B. nicht mit einem translation-layer gelöst, sondern damit, dass mein Modul das Layout erstellt.

Mein Modul stellt ebenfalls die Layouts für unterschiedliche Modelle und Fernbedienungen bereit. Das hat aber mit dem translation nichts zu tun. Spätestens wenn es mehrere unterschiedliche Fernbedienungen gibt, mit denen man die ListenLive Firmware steuern kann, brauchst Du nämlich wieder eine Zwischenschicht. Geh doch bitte nicht immer nur von EINEM Gerät aus!

Das remotecontrol Modul hat hier eigentlich gar nix zu suchen, oder sehe ich das falsch?

Für mich gehören die beiden Themen remotecontrol(-Modul) und AV-Geräte(-Modul) untrennbar zusammen und hierher, da beide letztendlich genau über die hier diskutierten Kommandos miteinander verknüpft sind bzw. werden sollen.

[TeeVau]

Du hast das Prinzip falsch verstanden. "set xxx audio volumeWecker1 12" würde es ja nicht heißen, sondern "set xxx wecker1 volume 12" weil alle Steuerfunktionen für den Wecker wieder in einer eigenen Befehlsgruppe "wecker1" eingeordnet sind, so auch die Lautstärke.

Ja, das hatte ich anders verstanden. Hab mich an der Struktur orientiert, die aktuell implementiert und in der commandref dokumentiert ist.
Welche Notwendigkeit siehst du denn noch in der Guidline, um deine Struktur mit einzubringen?

Für mich gehören die beiden Themen remotecontrol(-Modul) und AV-Geräte(-Modul) untrennbar zusammen und hierher, da beide letztendlich genau über die hier diskutierten Kommandos miteinander verknüpft sind bzw. werden sollen.

Sind diese Verknüpfungen dann bereits in der Guidline abgestimmt oder ist da noch eine Baustelle, wo dein Input sicherlich sehr hilfreich ist?!

[betateilchen]

[quote title=TeeVau schrieb am Fr, 02 August 2013 10:55]

Welche Notwendigkeit siehst du denn noch in der Guidline, um deine Struktur mit einzubringen?

Von meiner Seite keine. Die verwendete Struktur in meinem Modul läßt mir allerdings die Möglichkeit, auf jegliche Festlegungen einer Guideline (wenn sie denn jemals kommt) flexibel reagieren zu können.

Sind diese Verknüpfungen dann bereits in der Guidline abgestimmt

Da ist m.E. noch nichts festgelegt.

Meine ganz persönliche Meinung zu der (unbestritten hilfreichen) Guideline:

Hier wird derzeit >90% über eine Guideline von Leuten disktuiert, die dies auf rein theoretischer Basis tun. Die Baustellen werden sich auftun, wenn irgendwann praktisch versucht wird, diese Guideline innerhalb von Gerätemodulen anzuwenden und umzusetzen. Und wahrscheinlich werden dann einige Leute mehr die Gedanken hinter meiner bereits jetzt gewählten Form der Umsetzung verstehen. Im Moment kämpfe ich da irgendwie gegen Windmühlen an.

[Markus Bloch]

Meine ganz persönliche Meinung zu der (unbestritten hilfreichen) Guideline:

Hier wird derzeit >90% über eine Guideline von Leuten disktuiert, die dies auf rein theoretischer Basis tun. Die Baustellen werden sich auftun, wenn irgendwann praktisch versucht wird, diese Guideline innerhalb von Gerätemodulen anzuwenden und umzusetzen. Und wahrscheinlich werden dann einige Leute mehr die Gedanken hinter meiner bereits jetzt gewählten Form der Umsetzung verstehen. Im Moment kämpfe ich da irgendwie gegen Windmühlen an.

TeeVau: Modulentwickler VIERA
Markus Bloch: Modulentwickler YAMAHA_AVR
betateilchen: Modulentwickler LISTENLIVE

Ich bin da schon der Meinung, dass hier die richtigen Leute darüber diskutieren....

[justme1968]

ich hätte lightScene, iTunes und eventuell xbmc (das scheint grad keinem zu gehören) beizusteuern :)

gruss
  andre

[betateilchen]

Ich meinte mit "Diskussion auf theoretischer Basis" lediglich die Diskussion über die Benamung der Funktionen um die es hier seit langem geht, es geht mir nicht darum, dass hier niemand an einem Modul arbeitet. Es war in keinster Weise Absicht zu behaupten, dass hier die "falschen" Leute diskutieren.

An alle Modulentwickler: Fangt doch einfach mal an, das was bisher an "Guideline" existiert, in Euren bestehenden Modulen umzusetzen.

Bei der Konzeption des ListenLive Modules habe ich versucht, all das was hier diskutiert wurde, zu berücksichtigen und in die Entwicklung mit einzubeziehen. Und genau deshalb sieht  mein Konzept jetzt so modular und beliebig ausbaubar aus wie es ist. Hätte ich einfach vor mich hin gewurschtelt, hätte ich es sehr viel einfacher haben können.

[Markus Bloch]

Natürlich würde ich die Guideline ebenfalls bereits gerne umsetzen, aber ich denke, gerade da wir noch über einige Sachen diskutieren und Vorschläge unterbreiten, halte ich das noch für zu früh. Erst wenn z.B die Readings soweit fertig sind, so das kein Diskussionsbedarf besteht würde ich das ganze natürlich bei mir umsetzen. Zurzeit wird ja noch über den Inhalt des state-Readings diskutiert.

Erst wenn wir eine finale Fassung erreicht haben macht es Sinn, die Guideline technisch umzusetzen. Oder wie seht ihr das.


Viele Grüße