Integration AV-Receiver über HTTP-Requests

[haujo]

Ich verwende neben meinen normalen Raumfeld-Geräten auch einen Raumfeld-Connector um an mein Heimkinosystem auch über die Raumfeld-App Musik hören zu können. Funktioniert alles super, nur man muss immer den AV-Receiver erst einschalten und auf den richtigen Kanal stellen. Kann man das auch irgendwie automatisieren?

Ich kann auf jeden Fall meinen Denon AV-Receiver mittels HTTP-Requests einschalten und alle möglichen/nötigen steuerungsbefehle ausführen. Geht einfach und ohne Problem über den Browser.

Z.B. An-/Ausschalten http:///goform/formiPhoneAppPower.xml?1+PowerOn http:///goform/formiPhoneAppPower.xml?1+PowerStandby

Gibt es hierfür eine Lösung? Wenn nicht, könnte man dies dann vielleicht integrieren?

[janningnetworks]

schau dir mal ha-bridge an -> auch über github.

VG

janning networks

birger-forell-str. 46

49824 neugnadenfeld

phone +49 5944 599105

fax +49 5944 5999922

www.janning.info

Am 11. Januar 2017 um 15:35 schrieb haujo notifications@github.com:

Ich verwende neben meinen normalen Raumfeld-Geräten auch einen Raumfeld-Connector um an mein Heimkinosystem auch über die Raumfeld-App Musik hören zu können. Funktioniert alles super, nur man muss immer den AV-Receiver erst einschalten und auf den richtigen Kanal stellen. Kann man das auch irgendwie automatisieren?

Ich kann auf jeden Fall meinen Denon AV-Receiver mittels HTTP-Requests einschalten und alle möglichen/nötigen steuerungsbefehle ausführen. Geht einfach und ohne Problem über den Browser.

Z.B. An-/Ausschalten http:///goform/formiPhoneAppPower.xml?1+PowerOn http:///goform/formiPhoneAppPower.xml?1+PowerStandby

Gibt es hierfür eine Lösung? Wenn nicht, könnte man dies dann vielleicht integrieren?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ChriD/Raumserver/issues/53, or mute the thread https://github.com/notifications/unsubscribe-auth/AVnkSXEdJ_mkKsDs-5iXYAys0v26beLpks5rROjNgaJpZM4LgpdO .

[NetHans]

Hallo haujo,

die Idee auch andere Geräte über ein zentrales System zu steuern finde ich im Prinzip sehr gut, aber sollte man sowas nicht als "PlugIn" oder so ähnlich betrachten? Eine Vermischung von Raumfeld-Steuerung und Steuerung von 3th-Part-Hardware in einer Anwendung könnte in einer unübersichtlichen Software enden. Es müsste sich immer die Frage gestellt werden, wo fängt man an und wo hört man auf. Dazu kommt, wenn ich das Richtig mitbekommen habe, dass Christian aktuell alleine die Programmierung des Raumfeld-Server übernimmt.

Vielleicht wäre es hilfreich, wenn an dieser Stelle eine Diskussion darüber entsteht, ob der Raumfeld-Server sich ausschließlich auf Raumfeld-Funktionen konzentrieren und 3th-Part extra behandelt werden sollte, oder ob man alles in eine Software gepackt werden soll.

Meine ganz persönliche Meinung dazu ist, Das man 3th-Part Steuerung auch separat behandeln sollte. Der Gedanke an einen willkürlichen Funktionsmischmasch lässt es mir eiskalt den Rücken runter laufen.

@ChriD Auch an dieser Stelle noch mal einmal ein dickes Danke für deine tolle Arbeit hier ... dickes "Daumen hoch" ;-)

[haujo]

Danke für die ausführliche Antwort! Generell finde ich die Idee mit Plugin als eigenständige Sache sehr gut. Bezogen auf den raumfeld Connection ist es für mich aber etwas das auch als integrierte Lösung Sinn machen kann. Denn ein raumfeld connector läuft normal nicht alleine. Eine einfache Lösung, dass man bei ein und ausschalten von bestimmenden raumfeld Geräten (in diesem Fall der connector) eine Reihe von definierten http-requests absetzen kann, das würde bestimmt schon vielen helfen, dass sie damit den av-Receiver ein/ausschalten können und auf den richtigen Eingang umschalten (z.b. Von sat-Receiver auf raumfeld connector).

Von meiner Seite her auch vielen Dank für die tolle Leistung diese Anwendung zu entwickeln!

[NetHans]

An dieser Stelle sollte sich Christian mal äußern, was er für das Beste hält. Er ist der einzige der die Software im Kern wirklich kennt und weiß was geht und was nicht geht, bzw was er will und nicht will.

Aber auch beim Absetzen von HTTP-REQUEST werden die Anforderungen an die Funktionen so unterschiedlich sein, dass man nie genau das trifft, was "alle" haben wollen. Anforderungen macht man ja an sich immer aus der eigenen Sicht auf und bezieht sich explizit auf seine eigenen Bedürfnisse und das ist auch gut so ;-). Aber für eine "saubere" Software ist das eher ungünstig.

Das von dir beschriebene Absetzen von Befehlen beim Ein- und Ausschalten würde mit Sicherheit einigen helfen. Andere brauchen aber das absetzen von Befehlen, bevor das "Play"-Command gesendet werd. Andere benötigen die Befehlen bei anderen Commands. Entsprechend ist das garnicht so einfach hier eine "einfache" Lösung bereit zu stellen.

Interessant an dieser Stelle wäre wirklich, ob Christian gewillt ist auf kurz oder lang eine art Plugin-System zu implementieren, welches es ermöglicht bei diversen Events (OnPower, OnShutdown, OnPlay, OnChangeVolume, ..... ) irgendwas zu machen. Wie sowas aussehen kann, kann ich mir an dieser Stelle noch absolut garnicht vorstellen. Aber so könnten man sauber die Funktionen rund um die Raumfeld-Geräte von anderen Bedürfnissen der User trennen. Denn die Kernaufgabe für den Raumfeld-Server ist immer noch das steuern von Raumfeld-Geräten ;-)

@haujo Mich würde mal interessieren, auf welchen Weg du deine Raumfeld-Geräte ansteuerst, bzw einschaltest. Ich bin zwar auf dem Gebiet des Raumfeld-Servers absoluter Neuling, aber mir ist kein Event bekannt, was der Raumfeld-Server auslöst, wenn ein Raumfeld-Gerät manuell eingeschaltet wird. Das wiederrum bedeutet, das die von dir geforderten Befehle eh nur dann abgesetzt werden, wenn du die Raumfeld-Geräte über den Raumfeld-Server anschaltest. Da der Raumfeld-Server selber aber schon einen HTTP-Request benötigt um in Aktion zu treten, brauchst du einen vorgeschalteten Client der den Befehl an den Raumfeld-Server absetzt. Somit könntest du für eine schnelle Lösung deine gewünschten HTTP-Request über deinen Client an deinen AV-Receiver absetzen, bevor du die Befehle an den Raumfeld-Server absetzt.

[haujo]

@NetHans Wie der Raumserver genau funktioniert weiß ich nicht. Daher kann ich das nicht beurteilen wie das implementiert werden könnte. Mein persönliches Ziel ist es einfach, wenn ich die Raumfeld app nutze, dass ich nicht jedes mal den AV-Receiver einschalten und einstellen muss. Ich möchte einfach nur auf Play drücken in der App, dann geht ja ohnehin schon das Raumfeld-Gerät an. An dieser stelle möchte ich auch, dass ich meinen AV-Receiver per HTTP-Request aufwecken und auf den richtigen Kanel stellen kann. Evtl. als dritten Request noch die Lautstärke auf einen bestimmten Wert setzen (könnte ja durch TV-Schauen umgestellt worden sein).

[NetHans]

@haujo Wenn du über die App von Raumfeld direkt gehst, wirst du meines Wissens nach aktuell dein Vorhaben nicht umsetzen können. Denn der Raumfeld-Server bekommt es nicht pro aktiv mit, wenn du über die Raumfeld-App ein Device einschaltest. Der Raumfeld-Server benötigt aktuell glaube ich immer einen Request um eine Aktion zu starten. Diesen Request an den Raumfeld-Server musst du außerhalb der Raumfeld-App absetzen.

Somit müsste Christian erst einmal einen Mechanismus implementieren, welcher dafür sorgt, das der Raumfeld-Server in bestimmten Intervallen eigenständig den Status der Raumfeld-Devices abfragt, abgleicht und irgendwelche Aktionen (in deinem Fall HTTP-Requests) durchführt. Das sollte aber als eigenständige Anfrage hier bei Github eingestellt werden, damit die Ordnung gewahrt bleibt ;-)

Bevor hier der Eindruck entsteht, das ich hier alles schlecht rede, möchte ich noch einmal ausdrücklich klarstellen, das ich deine Idee super finde, solange sie vernünftig umgesetzt wird ;-)

[janningnetworks]

ich hatte ja weiter oben auf ha-bridge verwiesen...

ha-bridge emuliert eine Hue Bridge.

Du könntest dann mittels ha-bridge bestimmte "virtuelle HUE Geräte" erstellen: z.B. Gerät: "Einslive Stream Wohnzimmer"

(das könnten dann z.B. einfache Skripte sein (http-request auf deinen AV-Receiver + http-request zum starte von Einslive-Stream über Raumserver in Wohnzimmer. usw.).

Diese kannst du dann in einer beliebigen Hue-kompatiblen App starten und beenden.

Prinzip: Der Hue App vorgaukeln, diese Geräte wären HUE Lampen, die man ein- und ausschalten kann... (man könnte die Dimmfunktion z.B. für die Lautstärke nutzen)

Wenn du dann noch tatsächlich Hue Lampen besitzt - kannst du die sogar schöne Szenen bauen..

z.B. Lichtfarben auf Lagerfeuer, Receiver-Eingang wechseln, Musik spielen, Heizung hochregeln usw.

janning networks

birger-forell-str. 46

49824 neugnadenfeld

phone +49 5944 599105

fax +49 5944 5999922

www.janning.info

Am 12. Januar 2017 um 10:28 schrieb NetHans notifications@github.com:

@haujo https://github.com/haujo Wenn du über die App von Raumfeld direkt gehst, wirst du meines Wissens nach aktuell dein Vorhaben nicht umsetzen können. Denn der Raumfeld-Server bekommt es nicht pro aktiv mit, wenn du über die Raumfeld-App ein Device einschaltest. Der Raumfeld-Server benötigt aktuell glaube ich immer einen Request um eine Aktion zu starten. Diesen Request an den Raumfeld-Server musst du außerhalb der Raumfeld-App absetzen.

Somit müsste Christian erst einmal einen Mechanismus implementieren, welcher dafür sorgt, das der Raumfeld-Server in bestimmten Intervallen eigenständig den Status der Raumfeld-Devices abfragt, abgleicht und irgendwelche Aktionen (in deinem Fall HTTP-Requests) durchführt. Das sollte aber als eigenständige Anfrage hier bei Github eingestellt werden, damit die Ordnung gewahrt bleibt ;-)

Bevor hier der Eindruck entsteht, das ich hier alles schlecht rede, möchte ich noch einmal ausdrücklich klarstellen, das ich deine Idee super finde, solange sie vernünftig umgesetzt wird ;-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ChriD/Raumserver/issues/53#issuecomment-272115249, or mute the thread https://github.com/notifications/unsubscribe-auth/AVnkSdem9wBJVGjRzJmYa7bu-tgahn5Wks5rRfI1gaJpZM4LgpdO .

[haujo]

@janningnetworks Danke für die Information zu ha-bridge. Ich hatte mir das gestern auch angesehen. Jedoch so wie ich das verstehe würde es meine Anforderungen nicht erfüllen. Wenn ich in der Raumfeld-App die Musik starte (oder auch über ChromeCast aus einer anderen App heraus), dann würde ja trotzdem nicht automatisch der Receiver angehen. Oder verstehe ich da etwas falsch? Mein einziges Ziel ist es, dass ich ein Kopplung zwischen Raumfeld-Connector und AV-Receiver schaffe. Sobald der Connector etwas abspiel sollte sich der AV-Receiver einschalten, auf den richtigen Eingan schalten und evtl. die Lautstärke noch initial einstellen.

Ich weiß, dass es auch andere Möglichkeiten gibt. Z.B. dass ich beide systeme über http-requests anstarten kann z.B. durch doppelklick auf Lichschalter oder sonst irgendwie in die Hausautomatisation integriert. Aber es ist eben nichts so konfortable wie klick auf "Play" in meiner Standard App und fertig. Natürlich habe ich auch für Denon eine App, mit der ich den Receiver starten kann. Aber diese unnötigen Aktionen würde ich gerne los werden. Vor allem dreh ich die Musik im Wohnzimmer gerne mal auf, auch wenn ich in einem Nebenraum bin, wo ich keinen Raumfeld-Geräte habe.

[NetHans]

Bitte bedenkt immer die zugrunde liegenden Mittel. Die meisten welche den Raumfeld-Server verwenden, habe diesen sicher auf einem Raumfeld-Device ans laufen gebracht. Es ist meist nicht gewünscht, weitere Hardware in Form eines Raspberry oder so parallel betreiben zu müssen. Somit kommt die Software, welche janningnetworks vorgeschlagen hat, nicht in Frage, da diese nicht für ein Raumfeld-Device vorgesehen ist. Ich gebe haujo Recht, das der einfachste Weg mit den Raumfeld-Devices in Aktion zu treten die Hauseigene Raumfeld-App ist.

Das Projekt von Christian, hat allerdings - scheinbar - das primärziel Ziel, eine alternative Steuerung zur Raumfeld-App zu bieten, welche parrallel auf den Raumfeld-Devices lauffähig ist. So ist auch die Integration in eine Hausautomatisierung und ähnliches möglich.

Das Thema was hier diskutiert wird, hat ohne Frage seine Berechtigung, wird aber unter verschobenen Grundlagen betrachtet. Der Raumfeld-Server ist für die Steuerung von Raumfeld-Devices vorgesehen und auf dieser Aufgabe sollte auch der primäre Fokus liegen. Wenn Mechanismen für 3th-Part Devices mit implementiert werden sollen, dann sollte dies gekapselt erfolgen, damit eine klare Trennung der Aufgaben sichergestellt ist und sich der Raumfeld-Server auch weiterhin primär auf seine Hauptaufgaben konzentrieren kann. Wie und welche Ideen/Anregungen Christian an dieser Stelle umsetzt, bleibt in erster Linie ihm überlassen. Lasst Chrisian bitte erst einmal zu dem Thema Stellung nehmen, denn sonst wird sich dieses Thema hier immer weiter im Kreis drehen.

Sicher ist aktuell nur, das dem Raumfeld-Server für die Anforderungen von haujo mehr Funktionen fehlen als nur eine Möglichkeit beim OnPower-Event (welches nicht existiert) eine Liste von HTTP-Requests abzusetzen.

[ChriD]

Ist im erweiterten Sinne das da: https://github.com/ChriD/RaumserverLib/issues/6

Wann und wie und ob ich das umsetze ist aber fraglich....

[vicegold]

Am gleichen Problem sitze ich aktuell auch. Am schönsten wäre natürlich wenn Raumserver eine Art von Events unterstützen würde, quasi also einfach eine Schnittstelle bieten würde wo man eigene scripte für jede Statusveränderungen eines RF Systems hinterlegen kann. Die Möglichkeiten damit wären unendlich und der Entwickler müsste sich auch nicht um Drittanbieter Kram kümmern.

Wenn ich es jedoch richtig verstehe gibt /raumserver/data/getRendererState?id=Wohnzimmer ja den Status eines Gerätes zurück. Diesen könnte man mit einem eigenen Script jede Sekunde Abfragen und somit selbst Änderungen feststellen und damit dann die eigenen Aktionen ausführen. Werde das mal ausprobieren, bin heute erst auf Raumserver gestoßen.

[vicegold]

Update: Habe es so einigermaßen hinbekommen, leider scheint Raumserver nicht explizit mitzuteilen ob eine Zone auf Play oder Stop steht. Solange also ein Zone aktiv ist funktioniert es nicht. Wenn man aber beim stoppen der Wiedergabe nicht einfach nur auf Stop drückt, sondern die Zone deaktiviert funktioniert mein Script einwandfrei.

Wäre es evtl. möglich über /raumserver/data/getRendererState?id=Device auch abfragen zu können ob gerade etwas abgespielt wird oder ob die Wiedergabe gestoppt wurde?

@haujo vllt. interessiert dich mein Script (sehr rudimentär, aber es tut was es soll): https://gist.github.com/vicegold/7ec27b477f6c53a8695ab97a44360846

[ChriD]

@vicegold Der "Transport State" (also ob Play, Pause,...) sollte eigentlich bereits implementiert sein und funktionieren. Ich checke das mal.

BTW: Du brauchst eigentlich kein periodisches polling jede sekunde machen. Der Raumserver unterstützt bei diesem Request "long Polling". D.h du setzt erstmal den request ab und bekommst dann die daten zurück und im header des response eine "updateId". Du machst jetzt nochmal denselben request mit dieser "updateId" als query (also so z.B.) http://10.0.0.6:8080/raumserver/data/getRendererState?Id=Wohnzimmer&updateId=4578457 und du bekommst dann erst einen response wenn sich an den daten was ändert. Der response hat dann wieder eine updateid die du beim nächsten requets mitschickst. Und das geht dann immer so weiter. Wenn sich also überhaupt nichts ändert bleibt dein request also so lange "offen"

[vicegold]

@ChriD Bei mir steht bei transport state immer nur STOPPED. Egal in welchem Zustand sich das Gerät gerade befindet.

Long polling klingt interessant, muss ich mir einmal anschauen ob ich verstehe wie das funktioniert!

[ChriD]

@vicegold Hab was gefunden. Der Transport state ändert sich wirklich nicht mehr. Hab das in der neuen version gerichtet. Jedoch habe ich bemerkt, dass das Long Polling noch nicht ganz verlässlich. Vielleicht solltest du derweil wirklich noch normal pollen.

[ChriD]

@vicegold auch das mit dem Polling hab ich gefixt. Ist im repository drinnen. Neue Version mache ich mitte Februar herum

[vicegold]

Super, danke!

[ChriD]

Neue version ist verfügbar. https://github.com/ChriD/Raumserver/wiki/Manual-install-on-raumfeld-devices

[gutmensch]

@ChriD: Sieht gut aus, danke! Das docker-image ist geupdatet und funktioniert bei mir. Eine Frage zum Log/Debug-Output, (ich glaube) ich sehe seit dem Update häufig "UPNP: SSDP Unicast Http Error", obwohl es wohl keinen Einfluss hat:

2017.02.11 14:31:08.250 DEBUG:    UPNP: SSDP Unicast        HttpError
2017.02.11 14:31:08.250 DEBUG:    UPNP: SSDP Unicast        HttpError
2017.02.11 14:31:08.251 DEBUG:    UPNP: SSDP Unicast        HttpError
2017.02.11 14:31:08.251 DEBUG:    UPNP: SSDP Unicast        HttpError
2017.02.11 14:31:08.251 DEBUG:    UPNP: SSDP Unicast        HttpError
2017.02.11 14:31:09.732 DEBUG:    UPNP: SSDP Unicast        HttpError

root@qnap:/opt# cat raumserver/settings.xml
<?xml version="1.0" encoding="utf-8"?>
<Application>
  <Raumkernel>

    <!-- Log settings. You might change some settings here if you want to change the output log level or add/remove a log adapter
         To get the available options for 'LogLevel' and 'LogAdapter' please take a look at the documentation -->
    <Log>
      <Level>DEBUG</Level>
      <LevelUpnp>ERROR</LevelUpnp>
      <!-- <LevelUpnp>ALL,ADAPTERCHANGE,BONJOUR,DEVICE,DVDEVICE,DVEVENT,DVWEBSOCKET,DVINVOCATION,DVSSDPNOTIFIER,ERROR,EVENT,HTTP,LPEC,NETWORK,NONE,SERVICE,SSDPMULTICAST,;SSDPUNICAST,TRACE,THREAD,TIMER,VERBOSE,XMLFETCH</LevelUpnp> -->
    </Log>

Das Loglevel für UPNP sollte m. E. doch ERROR sein nach der settings.xml oder überschreibt der globale Wert oder gibts die Funktionalität noch gar nicht? Wie auch immer, gute Arbeit und weiter so! :-)

[ChriD]

Ja die 1.2 er leitet das Log vom OpenHome-UPNP Stack aus immer auf DEBUG um da ich vom UPNP-Log den typ des logs (fehler, info, ...) leider nicht mitbekomme. (z.B. wenn der Log Level bei UPNP auf ALL gestellt ist). Aber der UPNP Log wird schon auf die Einstellung gfiltert die im Setting angegeben ist Den Unicast Fehler hab ich auch. Das ist egal.