einheitliche kommandos für av geräte

[justme1968]

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

[50watt]

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

[justme1968]

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

[Markus Bloch]

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

[Loredo]

Exakt. Daher haben es bisher auch alle so umgesetzt.

[50watt]

Es scheint einen Konsens zu geben

Wollen wir "Zonen" nicht in die 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.

[50watt]

"statusRequest" -> "get" oder "set"?

Aus DevelopmentModuleIntro entnehme ich:

Mit get werden typischerweise Werte von einem Gerät abgefragt.

Die 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

Code Auswählen Erweitern

get statusRequest sein (und nicht wie in DevelopmentGuidelinesAV ein

Code Auswählen Erweitern

set statusRequest)?

[justme1968]

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

[Loredo]

das sollte aber keines der av devices betreffen.

Doch, das ENIGMA2 Modul arbeitet schon asynchron. Das sollen doch mittelfristig ohnehin alle Polling-Devices tun.

eigentlich sollte man es also ändern.

Ich würde es so belassen. Es ist einfach auch in allen anderen Tausend (überspitzt) Modulen so.

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.

Das wäre konsequent, aber wie oben gesagt würde ich es so belassen wollen.

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.

[Markus Bloch]

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

[justme1968]

ich würde definitionen zumindest im ersten satz durch device ersetzen. oder fhem-device.

gruss
  andre

[Markus Bloch]

habe ich geändert.

[justme1968]

ich finde es gut so.

gruss
  andre

[bugster_de]

zum Thema statusRequest:

das 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

[justme1968]

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.