-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration AV-Receiver über HTTP-Requests #53
Comments
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
<#53>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AVnkSXEdJ_mkKsDs-5iXYAys0v26beLpks5rROjNgaJpZM4LgpdO>
.
|
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 |
Danke für die ausführliche Antwort! Generell finde ich die Idee mit Plugin als eigenständige Sache sehr gut. Von meiner Seite her auch vielen Dank für die tolle Leistung diese Anwendung zu entwickeln! |
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 |
@NetHans |
@haujo 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 ;-) |
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
<#53 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AVnkSdem9wBJVGjRzJmYa7bu-tgahn5Wks5rRfI1gaJpZM4LgpdO>
.
|
@janningnetworks 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. |
Bitte bedenkt immer die zugrunde liegenden Mittel. 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. 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. |
Ist im erweiterten Sinne das da: Wann und wie und ob ich das umsetze ist aber fraglich.... |
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 |
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 @haujo vllt. interessiert dich mein Script (sehr rudimentär, aber es tut was es soll): |
@vicegold BTW: Du brauchst eigentlich kein periodisches polling jede sekunde machen. Der Raumserver unterstützt bei diesem Request "long Polling". |
@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! |
@vicegold |
@vicegold |
Super, danke! |
Neue version ist verfügbar. |
@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:
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! :-) |
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 |
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?
The text was updated successfully, but these errors were encountered: