einheitliche kommandos für av geräte

[justme1968]

ich hab die tabelle eben etwas vereinfacht. ich hoffe ich hab dabei keine falschen symbole eingebaut.

bitte schaut jeder noch mal kurz drauf.

gruss
  andre

[Markus Bloch]

Passt soweit,

allerdings würde ich es toll finden, wenn du die zwei neuen set-Befehle "repeat" und "shuffle" noch in der Tabelle im Kapitel "Kommandos" einträgst inkl. möglicher Parameter und einer kurzen Erklärung.

Viele Grüße

Markus

[TeeVau]

Hallo,

ich probiere es heute Abend mal bei mir aus, wie es sich mit 5% Änderung bei Volume verhält. 10% werden bei dem TV zu viel sein (TV gucke ich so bei 20-23, auf 16 schalte ich für Hintergrundgedudel). Ich befürchte bei 10% Änderung hätte ich nur laut oder leise :-)

Aber die Alternative die Schrittweite per Attribut volumeStep zu ändern finde ich gut! Das wäre eben sehr flexibel und in Abhängigkeit der unterschiedlichen Geräte kann jeder Modulauthor bzw. Benutzer den Schrittwert so setzten, wie er es benötigt.
Somit hätten wir keinen festen Wert der z.B bei XBMC total Super passt, bei anderen Geräten aber eigentlich zur Funktion Mute/unmute führt.

[Markus Bloch]

Dann lasst uns die Festlegung "volumeUp"/"volumeDown" muss um X % erhöhen/veringern aus der Guideline entfernen. Jeder Entwickler sollte dann entsprechende Volume-Steps verwenden die nachträglich durch ein Attribut verändert werden kann.

Attribut-Bezeichnungen würde ich hier allerdings nicht in der Guideline aufnehmen wollen, da die ja nichts mit remoteControl, LightScene usw. am Hut haben.

Viele Grüße

Markus

[justme1968]

es spricht doch aber auch nichts dagegen das attribut fest zu legen oder ?

der default kann ja trozdem modulspezifisch sein, der name des attributes um es einzustellen aber fest.

die version mit optionalem parameter finde ich trozdem immer noch sinnvoll fürs direkte programmieren aus einen notify z.b.

gruss
  andre

[justme1968]

ich habe die letzen vorschläge mal in die wikiseite eingepflegt. dabei habe ich den optionalen paramter für volumeUp und volumeDown mit dokumentiert und die alternative version eines kombinierten message komandos statt sayText und showText.

Ich habe als empfehlung noch dokumentiert das der inhalt eines readings sich als argument eines zugehörigen set verwenden lassen sollte. in dem zusammenhang sind mir die diversen current... readings aufgefallen. ist das current wirklich nötig und sinnvoll oder könnte es nicht einfach weg gelassen werden?

gruss
  andre

[Markus Bloch]

wollte grad nachschauhen, aber das Wiki ist grade down.

Gute Nacht

Gruß
Markus

[Markus Bloch]

Die Readings "currentInput" und "currentOutput" würde ich schon zu "input" und "output" ändern. Bei Artist, Album, Title und Media bin ich leidenschaftslos.

Den Rest find ich gut und werde ich auch so umsetzen in meinem Modul.

Viele Grüße

Markus

[Markus Bloch]

Da ja aktuell alle am umsetzen sind, habe ich einfach mal das Baustellensymbol aus dem Wiki-Eintrag entfernt, da nicht mehr an der Guideline geschraubt wird.

Viele Grüße

Markus

[Loredo]

Hi all,

ich habe jetzt das ENIGMA2 Modul vollständig konform zu eurer Guideline umgebaut.
Kann mir jemand sagen, ob ich das alles richtig umgesetzt habe?

Link


Gruß
Julian

[Markus Bloch]

Hi Julian,

hab soeben mal drübergeschaut. Sieht meiner Meinung nach gut aus. Mir ist jedenfalls nichts negatives aufgefallen.

Viele Grüße

Markus

[Loredo]

Danke!

Ich bin/war unsicher insbesondere wegen des channel.
Ich zeige dort den aktuellen Kanalnamen oder den Videonamen an. Mit diesen funktioniert aber der channel Set-Befehl nicht. Man kann beim channel-Befehl zwar die Service Referenz (z.B. 1:0:19:75:A:85:C00000:0:0:0:) oder eine Kanalnummer zwischen 1 und 9999 angeben. Aber da die Service Referenz so unleserlich ist wollte ich sie nicht nehmen, da ich vermute, dass das channel-Reading eher für die Anzeige irgendwo geeignet sein sollte. Die aktuelle Kanalnummer kriege ich nicht ausgelesen, aber irgendwie erscheint mir das auch zu wenig als Wert für das channel-Reading.

Ich denke den Kanalnamen anzuzeigen ist hier die beste Lösung, oder?


Gruß
Julian

[henryk]

Moin,

für lightScene wäre es mir wichtig wie ich den aktuellen zustand festhalten und wieder her stellen kann.

Wie ist denn da der aktuelle Status bezüglich LightScene und A/V-Geräten, oder komplexeren Geräten generell? Für mein Epson-Beamer-Steuerungsmodul (70_ESCVP21) hab ich mir das so gedacht, dass das set-Kommando auch Werte der Art status-eingang akzeptiert, damit LightScene out of the box (mit einem entsprechend angereicherten state in get) funktioniert. Für noch komplexere Dinge muss man aber wohl LightScene (und ggbf. die Module) anfassen. In keinem Fall will man wohl irgendeine Geräte-spezifische Sonderlogik in LightScene.

Grade dachte ich an ein Attribut ("scene_parameters" oder so) mit einer Liste von get-Parametern. Zum sichern müsste LightScene dann die Parameter alle mit get ... abfragen, und beim wiederherstellen mit set ... ... zurück setzen. Vorteil des Attributs: Der User kann da so viele oder wenige Geräte-Zustands-Aspekte einschließen wie er möchte. Der Modul-Autor muss nur sicherstellen, dass korrespondierende get/set-Paare verfügbar sind. Man kann sich dann sogar überlegen, das Attribut nicht (nur) auf dem Gerät zu erlauben (wo es der Modul-Autor ggbf. sogar einen Default-Wert zur Verfügung stellen kann), sondern auch auf dem LightScene-Objekt erlauben, eine Liste von Gerätenamen-Attributlistenpaaren zu setzen. Dann kann das gleiche Gerät in mehreren Scenen verwendet werden wobei zu jeder Scene unterschiedliche Aspekte beitragen dürfen.

Einziger Nachteil hier: Sichern und Wiederherstellen erfordern eine Reihe von get/set-Kommandos.

am liebsten wäre mir eine set commando oder eine funktione die z.b. an/aus, lautstäreke, kanal, playlist und was auch immer nötig ist auf einen schlag einzusammeln und das entsprechende gegenstück um genau den zustand wieder her zu stellen

Das ist natürlich auch schön. Man würde ein neues Kommandopaar definieren (get sceneState, set sceneState ...) welches, wenn implementiert, eine kompakte Repräsentation des aktuellen Zustands zurückliefert bzw. wieder einliesst und setzt (je nach Gerätefähigkeiten könnten die beiden Operationen sogar atomar implementiert sein, ein Vorteil gegenüber der Variante mit einzelnen gets und sets). Nachteile: Erfordert nicht nur an LightScene sondern auch an jedem einzelnen Modul Modifikationen (die obige Variante würde mit den meisten Modulen ohne weitere Veränderungen funktionieren), ist mehr Aufwand (lässt sich durch entsprechende Bibliotheksfunktionen stark reduzieren) und lässt die Flexibilität vermissen, die eine frei konfigurierbare Parameterliste hätte. Letzteres kann man durch noch mehr Komplexität kompensieren: get sceneState ... mit einer Parameterliste als zusätzlichem Argument die entweder aus dem Geräte- oder dem Scene-Attribut (siehe oben) kommt. Das zurückgelieferte Format muss dann derart sein, dass bei set sceneState ... erkannt werden kann, welche Parameter gesetzt werden sollen.

--
Henryk Plötz
Grüße aus Berlin

[justme1968]

lightscene kann zur zeit 'out of the box' nur geräte die ihren eigenen state als set verstehen. das funktioniert und wird auch schon an einigen stellen mit av geräten eingesetzt. für dinge bei denen das nicht reicht, aber immer noch ein einziges set genug ist kann man von hand das kommando per set setzen.

bis jetzt gibt es eine sonderbehandlung für die hue devices. dort sind immer zwingend zwei paramter nötig um den zustand zu speichern und wieder her zu stellen. da habe ich es so gelöst das die lightscene weiss welche beiden parameter zu speichern sind und das hue modul kann eine beliebige anzahl an set mit : getrennt auf einen schlag entgegen nehmen. also eine art erweiterung des set damit es atomar mehrere parameter entgegen nehmen kann.

ersteres (d.h. eine sonderbehandlung für jedes kompliziertere device) möchte ich auf jeden fall vermeiden.

letzteres (d.h. mehrere set auf einen schlag auszuführen) ist eigentlich auch für andere dinge sehr nützlich weil das kommando dann tatsächlich auf ein mal abgearbeitet werden kann (z.b. eingang wählen und lautstärke setzen). ich fürchte aber das lässt sich nicht so einfach und vor allem rückwärts kompatibel im fhem einbauen. es steht natürlich jedem modul frei das für sich zu machen.

zu deinem vorschlag mit den attributen: wenn man das mit den mehrfach set von oben kombiniert ist der nachteil der mehrfachen set nicht mehr vorhanden. nur noch der mehrfachen get. das stört aber nicht so sehr und wenn doch liesse es sich mit der gleichen methode verhindern.

ein wichtiger punkt der hier noch fehlt ist aber das die liste der zu sichernden parameter nicht nur vom benutzer sondern auch vom aktuellen zustand abhängen kann.

je länger ich darüber nachdenke um so besser gefällt es mir. sogar ohne atomares set und get. ich glaube ich baue das einfach mal in lightscene ein. dann kann man testen ob es wirklich so gut funktioniert. module die ein atomares set brauchen können das ja unabhänigig davon bereit stellen.

das ganze lässt sich ja auch mit den speziellen get sceneState und set sceneState kombinieren wenn die tatsächlich trozdem nötig sein sollten. dann gibt man einfach sceneState als scene_parameter an.

gruss
  andre

[justme1968]

anbei eine erste version die die idee von oben umsetzt. es gibt damit ein neues attribut lightSceneParamsToSave das in jedem device gesetzt werden kann dessen zustand in einer lightLightScene gesichert werden soll. das attribut gibt eine liste der readings die gesichert und später dann mit einem gleichnamigen set wieder hergestellt werden. der string kann entweder direkt als string oder als perl in {} eingeschlossener perl ausdruck der genau einen solchen string zurückgibt angegeben werden. readings die mit doppelpunkt statt komma getrennt sind werden zu einem einzigen set zusammen gefasst. das muss von device untgerstütz werden.

zwei beispiele

Code Auswählen Erweitern

attr myReceiver lightSceneParamsToSave volume,channel
attr myHueDevice lightSceneParamsToSave {(Value($DEVICE) eq "off")?"state":"bri : xy"}

die fertige version wird noch ein zweites attribut unterstützen um eventuell unterschiedliche namen von reading und set zuzuordnen und die möglichkeit statt readings get kommandos zu verwenden um einen status abzufragen.

gruss
  andre

edit: ich habe das file noch mal aktualisiert. in der liste können jetzt auch einträge der form 'abc -> xyz' oder 'get cba -> set uvw' vorkommen um das reading abc auf ein set xyz oder den wert eines get cba auf ein set uvw zu mappen.