Neues Modul - 70_VolumeLink - Zum koppeln der Lautstärke/Mute zweier Geräte

[rapster]

Hallo Zusammen,

habe soeben das neue Modul VolumeLink eingecheckt womit man den Lautstärke-Level (incl. Mute) eines tatsächlichen Gerätes (z.B. TV) mit einem fhem-device (z.B. einer SONOS-Playbar oder einem AVR, usw.) koppeln kann.

Sollte ab Morgen über das Update verfügbar sein.

• Das Modul pollt NonBlocking in sehr kurzen Intervallen (ich nutze i.M. interval 0.2 sec. mit einem timeout von  0.2 sec.) die Informationen vom physikalischen Gerät und setzt bei Änderung ein set an das entsprechende FHEM-Device ab.
  
  


• Das mögliche <intervall> und <timeout> wird hauptsächlich durch die Belastbarkeit und Antwortzeit eures abzufragenden Gerätes (z.B. TV) beeinflusst, denn selbst bei einem Interval von 0.1 sec. entsteht durch das Modul keine nennenswerte/messbare Erhöhung der Last auf der FHEM-Maschine, bei einem überaus kleinen Interval von 0.01 sec. erhöht sich bei mir die CPU-Nutzung um etwa 2%.
  
  


• Der Timeout sollte so gesetzt werden dass das abzufragende Gerät evtl. auch mal etwas länger Zeit zum Antworten hat, andererseits sollte statt zu langer Wartezeit lieber eine neue Abfrage gestartet werden welche wahrscheinlich wieder schnell antwortet.
  Bei den ersten drei aufeinander folgenden Timeouts versucht das Modul ein "fast-retry" nach jeweils 0.1 Sekunden (falls konfigurierter <interval> nicht bereits kleiner ist), bei allen nachfolgenden Timeouts wird der nächste Versuch nach der Zeit <interval> gestartet.
  
  


• Bei meinem Philips-TV beträgt die übliche Antwortzeit  ca. 0.016 bis 0.03 Sekunden, bei einem <intervall> von 0.2 Sekunden, + der Zeit welche z.B. das Sonos-Modul zum übermitteln der Lautstärke an die Playbar benötigt lässt sich die Lautstärke sehr angenehm steuern und der minimale delay fällt in der Praxis kaum ins Gewicht.
  
  
• Der Minimalwert für interval & timeout ist auf 0.01 begrenzt.
  
  

Ich verwende es z.B. um mit der original Funk-Fernbedienung meines Philips-TV's die Lautstärke an der per Toslink angeschlossenen SONOS-Playbar steuern zu können, da ich die original Fernbedienung deutlich besser finde als irgend eine Harmony ect...

Weitere Infos zu dem Modul sind in der Commandref zu finden.

Gruß
Claudiu

[FunkOdyssey]

Sehr gute Idee. Gefällt. Vielen Dank.

[Markus Bloch]

Hallo Claudiu,

kleiner Hinweis. Ein Interval von 0.1 Sekunden kann durchaus funktionieren, impliziert aber, das ein FHEM-Main-Schleifendurchlauf innerhalb von 0.1 Sekunden durchgeführt wird. Das kann allerdings je nach System unterschiedlich hoch sein (teilweise mehrere Sekunden). Sobald ein HTTP Request Non-Blocking durchgeführt wird, braucht es mind. einen Schleifendurchlauf um eine vorhandene Antwort an VolumeLink zu melden.

Wenn ein User in seiner FHEM Konfiguration Module oder Definitionen verwendet, die den Hauptprozess mittels sleep() verzögern, kann ein Schleifendurchlauf schonmal durchaus weit länger als 0.1 Sekunde dauern.

Viele Grüße

Markus

[rapster]

Hallo Markus,

danke für den Hinweis, daran habe ich nicht gedacht, auch da bei meinen Tests erstmal alles wie erwartet funktionierte.
Wobei natürlich die 0.1 schon auch ein sehr kleiner Wert ist, in der Praxis fallen auch etwas höhere Werte kaum auf, wobei wie du schon sagtest, wenn einer ein perlsleep irgendwo reingebaut hat wirds schon kritisch

Meinst du eine Lösung mit Blockingcall, in welchem z.B. ein sleep 0.1 durchgeführt wird, und welcher bei Rückkehr sofort den nächsten BlockingCall startet wäre besser geeignet?

Gruß
  Claudiu

[justme1968]

wenn das device um das es geht dir änderungen wirklich nicht von sich aus meldet sondern gepollt werden muss würde ich das do weit von fhem entkoppeln das das polken komplett in einem dauernd laufenden prozess mit eventuell niedriger priorität gemacht wird und von diesem nur tatsächliche änderungen an fhem weiter gemeldet werden.

schau dir mal mal SubProcess dafür an.

gruss
  andre

[rapster]

Hallo Andre,

danke für die Info, SubProcess ist sehr interessant, ebenfalls deine Sandbox die ich dadurch gefunden habe
Wird denke ich für ein anderes Projekt an dem ich nebenbei bastel ganz hilfreich sein.

Wenn ich allerdings VolumeLink auf SubProcess ändere, gewinne ich doch eigentlich nicht wirklich viel, außer dass das polling dann in einem eigenen Prozess stattfindet.
Einen mögliche Volume-Änderung bekommt ja der parent in diesem Fall (wie auch in der momentanen Implementierung) auch erst frühstens mit wenn readFN vom main-loop aufgerufen wird.

Oder übersehe ich da was?

Überlege gerade das polling in einem fork laufen zu lassen, und bei einer volume-Änderung à la Blocking.pm über die telnet-Schnittstelle eine sub VolumeLink_DoParent() aufzurufen welche dann den rest übernimmt, dies sollte doch dann beides erschlagen - Polling in eigenem Process - Zeitmanagement größtenteils losgelöst vom fhem-loop...

Oder übersehe ich hier erst recht was ?

Gruß
Claudiu

[justme1968]

das pollen im sub prozess ist genau die wichtige änderung. weil weder fhem verzögert wird noch das pollen durch fhem beeinflusst wird. die änderungen die du dann an fhem schickst werden über die main loop asynchron und so schnell es fhem gerade erlaubt verarbeitet. da die häufigkeit einer tatsächlichen ändeung vermutlich minimal gegenüber den polling versuchen ist würde ich nur dann den wert an fhem schicken wenn es auch tatsächlich eine änderung gab.

die sandbox ist etwas genereller aber leider noch nicht fertig.

BlockingCall ist im prinzip auf seltene aufrufe die lange laufen ausgerichtet, die kommunikation zurück wird jeweils neu aufgebaut.

SubProcess ist auf einen aufruf der dann permanent parallel läuft und immer wieder ergebnisse liefert ausgerichtet. die verbindung zwischen patent und child bleibt dauernd bestehen.

das eigentliche forken ist immer gleich.

gruss
  andre

[rapster]

Zitat: .. noch das pollen durch fhem beeinflusst wird ..

Stimmt, macht auch definitiv Sinn und werde ich einbauen. Ist auch das worauf Markus hinwies.

Zitat: .. weil weder fhem verzögert wird ..

Ich konnte allerdings bei meinen Tests nicht wirklich feststellen (Messen?) das fhem selbst durch wahnsinnig viele pollings in Mitleidenschaft gezogen wird, bietet fhem selbst noch andere Möglichkeiten als Apptime an dies zu beurteilen? Oder betrifft eine Beeinträchtigung durch ein solches vorgehen eher sehr leistungsschwache Devices à la FritzBox und co.?


Den Fork erstmal ganz normal mithilfe von SubProzess.pm laufen zu lassen ist erstmal eine gute Lösung, nur nochmal kurz zurück zu meiner letzten Frage die mich doch interessiert

Wenn ich die Antworten des SubProcess (auch wenn es nicht viele sind..) nicht über die ReadFN verarbeiten würde, sondern über die telnet-Schnittstelle immer wieder eine eigene perl-Function hierfür aufrufe, würde man hierdurch nicht noch ein par ms rausschinden können? Oder ist das dann eher schlechtes design?

Natürlich müsste das anschließend sowieso von dem Ziel-fhem-device verarbeitet werden,  aber das ist ja wieder eine ganz andere Baustelle


Gruß
Claudiu

[justme1968]

ich denke es ist sinnvoll nicht nur den ideal fall anzuschauen sondern auch den fehlerfall. wenn das gepolte device nicht antwortet, es netzwerk probleme gibt oder was auch immer. jedes blockieren blockiert würde auch fhem blockieren.

du gewinnst hier ziemlich sicher nichts. vermutlich ist eher die readFn variante effizienter diverser oberhead durch das parsen einer normalen fhem kommandozeile und erst recht des eval für den perl aufruf weg fällt. ich denke aber der unterschied ist klein. 

gruss
  andre

[rapster]

Alles klar, Danke dir Andre,

Werde die readFn Variante bei Gelegenheit einbauen, ist auf jedenfall sauberer finde ich.

Ein blockieren aufgrund des http-get's sollte allerdings aufgrund des verwendeten HttpUtils_NonblockingGet nicht auftreten, oder habe ich die Funktion falsch verstanden

Gruß
  Claudiu

[justme1968]

jein... das nonblocking get kann bei der namensauflösung vor dem  eigentlichen verbindungsaufbau hängen bleiben. eventuell noch bei ein oder zwei anderen fehlern. 

aber wenn du sowieso das nonblocking get verwendest würde ich mir die mühe mit dem forken & co. vermutlich  nicht machen. du blockierst fhem ja jetzt schon nicht. das eigentliche synchronisieren so oder so nicht besser da es im parent prozess erfolgt. und nicht zu forken schont auch ressourcen

gruss
  andre

[rapster]

hihi, ok, dann halt nur wirklich "bei Gelegenheit" oder Lust am Basteln 

Markus sein Argument stimmt ja noch, dass ich mich auf mein <interval> nicht ganz verlassen kann, wenn der fhem-loop aus irgend einem Grund länger brauchen sollte als das interval dauert. (Ich frage mich allerdings ob das dann überhaupt was bringt, wenn fhem sowieso schon am "hängen" ist?)

Werd dann erstmal noch paar andere Sachen einbauen, z.B. dass das Modul nicht nur mit Device-Modulen von AVR's usw. einfach zusammenarbeit, sondern auch mit dem Harmony-Hub oder ähnlichem ohne dafür readingsProxy o. dummy als Zwischenschritt anlegen zu müssen, und so paar Kleinigkeiten...

Gruß
  Claudiu

[justme1968]

ja. auf das inervall kannst du dich nicht verlassen. du kannst über das forken aber eben nur die abfrage deterministischer machen. nicht die weiterverarbeitung auf fhem seite. und weil die potentiell regelmäßigere abfrage nichts bringt ohne die passende weiterverarbeitung wäre es vermutlich wirklich nur die lust am basteln:)

warum brauchst du dür den hub noch zwischenschritte? wenn eine activity gestartet ist gehen funktionieren die volume kommandos genau so wie bei anderen device modulen. und außerhalb einer activity eigentlich auch wenn man das harmony device dur sein gerät angelegt hat. 

die gegenrichtung (volume vom gerät abfragen) gibt es ja leider so oder so nicht.

gruß
  andre

[rapster]

ok super dass du das genauso siehst, so hab ich mir das auch gedacht

jup genau wegen der fehlenden Gegenrichtung würde es i.M. noch nicht (direkt) mit dem hub funktionieren, VolumeLink prüft i.M. die gesetzten/zu setzenden Werte am Ziel-device um zu prüfen ob eine Änderung notwendig ist.

Werd dann für solche Fälle evtl. ein Attr anlegen damit sich VolumeLink einfach den zuletzt gesetzten Wert merkt ohne den echten state zu prüfen.
Oder so ähnlich, noch nicht wirklich Gedanken dazu gemacht

Gleich mal a Frage dazu, wie verhält sich der hub eigentlich bei einer absoluten Lautstärke wenn die Activity / das Device das nicht kennt?
In dem Fall müsste wahrscheinlich mit VolumeUp/Down so oft getriggert werden bis der Stand erreicht ist?

Hab zwar ein hub da um dann mal zu testen, der liegt aber i.M. nur auf dem Küchenschrank um die Dunstabzugshaube + Licht zu steuern


Gruß
  Claudiu


EDIT:
..und wies so oft ist, kommen mir beim Zähneputzen immer die meisten Ideen in den Kopf, und ich merkte wie blöd die Frage war ob harmony-hub eine absolute Laustärke kann 

Denke es bzgl. hub so zu implementieren, dass wenn im bereits vorhandenen Attribut 'ampVolumeCommand' nicht mehr 1 Befehl sondern 2 durch Leerzeichen getrennte Befehle stehen, wird automatisch jede Volume-Änderung mit Befehl1(Down)/Befehl2(Up) an das Gerät(hub) weitergereicht,
und es wird nicht mehr der aktuellen Volume-state vom fhem-device abgefragt.

Vll. fällt mir aber auch beim morgendlichen Zähneputzen was besseres ein

[justme1968]

genau der hub kennt keine absolute laurstärke.

ich bin schon eine ganze weile am überlegen wie es möglich ist bestimmte device zustände wie play/pause oder mute per zusätzlichen ir empfänger nachzubilden. aber da es weder die möglichkeit gibt den ausgangszustand sicher zu erkennen noch nicht angekommene befehle funktioniert das nicht.

gruss
  andre