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
Hi,
bin dafür :)
Wir könnten einen neuen Entrag unter http://www.fhemwiki.de/wiki/Kategorie:Development (//www.fhemwiki.de/wiki/Kategorie:Development) platzieren.
=8-)
plus 1 für die Idee
generell währe ich auch dafür, allerdings dann eben nur mit lowelCamelCaps wie in http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Bezeichnungen (//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
Finde die Idee sehr gut.
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 (//www.fhemwiki.de/wiki/DevelopmentGuidelinesAV).
gruss
andre
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
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
Zitat von: Markus Bloch schrieb am Do, 18 Juli 2013 16:17Je 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
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
Zitat von: justme1968 schrieb am Do, 18 Juli 2013 16:56ja. 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.
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
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
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.
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
Blocking/fork ist ein anderes Thema, außerdem blockt nix wenn das device selber tts kann.
Grüße
Jörg
mir persönlich ist kein Gerät bekannt, was sowas von Haus aus mitbringt. Selbst in SONOS wird das ganze über Google generiert und dann an das Device gestreamt.
Viele Grüße
Markus
Hi,
die hier gewählte Struktur gefällt mir auch gut - bin aber ncht sicher wie weit sich das mit bestehenden Modulen deckt.
Link (http://forum.fhem.de/index.php?topic=13774.msg86564#msg86564)
Gruß, Uli
*grübel* ich denke grade über remotecontrol, LISTENLIVE und einheitliche Kommandos nach, da kam mir folgende Frage in den Sinn:
(http://up.picr.de/15272168hs.png)
wie können/sollen eigentlich mit remotecontrol mehrfach belegte Tasten abgebildet werden?
Bei der abgebildeten Fernbedienung kann man sehen, dass die Cursortasten verschiedene Funktionen haben, je nachdem wo man sich gerade in der Gerätenavigation befindet.
Zum Beispiel kann "Pfeil nach oben" einmal wirklich die Bewegung nach oben sein, aber auch die Funktion "Lauter" wenn grade irgendwas abgespielt wird.
Btw: könnte man diesen Thread bei Gelegenheit ins Multimedia-Forum verschieben? Ich muss den jedesmal suchen...
zur zeit kann die remote keine mehrfach belegten tasten. jede taste ist immer genau mit einem kommando verknüpft. wenn dein device abhängig vom zustand dann unterschiedliche aktionen durchführt entspricht das verhalten im prinzip dem der original fb.
diese mehrfach belegung hat aber eigentlich den hintergund das es unübersichtlich und aufwändig wird auf einem so kleinen plastik ding viele tasten unterzubringen.
in fhem ist es meiner meinung nach besser pro kommando genau eine funktion zu haben. also ein mal volume und ein mal cursor. wobei cursor eigentlich eh gar keinen sinn macht weil man das device über fhem ja normalerweise genau dann bedient wenn man es nicht im blick hat.
was ich für die remotecontroll in fhem gerne umsetzen möchte ist das sie zum einen feedback geben kann und zum anderen das layout dynamisch sein kann. mit dem ersten meine ich das z.b. die play taste 'leuchtet' wenn der status play ist oder man ein sender logo einblenden kann. letzteres würde mehrfach belegte tasten überflüssig machen da immer nur die tasten da sind die gerade sinnvoll sind. beides geht aber zur zeit noch nicht.
gruss
andre
Zitat von: justme1968 schrieb am Di, 23 Juli 2013 15:25wobei cursor eigentlich eh gar keinen sinn macht weil man das device über fhem ja normalerweise genau dann bedient wenn man es nicht im blick hat.
Das sagst Du so in Deinem jugendlichen Leichtsinn...
Es geht ja noch härter: Ich habe hier ein Gerät von Alesis stehen, da muss man sogar gleichzeitig zwei Tasten drücken, um eine bestimmte Funktion - völlig unabhängig von den Einzelfunktionen der beiden Tasten - auszulösen.
das aber dann auf einer viruellen fernbedienung nachzubilden statt dafür eine eigene taste zu spendieren wäre einfach unsinnig...
ich kann Dich beruhigen, das kriegst Du auch über eine eigene Taste nicht abgebildet :) Abgesehen davon, dieses Gerät keine Steuerung von außen zulässt.
ich habe mal im Wiki die Readings mit einer Beschreibung und möglichen Werten gespickt. Ich hoffe das ist in eurem Interesse.
Ich finde, dass wir so etwas auch bei den Set-Befehlen und Get-Befehlen machen sollten.
Viele Grüße
Markus
zum Thema "mehrfach belegte Tasten" bin ich der Meinung, dass die Hersteller da selber schon mitgedacht haben und solche Shift-Funktionen in einer App, oder in so einem Interface mit einem eigenen Befehlsnamen direkt ansprechen werden, wodurch das auch kein Hexenwerk darstellen sollte.
wer kann eigentlich Icons so erstellen, dass sie zu den vorhandenen passen? Ich kann das nicht - grafisches Gestalten war noch nie meine Stärke.
Ich bräuchte noch ein paar Buttons, um das Layout für Xoro HMT350 zu erstellen.
Ich ebenfalls für Yamaha Receiver
Um mal konkret zu werden - mir fehlen für alle mit Ziffern gekennzeichneten Tasten ein Symbol:
(http://up.picr.de/15277749ka.png)
1 = Home (vielleicht mit einem schönen Häuschen-Symbol?
2 = TV out
3 = Page Up
4 = Internet TV
5 = Page Down
6 = Internet Radio
7 = FAV
8 = Repeat
9 = EQ
falls mal jemand Zeit und Lust hat :)
Zitat von: Markus Bloch schrieb am Di, 23 Juli 2013 19:19ich 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)
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.
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.
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
Zitat von: justme1968 schrieb am Mi, 24 Juli 2013 10:33STATE sollte der anwender mit stateFormat überschreiben können. im modul sollte nur state verwendet werden.
wird auch.
Zitat von: betateilchen schrieb am Di, 23 Juli 2013 23:41Um 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:
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.
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)
Zitat von: betateilchen schrieb am Mi, 24 Juli 2013 09:27Zitat von: Markus Bloch schrieb am Di, 23 Juli 2013 19:19ich 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
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
Ja saubere Sache. Sieht schonmal gut aus. Jetzt bräuchten wir so eine Tabelle noch für die Set- und Get-Kommandos.
Gruß
Markus
Hab im Wiki mal wieder ein paar Vorschläge eingebaut.
Was meint ihr dazu?
Viele Grüße
Markus
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
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 (http://forum.fhem.de/index.php?topic=14057.0).
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
Hallo Tobias,
Zitat von: TeeVau schrieb am Do, 01 August 2013 11:22Als 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.
Zitat von: justme1968 schrieb am Do, 01 August 2013 11:48kur 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
Zitat von: justme1968 schrieb am Do, 01 August 2013 11:484. 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
Zitat von: Markus Bloch schrieb am Do, 01 August 2013 15:29dennoch 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.
Zitat von: Markus Bloch schrieb am Do, 01 August 2013 15:29Den 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.
Zitat von: betateilchen schrieb am Do, 01 August 2013 19:29Nochmal: 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
Zitatweiterhin 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.
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.
Zitat von: Markus Bloch schrieb am Do, 01 August 2013 22:51nur sollen die Bezeichnungen lowerCamelCaps sein ohne Unterstriche (meiner Meinung nach)
*dafür*
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.
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 :-)
Habe den Artikel im Wiki mal mit ein paar Vorschlägen gefüllt.
Sieht gut aus, ich hab hier den Parameter Volume noch einmal etwas präzisiert.
Viele Grüße
Markus
Zitat von: TeeVau schrieb am Do, 01 August 2013 23:12Aber 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.
Zitat von: TeeVau schrieb am Do, 01 August 2013 23:12Dein 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!
Zitat von: TeeVau schrieb am Do, 01 August 2013 23:12Das 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.
Zitat von: betateilchen schrieb am Fr, 02 August 2013 08:50Du 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?
Zitat von: betateilchen schrieb am Fr, 02 August 2013 08:50Fü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?!
[quote title=TeeVau schrieb am Fr, 02 August 2013 10:55]
Zitat von: betateilchen schrieb am Fr, 02 August 2013 08:50Welche 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.
Zitat von: betateilchen schrieb am Fr, 02 August 2013 08:50Sind 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.
Zitat von: betateilchen schrieb am Fr, 02 August 2013 13:05Meine 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....
ich hätte lightScene, iTunes und eventuell xbmc (das scheint grad keinem zu gehören) beizusteuern :)
gruss
andre
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.
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
für lightScene wäre es mir wichtig wie ich den aktuellen zustand festhalten und wieder her stellen kann.
bei lampen und dimmern geht das ja fast immer per state und dann genau den state wieder per set herstellen.
bei den av geräten geht das nicht.
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.
eine option für das wieder her stellen wäre auch beim set mehr als ein kommando z.b. mit einem doppelpunkt als trennzeichen zu akzeptieren (siehe HUEDevice).
gruss
andre
Zitat von: justme1968 schrieb am Do, 01 August 2013 11:48zu 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.
Generell könnte man das durchaus so machen. Aber ich denke wenn man diese beiden Befehle so getrennt lässt, weis der User direkt was der Befehl macht. Die Bezeichnung "message" währe da ja etwas allgemeiner gehalten.
Gibt es evtl. Geräte die beides können? Also Text vordudeln und auf nem TV oder einem internen LED-Display ausgeben?
Gerade bei dem Text vorspielen müsste ich mal beim SONOS Modul demnächst spicken, wie das dort genau umgesetzt ist. Bei YAMAHA z.B. könnte man ein generiertes File an den Receiver schicken, dann würde er aber den bestehenden Kanal wechseln und z.B. vom Fernseher-Kanal auf Streaming umschalten und damit auch das Bild umschalten.
Viele Grüße
Markus
der witz wäre ja gerade das man vorher nicht wissen muss ob das gerät das eine oder das andere kann. z.b. das gleiche kommando egal welches gerät gerade an ist.
message war auch nur ein vorschlag weil mir gerade nichts besseres eingefallen ist.
gruss
andre
Zitat von: Markus Bloch schrieb am Fr, 02 August 2013 16:03Gibt es evtl. Geräte die beides können? Also Text vordudeln und auf nem TV oder einem internen LED-Display ausgeben?
Es gibt sogar Geräte, die noch mehr können:
message text (Popup auf dem bestehenden Screen)
message speech (Sprachausgabe)
message image (Meldung als Image auf dem Screen anzeigen)
Und schon sind wir wieder bei strukturierten/gruppierten Kommandos *duck-und-weg*
Zitat von: betateilchen schrieb am Fr, 02 August 2013 16:45Zitat von: Markus Bloch schrieb am Fr, 02 August 2013 16:03Gibt es evtl. Geräte die beides können? Also Text vordudeln und auf nem TV oder einem internen LED-Display ausgeben?
Es gibt sogar Geräte, die noch mehr können:
message text (Popup auf dem bestehenden Screen)
message speech (Sprachausgabe)
message image (Meldung als Image auf dem Screen anzeigen)
Welche Geräte sind denn das genau, an die du da denkst? Gerade in einem solchen Fall wo text, speech und image unterstützt wird müsste man das schon als Befehl differenzieren.
Btw: Eine andere Frage, was haltet ihr davon ein Reading "CommandAccepted (yes|no)" einzufügen? Viele Geräte bestätigen einem ja meistens die gesendeten Befehle. Ich persönlich verwende das Reading in meinem FHEM System nicht wirklich, aber evtl. besteht ja Interesse daran.
Viele Grüße
Markus
ich würde das message dann so definieren wollen das das ziel ein 'vorschlag' ist oder priorität haben sollte und auf einen anderen kanal ausgewichen wird wenn dieser nicht vorhanden ist.
gruss
andre
Zitat von: Markus Bloch schrieb am Sa, 03 August 2013 11:58ein Reading "CommandAccepted (yes|no)" einzufügen? Viele Geräte bestätigen einem ja meistens die gesendeten Befehle.
warum dann nicht gleich ein Reading, in dem die Antwort des Gerätes steht? Bei mir heißt das Reading dafür lastResult (genau wie es ein Reading "lastCmd" gibt, in dem der abgesetzte Befehl steht)
lastResult und lastCmd halte ich im Zusammenhang mit einer Vereinheitlichung von AV-Modulen für nicht zielführend, da ja jedes Gerät/Modul andere Rückgabewerte erhält, bzw. andere Befehle sendet.
Als Beispiel bei Yamaha würde lastCmd ein ca. 40 Zeichen lange XML-Struktur beinhalte.
Da lastResult und lastCmd sehr Hersteller/Geräteabhängig würde ich sowas hier nicht aufnehmen wollen, ist aber dem Modulentwickler natürlich freigestellt so etwas zusätzlich anzubieten.
Ein "CommandAccepted" Reading währe dennoch modulübergreifend gleich, obwohl hier unterschiedliche Geräteantworten/-returncodes zum tragen kommen.
Viele Grüße
Markus
Zitat von: Markus Bloch schrieb am So, 04 August 2013 19:21Ein "CommandAccepted" Reading
Welchen Nutzen hat das?
Falls ein Fehler bei der Ansteuerung auftritt, muss der sowieso schon im Modul selbst abgefangen werden.
Ich halte den Namen des Readings in diesem Zusammenhang für absolut unsinnig, zumal er mit einem bereits bestehenden Reading bei HomeMatic-Geräten in Konflikt steht.
Ist ja auch nur ein Vorschlag.
Es war auch nur eine Frage. Was willst du mit so einem Reading in der Praxis anfangen?
Ich persönlich hab dafür keinen Einsatz. Daher die Frage ob es evtl. andere brauchen. Ich hatte es daher bewusst an das Reading von HomeMatic angelehnt.
Wenn es keiner braucht, lassen wir es.
Viele Grüße
Markus
Ich wüsste nicht wie ich das reading in meinem Modul z.B. nutzen soll. Falls ein set/get Befehl, der zwar in der AV Guideline beschrieben aber vom Gerät nicht unterstützt wird, gebe ich eine entsprechende Meldung im return() aus.
Da es jetzt ja etwas ruhiger um das Thema geworden ist, wäre es sicherlich nicht verkehrt dem Vorschlag von betateilchen zu folgen und die Punkte der Guidline umzusetzen. Oder was sagt der Rest dazu?
Falls ein Gerät ein Reading auch durch Nachimplementation im Modul nicht liefern kann, sollte es auch nicht leer befühlt werden.
Also nur die Readings liefern die möglich sind.
Ist zumindest meine Meinung
Viele Grüße
Markus
Also ich wollte anfangen sobald die folgenden Fragen geklärt sind:
- Inhalt des state-Readings (power, presence, ....)
- Coverart, wie genau soll es funktionieren
Beim Umsetzen ist mir auch noch folgendes aufgefallen. In FHEMWEB kann ein slider immer nur einen festen Wertebereich haben, daher müssen wir entweder ein neues Kommando volumeStraight verwenden (hab ich im Wiki einfach mal so reingesetzt) oder wir lassen nur noch volume mit Prozentangaben.
Wie ist eure Meinung dazu?
Gruß
Markus
Hallo,
bei der Lautstärke schließe ich mich dem Vorschlag an. Die Lautstärke nur von 0-100% einstellbar machen, kann bestimmt bei dem ein oder anderen zu Schwierigkeiten führen, wenn das Gerät selber eben mit dB Werten arbeitet. Da wird die umgewöhnung von dB auf Prozent mehr ärger bereiten als nutzen.
Von daher ist die Idee gut, generell "Volume" als prozentualen Wert zu nehmen, was für jedes Gerät dann verwendet werden kann. Nutzt jemand lieber den Wert, mit dem das Gerät eigentlich arbeitet, ist VolumeStraight das Mittel der Wahl.
Bei dem Inhalt von state gab es die Vorschläge on/off oder absent/present.
Ich selber habe mich damals für on/off entschieden, da in einer anderen Guidline stand im STATE soll das stehen, was aktuell vom Gerät für den Nutzer am "sinnvollsten" ist. Deshalb gab es on und off im Sinne der Benutzbarkeit. On = Gerät kann benutzt werden, off = Gerät komplett aus (Kein standby).
Bei listenlive und auch den anderen Geräten gibt es eben noch ein standby bzw. gewünscht absent/present.
Wie wäre die Einigung, dass im Reading state on/off/absent/present steht?
- On = Gerät ist eingeschaltet und zur zweckmäßigen Verwendung betriebsbereit, kann auch Befehle empfangen
- Off = Gerät ist ausgeschaltet und nicht zur zweckmäßigen Verwendung betriebsbereit, kann keine Befehle empfangen
- present = Gerät ist ausgeschaltet und nicht zur zweckmäßigen Verwendung betriebsbereit, kann aber Befehle empfangen
- absent = Gerät ist ausgeschaltet und nicht zur zweckmäßigen Verwendung betriebsbereit, kann keine Befehle empfangen.
off und absent sind eigentlich gleich, meiner Meinung nach ist present auch das selbe wie "standby", aber ich denke die Benennungen sind in Modulen teilweise schon vorhanden, dass es wenig Sinn macht die Bezeichnungn zu ändern.
Wie währe es denn dann mit folgenden Vorschlag zu state:
on - Gerät ist empfangsbereit und eingeschaltet
off - Gerät ist empfangsbereit und ausgeschaltet
absent - Gerät ist nicht empfangsbereit.
So hätte man sowohl den Benutzungsstatus als auch die Anwesenheit/Empfangsbereitschaft.
@betateilchen: Währe das für dich ein gangbarer Weg?
@rest: Was haltet ihr davon?
Gruß
Markus
ich finde es gut.
gruss
andre
weitere Meinungen?
Ich kann damit als Kompromiss leben und würde es so einbauen.
Ich habe es mal ins Wiki aufgenommen und noch eine kleine Änderung an den Volume-Sachen durchgeführt, damit die Slider in FHEMWEB anschließend auch den aktuellen Status verwenden.
Viele Grüße
Markus
Eine weitere Baustelle die ich sehe ist bei den set-Kommandos "channel" und "input".
Es werden die beiden set-Kommandos "input" (für den Eingangskanal z.B. hdmi1, usw.) und ein Kanal "channel" (für den TV-Kanal bei DVB-T/DVB-S,....). Allerdings gibt es nur ein Reading "channel". Wobei das auch schwammig formuliert ist, was dieses Reading beinhalten soll.
Dennoch sollte auch ein Reading "input" existieren um den aktuellen Eingangskanal zu ermitteln.
Viele Grüße
Markus
es sollte jeweils zum channel und Input set das zugehörige reading geben.
ob es channel und/oder input gibt sollte vom jeweilligen device abhängen und ist unter umsänden auch dynamisch. d.h. wenn ein avr auf input tuner steht gibt es channel, wenn er auf cd steht vermutlich eher nicht.
bei einem modul wie z.b. itunes wird es vermutlich nur currentArtist/Album/Title geben.
gruss
andre
Ich sehe es auch so. Für channel und input muss es auch ein Reading geben, soweit das Gerät es zulässt, diese Information auszulesen.
Channel kann ja eigentlich alles sein, abhängig vom Gerät bzw. aktueller Funktion des Gerätes. Es macht Sinn, dass nicht auf Fernsehkanal festzulegen, oder?! Bei einem Radio kann es z.B. ja ein Speicherplatz sein (Die URL würde ja in currentMedia stehen).
Habe im Wiki eine Tabelle erstellt, die darstellt welche Funktionalitäten zur Zeit implementiert sind.
Habe meine Infos aus der commandref genommen. Wäre super, wenn jeder Modulauthor das für sein Modul ergänzt.
Ich bin gerade bei der Implementierung.
Eine kurze Frage nochmal zu volume. Sollten die Readings das Einheitensymbol mit beherbergen, oder nicht?
Also
Zitatvolume: 10 %
volumeStraight: -70 dB
oder ohne Einheiten?
Ich reiche meine Sachen in Kürze nach.
Viele Grüße
Markus
Zitat von: Markus Bloch schrieb am Do, 15 August 2013 14:27oder ohne Einheiten?
Hi,
darum gab es vor 1-2 Jahren extensive Diskussionen in der devel-Gruppe.
Ergebnis: Alles ohne Einheiten.
(Ich hoffe ich vereinfache hier nicht zu stark - so hab ich das wahrgenommen).
Geschrieben steht das m.W. nur bezgl. readings:
http://www.fhemwiki.de/wiki/DevelopmentGuidelinessiehe E8 ganz unten
Gruß, Uli
ist die 1% schrittweite bei volumeUp und volumeDown wirklich handlich?
wären 10% oder 5% nicht ein besserer default? und zusätzlich ein optionaler parameter um die schrittweite anzugeben?
gruss
andre
Hab ich gerade mal ausprobiert. 5% finde ich in Ordnung (kam mir auch erst etwas wenig vor). 10% ist zuviel meiner Meinung nach.
Ich würde die Schrittweite wenn dann als Attribut festlegen: z.B. "volume-step" oder ähnlich.
Optionale Parameter in FHEMWEB als Dropdown darzustellen ist mir nicht bekannt.
Viele Grüße
Markus
im web muss man sich entscheiden ob das set einen paramtere hat oder nicht. das stimmt.
wenn man es aber im code verwendet stehen immer beide varianten offen.
gruss
andre
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
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
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.
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
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
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
wollte grad nachschauhen, aber das Wiki ist grade down.
Gute Nacht
Gruß
Markus
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
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
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 (http://forum.fhem.de/index.php?topic=14792.msg95599#msg95599)
Gruß
Julian
Hi Julian,
hab soeben mal drübergeschaut. Sieht meiner Meinung nach gut aus. Mir ist jedenfalls nichts negatives aufgefallen.
Viele Grüße
Markus
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
Moin,
Zitat von: justme1968 schrieb am Fr, 02 August 2013 16:02fü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.
Zitat von: justme1968 schrieb am Fr, 02 August 2013 16:02am 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
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
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
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.
ich habe diese version mit einer zusätzlichen erweiterung die es erlaubt die reading werte noch zusätzlich zu verändern eben eingecheckt.
gruss
andre
AV-Receiver haben mehrere Audio/Video Ausgänge, die auch in unterschiedlichen Räumen sein können -> "Zonen".
Wie sollen Zonen implementiert werden?
YAMAHA_AVR implementiert jede Zone als eigenes Gerät (mit "Main Zone" als default).
Gibt es dazu bereits einen Konsens? Meinungen?
Grüße
50watt
ich denke zonen lassen sich in fhem nur als eigene devices wirklich vernünftig handhaben. nur so bekommst man eigene icons, webCmds oder die zuordnung zu räumen.
gruss
andre
Zumal man auch jede Zone unabhängig von anderen Zonen einschalten kann, ist es denke ich die logischste und einfachste Variante. Man kann die Zone über das jeweilige Device anderen Räumen zuordnen, separat ein-/ausschalten, unabhängig die Eingänge wechseln, etc.
Das alles in einem Device erachte ich als sehr kompliziert und nicht intuitiv.
Gruß
Markus
Exakt. Daher haben es bisher auch alle so umgesetzt.
Es scheint einen Konsens zu geben ;-)
Wollen wir "Zonen" nicht in die DevelopmentGuidelinesAV (http://www.fhemwiki.de/wiki/DevelopmentGuidelinesAV) unter "Sonstiges" aufnehmen?
Textvorschlag:
Zonen
AV-Receiver haben mehrere Audio/Video Ausgänge, die auch in unterschiedlichen Räumen sein können -> "Zonen".
Jede Zone soll als eigenes Gerät, mit "main" als Default-Zone, definiert werden.
"statusRequest" -> "get" oder "set"?
Aus DevelopmentModuleIntro (http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#X_Get) entnehme ich:
ZitatMit get werden typischerweise Werte von einem Gerät abgefragt.
ZitatDie Set-Funktion ist das Gegenteil zur Get-Funktion. Sie ist dafür gedacht, Werte zum physischen Gerät zu schicken.
Sollte demnach das Kommando "statusRequest" nicht ein
get statusRequest sein (und nicht wie in DevelopmentGuidelinesAV (http://www.fhemwiki.de/wiki/DevelopmentGuidelinesAV#Kommandos) ein
set statusRequest)?
das statusRequest dort als set beschrieben ist hat zum teil historische gründe. ein weiterer grund ist ist das man es als get nicht in die webCmds tun kann.
bei homematic bzw. anderen devices die per funk angesteuert werden gibt es noch den grund das ein 'set statusRequest' nur die aufforderung zum device sendet und dieses dann selbständig asynchron (und eventuell langsam) den status zurück sendet. ein get würde also dem user nichts zurück liefern können weil die info vom device noch nicht da ist. das sollte aber keines der av devices betreffen.
eigentlich sollte man es also ändern.
und richtigerweise gleich in 'get status', 'get currentStatus' oder 'get statusUpdate' statt 'get statusRequest'. es ist ja im gegensatz zu homematic normalerweise nicht ein request an das device etwas zu senden sondern tatsächlich die abfrage des aktuellen status.
gruss
andre
Zitat von: justme1968 am 05 Mai 2014, 14:03:52
das sollte aber keines der av devices betreffen.
Doch, das ENIGMA2 Modul arbeitet schon asynchron. Das sollen doch mittelfristig ohnehin alle Polling-Devices tun.
Zitat von: justme1968 am 05 Mai 2014, 14:03:52eigentlich sollte man es also ändern.
Ich würde es so belassen. Es ist einfach auch in allen anderen Tausend (überspitzt) Modulen so.
Zitat von: justme1968 am 05 Mai 2014, 14:03:52und richtigerweise gleich in 'get status', 'get currentStatus' oder 'get statusUpdate' statt 'get statusRequest'. es ist ja im gegensatz zu homematic normalerweise nicht ein request an das device etwas zu senden sondern tatsächlich die abfrage des aktuellen status.
Das wäre konsequent, aber wie oben gesagt würde ich es so belassen wollen.
Zitat von: 50watt am 05 Mai 2014, 13:44:38
Textvorschlag:
Zonen
AV-Receiver haben mehrere Audio/Video Ausgänge, die auch in unterschiedlichen Räumen sein können -> "Zonen".
Jede Zone soll als eigenes Gerät, mit "main" als Default-Zone, definiert werden.
Find ich ok.
Ich habe in der Guideline einmal Zonen aufgenommen: http://www.fhemwiki.de/wiki/DevelopmentGuidelinesAV#Wie_funktionieren_Zonen.3F
Passt das soweit aus eurer Sicht?
Gruß
Markus
ich würde definitionen zumindest im ersten satz durch device ersetzen. oder fhem-device.
gruss
andre
habe ich geändert.
ich finde es gut so.
gruss
andre
zum Thema statusRequest:
Zitatdas sollte aber keines der av devices betreffen.
doch, dass Squeezebox Modul arbeitet asynchron. Und wenn man so will dann sogar mehrstufig asynchron.
Der SB_SERVER sendet den statusRequest and den physikalischen SB Server. Und der antwortet dann halt irgendwann, so dass SB_SERVER die Antwort verarbeiten kann. Teile der Antwort betreffen aber nur die FHEM Repräsentation des Servers, andere Teile betreffen die FHEM Rep der Player.
Ob das nun per set oder get ausgelöst wird ist aus meiner Sicht nicht ganz egal. set statusRequest drückt aus meiner Sicht genau aus was passiert: ich setze eine Anforderung zum Status ab.
Aus meiner Sicht wäre folgendes richtig:
set statusRequest --> schickt die Anfrage ab
get status --> gibt dem user den aktuellen Status zurück, sowie ihn das Modul halt kennt
das mit dem umstellen auf asynchron habe ich bei meiner antwort übersehen. das stimmt. es sollte also beim set bleiben.
der aktuelle (bekannte) status sollte im device sichtbar sein und ein einfaches list sollte reichen.
Hallo Zusammen,
ich bastle gerade mithilfe des Dashboards und readingsGroup einen - sagen wir mal einen Multimedia Tab.
Von dort aus kann ich alle verfügbaren Eingangsquellen zu den entsprechenden Ausgängen Mappen und die playerfunktion bedienen. Ich las irgendwann mal das versucht werden sollte möglichst einheitliche befehle zu nutzen.
OK, hier geht es um AV Geräte - mir geht es eher um Audio, aber vielleicht macht es trotzdem sinn das ganze zu erweitern.
Mir fehlen die Player Kommandos skip ff, skip rew, crossfade, record
Welche befehle werden z.b. bei Squezzebox oder iTunes verwendet? Wie läuft das bei ListenLive?
Oder würde es zu weit führen diese player typen & Sonos zu vereinheitlichen?
Gibt es noch mehr Module / Geräte die diese Befehlstypen verwenden?
HI Folks,
Ich weiß, dass ich mit meiner Ergänzung der Guidlines im Wiki für ein stateAV Reading vielleicht etwas voreilig/übereifrig war, deshalb möchte ich formell nochmals auf diesen Beitrag (https://forum.fhem.de/index.php/topic,56904.0.html) verweisen wo erklärt ist, wofür das Reading gut ist.
Ich habe das Reading in all meinen Modulen implementiert und wie im verlinkten Beitrag zu lesen ist auch für SONOSPLAYER einen Workaround bei mir im Einsatz (https://forum.fhem.de/index.php/topic,42116.0.html) (auch wenn stateAV hier aufgrund des SONOSPLAYER Modul etwas von dem Reading in den anderen Modulen abweicht, da es sich an den wichtigen Stellen ohnehin nicht an die AV-Standards hält und es daher für SONOSPLAYER sinnvoll erschien es anders auszulegen).
Seht das hier gerne als Antrag an.
Dementsprechend überlasse ich es gerne der Community meine Wiki Ergänzungen wieder zu löschen.
Gruß
Julian
Ich schlage außerdem noch die Standard-Readings channelList und inputList vor, um diese aus anderen Frontends als Eingabe für die AV-Setter "channel" und "input" verwenden zu können.
Hi Julian,
mit dem Reading stateAV habe ich so meine Bauchschmerzen, es ist zu speziell auf das Abspielen von steuerbaren Eingängen (wie Bluetooth, DLNA, Airplay) ausgelegt. Was sollte der Status bei Eingängen sein, die nicht direkt durch ein Gerät gesteuert wird (bspw. AV1/2/3, PHONO, CD, ...)? In so einem Fall ginge ja nur absent->off->muted->on???
Wozu genau benötigt man die channelList/inputList? Wenn man bei den set-Kommandos die Usage entsprechend dynamisch generiert, dann ist doch die channelList/inputList daraus ableitbar:
Unknown argument ?, choose one of on:noArg off:noArg volumeStraight:slider,-80,1,16 volume:slider,0,1,100 volumeUp volumeDown input:audio,av1,av2,av3,av4,av5,av6,airplay,hdmi1,hdmi2,hdmi3,hdmi4,netradio,server,tuner,usb,v-aux,ipod_usb mute:on,off,toggle remoteControl:setup,up,down,left,right,return,option,display,tunerPresetUp,tunerPresetDown,enter scene:scene1,scene2,scene3,scene4 straight:on,off 3dCinemaDsp:off,auto adaptiveDrc:off,auto direct:on,off dsp:hallinmunich,hallinvienna,chamber,cellarclub,theroxytheatre,thebottomline,sports,actiongame,roleplayinggame,musicvideo,standard,spectacle,sci-fi,adventure,drama,monomovie,surrounddecoder,2chstereo,5chstereo enhancer:on,off sleep:off,30min,60min,90min,120min,last bass:slider,-6,0.5,6 treble:slider,-6,0.5,6 tunerFrequency statusRequest:noArg
Unknown argument ?, choose one of statusRequest:noArg showPairCode:noArg removeP airing:noArg remoteControl:0,1,2,3,3D_L/R,3Dvideo,4,5,6,7,8,9,PiP,PiP_channelDow n,PiP_channelUp,audioDescription,avMode,back,blue,channelDown,channelUp,dash,dow n,energySaving,epg,exit,fastForward,favouriteChannel,green,home,info,input,left, liveTv,mark,menu,mute,myApps,netCast,ok,pause,play,power,prevchannel,proglist,qu ickMenu,ratio,record,recordingList,red,repeat,reservationProglist,rewind,right,s implink,skipBackward,skipForward,stop,subtitle,switchPriSecVideo,teletext,textOp tion,up,volumeDown,volumeUp,yellow channelDown:noArg channelUp:noArg channel:1,2 ,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,19,20,21,22,23,24,25,26,27,28,29,30,31,32 ,33,34,36,38,39,40,41,42,43,44,45,46,47,49,50,51,52,54,58,59,60,61,62,63,65,70,7 2,74,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,100,10 1,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,12 1,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,143,14 4,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,16 4,165,166,167,168,169,170,171,172,173,174,175,176,177,180,181,182,183,189,190,19 1,192,194,195,196,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,21 6,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,23 6,237,238,239,240,242,243,244,245,246,247,248,249,250,251,252,253,254,255,261,26 2,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,28 2,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,30 2,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,32 2,323,324,325,326,327,328,330,331,332,333,334,335,336,337,338,339,340,341,342,34 3,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,36 3,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,38 3,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,403,40 5,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,423,424,425,42 6,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,44 6,447,448,449,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,470,47 1,472,473,474,475,476,480,481,482,483,484,485,486,488,490,491,492,493,494,495,49 6,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,51 6,517,519,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,53 8,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,55 8,562,563,564,567,568,571,573,574 startApp:149,Aufnahmeliste,Benutzerhandbuch,Be rliner_Philharmoniker,Digitale_Videoaufnahme,Dual_Play,Eingangsliste,Einstellung en,Fernsehprogramm,Fotos,HDplusReplay,Internet,Kamera,LG_Smart_World,LOVEFiLM,Ma xdome,Musik,MyVideo,Myspass,Netflix,Neueste_Liste,Prg.Liste,SIMPLINK,Schnellmen, Skype,SmartShare,Spotify,Suchen,UlmAllg,Universalsteuerung,Videoload,Videos,Watc hever,YouTube,Zattoo,tagesschau,wuaki_tv_ui30 stopApp:149,Aufnahmeliste,Benutzer handbuch,Berliner_Philharmoniker,Digitale_Videoaufnahme,Dual_Play,Eingangsliste, Einstellungen,Fernsehprogramm,Fotos,HDplusReplay,Internet,Kamera,LG_Smart_World, LOVEFiLM,Maxdome,Musik,MyVideo,Myspass,Netflix,Neueste_Liste,Prg.Liste,SIMPLINK, Schnellmen,Skype,SmartShare,Spotify,Suchen,UlmAllg,Universalsteuerung,Videoload, Videos,Watchever,YouTube,Zattoo,tagesschau,wuaki_tv_ui30
Ein nachgelagertes Frontend sollte daraus die entsprechenden Listen auslesen. FHEMWEB als Frontend macht ebenfalls nichts anderes. Daher sollten auch Frontends die Usage mittels "set <name> ?" abfragen um die möglichen Werte zu erhalten.
Gruß
Markus
die idee hinter stateAV finde ich im prinzip nicht schlecht. eine reihenfolge mit prioritäten wir z.b. absent -> off -> playing könnte nützlich sein um einfacher in icon anzuzeigen. das steuern per single klick ist aber schon schwieriger. man kann aus off zwar einschalten und auch zwischen play und pause wechseln, aber wieder ausschalten geht schon nicht mehr. mute noch mit rein zubringen halten ich für problematisch. je nach anwendung ist mute höher oder niedriger einzustufen als play. bei einkniff bedienung ist auch nicht eindeutig ob von mute aus nach pause oder nach unmute gewechselt werden soll.
ich vermute es gibt nich mehr solche nicht eindeutigen zustände/anforderungen und die logik ist besser im fronted/widget aufgehoben das jeweils zur steuerung verwendet wird statt es im modul fest zu legen. für fhemweb wäre das tatsächlich ein user reading.
@Markus Bloch: bei den nich gesteuerten eingängen gibt es die prinzipielle frage ob on = play ist und ob state bei diesen statt on play (und pause?) anzeigen sollte. das ist aber glaube ich unabhängig von stateAV.
für channelList/inputList schliesse ich mich markus im prinzip an. warum ein eigenes reading wenn die dynamische set ? liste die gleiche info liefert.
andererseits hat diese liste das problem das bei einer änderung kein event gibt das man im frontend auswerten kann um die darstellung dynamisch anzupassen. wäre es eventuell sinnvoll einen generellen mechanismus zu haben mit dem ein modul das frontend über eine änderung an der set/get/attr liste informieren kann? so eine generelle lösung hätte gegenüber deinen beiden readings noch den vorteil das es auch für alle anderen module und kommandos sinnvoll zu verwenden wäre.
gruss
andre
Ich bin derzeit dabei umfangreiche Veränderungen am STV-Modul vorzunehmen. Leider bin ich jetzt erst auf die AV Development Guidelines aufmerksam geworden. Ich finde die Idee gut, frage mich aber, ob es bei 371 Definitionen(lt. Statistik) eine gute Idee ist, Befehle zu verändern. OK, ich könnte zumindest für evtl. Abhängigkeiten die "alten" cmd's zulassen, sie aber im Frontend nicht mehr anzeigen.
Die commands gemäß der Richtlinie sind lowercase. Im STV grundsätzlich uppercase. Ändere ich nun die relevanten cmd's auf lowercase verändere ich die Sortierreihenfolge im Frontend. Irgendwie unschön. Alle ca. 100 cmd's auf lowercase umstellen ?
Da die jetzigen cmd's quasi dem Befehl an das API 1:1 entsprechen, macht es da Sinn einen Hash zu bauen, der Übersetzungen enthält, obwohl eigentlich nur ein Handvoll Befehle betroffen sind ?
Und macht es wirklich Sinn aus z.B. CHDOWN ein channelDown zu transformieren, nur um dem Standard zu entsprechen ?
Und dann muss auch noch das remotecontrol-Modul angepasst werden, weil dort ja das layout für die Samsung-TV's hinterlegt ist.
Readings haben wir eigentlich noch keine, so dass ich mich dort anpassen könnte. In der Regel habe ich aber kein Feedback vom TV. Wird also über die physische RC geschaltet, ist das reading falsch bzw. beinhaltet "nur" den letzten FHEM-Befehl.
Ich bin mir sowas von unschlüssig, was ich machen soll.
Bitte um Tipps.
Und dann wäre da noch die Frage nach dem Unterschied zwischen dem power- u. dem presence-Reading. Ich sehe da einfach keinen. Wobei mir "logisch" das presence-reading besser gefällt, denn das Modul kann nicht beurteilen, ob der TV an oder aus ist, wohl aber ob eine TCP/IP-Verbindung möglich ist. Das passt dann aber irgendwie nicht zum state-Reading, das kein present bieten soll.
(und ich hatte gerade erst den state auf connected/disconnected umgestellt ::) )
Grüße Markus
Hallo Markus,
Und wenn Du ein komplett neues Modul erstellst? STV2?
Grüße
Hi Leon,
würde sicherlich das Problemchen der Abwärtskompatibilität lösen. Wer eine meiner inoffiziellen Versionen nutzt, hat aber auch sicher-(hoffent-)lich (noch) ein excludefromupdate. ;D Hat also das Problem der plötzlichen Veränderung nicht. Betroffen wären "nur" die Nutzer von TVs mit Alter > 5 Jahren, denn nur für die funktioniert überhaupt das offizielle Modul.
Einerseits hat meine Version nicht mehr viel mit dem ursprünglichen STV gemeinsam. Andererseits ein weiteres Modul ins offizielle FHEM für den selben device-type übernehmen ? :-\ Ist das nicht am Ende des Tages mit Kanonen auf Spatzen geschossen ?
Grüße Markus
Edit: btw. da ich eh Antworten von AV-Modulautoren erwarte, guckt Euch bitte mal meine Gedanken zur Vereinheitlichung (https://forum.fhem.de/index.php/topic,92636.msg853478.html#msg853478) an
Indirekt. Du zwingst die User nicht Ihre Konfiguration zu ändern, wollen sie aber ein aktuelles Modul welches gepflegt wird müssen sie auf Dein neues Umschalten.
Irgendwann kann man darüber nachdenken das alte (sofern Du die Hohheit darüber hast) komplett aus dem SVN von FHEM zu entfernen. Es bleibt lokal bei den User erhalten ist aber bei Neuinstallationen von FHEM nicht mehr dabei.
Ah, OK, also nur temporär 2 Module. Mit dem Gedanken könnt ich mich anfreunden. Dann aber als 70_SamsungAV. ;)