einheitliche kommandos für av geräte

justme1968 · 02 August 2013, 16:02:05

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

Markus Bloch · 02 August 2013, 16:03:44

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

justme1968 · 02 August 2013, 16:36:08

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

betateilchen · 02 August 2013, 16:45:48

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*

Markus Bloch · 03 August 2013, 11:58:43

Zitat von: betateilchen schrieb am Fr, 02 August 2013 16:45
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)

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

justme1968 · 03 August 2013, 12:16:03

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

betateilchen · 03 August 2013, 18:50:59

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)

Markus Bloch · 04 August 2013, 19:21:05

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

betateilchen · 04 August 2013, 22:27:27

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.

Markus Bloch · 04 August 2013, 23:47:42

Ist ja auch nur ein Vorschlag.

betateilchen · 05 August 2013, 11:49:27

Es war auch nur eine Frage. Was willst du mit so einem Reading in der Praxis anfangen?

Markus Bloch · 05 August 2013, 15:56:29

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

TeeVau · 09 August 2013, 11:29:57

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?

Markus Bloch · 09 August 2013, 12:28:07

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

Markus Bloch · 10 August 2013, 14:41:54

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