einheitliche kommandos für av geräte

[justme1968]

hallo zusammen,

gerade ist ja mit den tv und verstärker modulen sowie dem remotecontrol modul ziemlich schwung in den bereich audio und video geräte gekommen. zusätzlich gibt es noch eine ganze reihe älterer module wie sonor und xbmc und zwei arten itunes anzusprechen und neue module wie für die web radios oder das raspberry multiroom stehen vor der tür.

wie wäre es sich rechtzeitig auf ein möglichst einheitiches kommando set zu verständigen damit grundlegende dinge wie play/pause/volume/next bei allen geräten einheitlich, in gleicher schreibweise und mit möglichst ähnlichen parametern funktionieren?

das würde module wie die remotecontrol aber auch structure und lightscene deutlich einfacher und nützlicher machen und auch alternative frontends erleichtern wenn bestimmte features wie audio,video oder cover über ein einheitliches schema markiert würden.

mein vorschlag wäre sich an das sonos modul anzulehnen weil es mir in dieser hinsicht am fortgeschrittensten erscheint und auch  weitergehende features wie cover oder durchsagen anbietet.

zu vereinheitlichen wäre dann u.a.:
- welche kommandos zu welchem zweck
- kommandos sollten einheitlich geschrieben werden. also z.b. immer klein oder immer mixed case.
- parameter sollten so weit möglich den gleichen wertebereich haben. also z.b. volume immer von 0-100.
- wenn es aus irgendeinem grund noch ein gerätespezifischer wertebereich nötig ist sollte der zusätzlich vorhanden sein.
- cover sollten immer auf die gleiche art gelesen werden können
- ...

für die eigentliche ideensammlung und dokumentation ist vielleicht das wiki am geeignetsten.

was haltet ihr davon?

gruss
  andre

[UliM]

Hi,
bin dafür :)
Wir könnten einen neuen Entrag unter http://www.fhemwiki.de/wiki/Kategorie:Development platzieren.
=8-)

[herrmannj]

plus 1 für die Idee

[Markus Bloch]

generell währe ich auch dafür, allerdings dann eben nur mit lowelCamelCaps wie in http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Bezeichnungen beschrieben. Im Sonor ist das ja wieder anders umgesetzt und ich denke wir sollten uns hier schon an die bereits vorhandenen guidelines halten.

ich denke das gleiche sollten wir dann ebenfalls für Readings/Events machen.

Gruß
Markus

[Rince]

Finde die Idee sehr gut.

[justme1968]

alles was es hier schon gibt sollte man natürlich verwenden. vorausgesetzt es passt und es wird an irgend einer stelle tatsächlich auch schon so gemacht. wenn die realität doch anders ist sollte man sich vielleicht doch daran orientieren.

die bisherigen guidelines mit den lowelCamelCaps beziehen sich auf readings und attribute. das können wir gerne so übernehmen bzw. darauf verweisen. für kommandos würde ich das gleiche vorschlagen.

die meisten readings im sonos modul sind glaube ich auch so. aber die kommandos sind (fast?) alle gross geschrieben.

ich denke es ist aber wichtig nicht nur die syntax so einheitlich wie möglich zu machen sondern auch die semantik wenn es geht. neben den kommandos die das gerät steuern auch solche dinge wie cover art oder sprachdurchsagen und text einblendungen. wenn die überall einheitlich funktionieren kann man dann universell verwenden egal welches gerät ein anwender dann tastächlich hat.

einen anfang des wiki artikels gibt es hier: http://www.fhemwiki.de/wiki/DevelopmentGuidelinesAV.

gruss
  andre

[Markus Bloch]

evtl. sollten wir im rahmen dessen einmal ein solches namensschema definieren. Dazu kommt, das solche sachen wie Coverart, text2speech z.T. auch Deviceabhängig sind und man nicht immer forcieren kann.

Ich persönlich denke ein absolutes Minimum an set-Befehlen für jedes Modul währe:

- allgm. an und aus schalten
- Lautstärke (Pegel und Stummschaltung)
- Kanal wechseln (Eingangskanal, bzw. Fernseherkanal bei TV/Mediareceiver)

ein absolutes Minimum an Readings:

- Power Status (an oder aus=
- akt. Lautstärke und Stummstatus
- akt. Kanal

Weitere sachen wie:

- Coverart
- Fernbedienungstasten
- Zonen
- Text 2 speech
- usw.

währe n dann optional, je nach Möglichkeiten des Gerätes.

Je nach dem was ein Device kann, sollte es nur die entsprechenden Befehle/Kanäle zur anzeige bringen.

Und wie diese Befehle/Readings heißen, sollten wir in deinem Wiki-Artikel komplett festhalten.

Je nachdem muss man dann eben bestimmte Befehle/Funktionalitäten die ein Gerät von Haus aus nicht kann im Modul nachprogrammieren.

Viele Grüße

Markus

[justme1968]

ja. genau das ist die richtung die mir vorschwebt.

wenn man kommandos und readings vereinheitlicht dann kann eben ganz einfach mit 'set <device> ?' oder 'get <device> ?' nachsehen ob eine bestimmte funktionalität auch da ist oder im frontend spielereien machen die dann für mehr als ein gerät gehen.

was die funktionalitäten angeht die ein gerät vielleicht nicht direkt bereitstellt und die dann im modul nachprogrammiert werden: wenn sie sich auf die vereinheitlichen minimal befehle zurückführen lassen dann kann man sie auch einmal und allgemein implementieren wie es bei den SetExtensions der fall ist.

gruss
  andre

[UliM]

Je nachdem muss man dann eben bestimmte Befehle/Funktionalitäten die ein Gerät von Haus aus nicht kann im Modul nachprogrammieren.

Wenn ein Gerät keine Latstärkesteuerung von außen anbietet, kann man sie auch nicht nachprogrammieren - hängt halt ovn der Firmware des zu steuernden Gerätes ab.

Mein Votum: Werden Befehle, Attribute, Readings implementiert, müssen sie sich an die Namenskonvention halten. Die Liste ist zu erweitern, wann immer neue Befehle dazukommen.
Für existierende Module heisst das: Der Modulautor entscheidet, ob er die Befehle/Readings/Attribute gemäß der nun zu etablierenden Namenskonvention im Sinne der Abwärtskompabilität zusätzlich zu den bestehenden implementiert, oder die bisherigen ersetzt.


Gruß, Uli

[justme1968]

ja. wenn es keine lautsärke gibt kann man sie nicht herbeizaubern. wenn es aber eine absolute laustärke gibt kann man lauter,leiser und mute nachbauen.

gruss
  andre

[Markus Bloch]

ja. wenn es keine lautsärke gibt kann man sie nicht herbeizaubern. wenn es aber eine absolute laustärke gibt kann man lauter,leiser und mute nachbauen.

gruss
  andre

genau das meinte ich.

[Markus Bloch]

genauso auch, ob man nun absolute (dB) oder relative lautstärke (Prozent) verwendet und falls beides verfügbar ist, wie man das befehlsmäßig anbietet

[herrmannj]

Für die Lautstärke schlage ich per Konvention 0..100 vor, steht zukünftigen Modulentwicklern ja frei das intern in dB umzurechnen und bei Bedarf zusätzliche proprietäre Funktionen anzubieten.  

Generell können wir ja ein set mit optionalen Paramatern abbieten, Vereinbarung wäre dann: wenn halt Feature xyz unterstützt wird dann bitte so und wenn es nicht unterstützt wird dann zusätzliche Parameter ignorieren.

Zum tts: wenn man da tiefer reinschaut gewinnt es wie alles andere auch an Komplexität: Thema zum Beispiel "was mache ich unterdessen mit der wiedergabe die gerade läuft ? pause ? muten ? Wie laut wird ge-tts't ? Signalton dazu ?".

Schlage sowas vor (tts):

say "Text zum sagen", [volume=0..100], [pause|mute], [Sprache=de-de], [Msg=Info|Warning|Error|Alarm|...], [weitere Devicespezifische Parameter wenn notwendig]

Damit kann der Modulautor dann machhen was er will, mindestens say "bla" soll immer gehen (wenn tts geht) und wenn zum Beispiel Volume auch unterstützt wird dann bitte so wie vereinbart. Wenn das Modul den Parameter Volume nicht auf dem Device setzen kann dann bitte ignorieren ohne den Programmverlauf zu unterbrechen (vielleicht warning oder info im log, mehr nicht). Andersrum sollte jedes Modul auch mit dem minimalen say "bla" arbeiten können und die notwendigen Parameter intern mit defaults füllen.

Grüße
Jörg

[Markus Bloch]

das tts-feature impliziert aber auch, das sämtliche device-module forken müssten (via BlockingCall) um während der Generierung und Wiedergabe des Files nicht den ganzen FHEM Hauptprozess zum Stillstand zu bringen.

[justme1968]

nicht unbedingt...

es würde z.b. reichen wenn genau ein modul in der lage ist das im hintergrund zu machen und dann diese funktionlität per notify allen anderen zur verfügung stellt.

im übrigen sind eine ganze menge dinge auch per select möglich. im itunes module hab ich mich auch lange um einen synchronen status gedrückt und es nur per polling implementiert weil ich dachte es geht nicht ohne blocking call... es funktioniert aber ganz wunderbar per select.

es muss auch nicht unbedingt text to speech sein. bei den video modulen wie z.b. xbmc kann die nachricht ja auch per text eingeblendet werden.

gruss
  andre