JSON: push statt pull

  • Hallo,


    ich habe ein Perl Modul für Hyperion für die Hausautomationssoftware FHEM geschrieben.


    Im einstellbaren Intervall werden die Daten vom Hyperion JSON Server abgerufen (pull) und verarbeitet.
    Gibt es statt dessen auch eine Möglichkeit die Daten gepusht zu bekommen?
    Hatte mir eben die JSON Weiterleitung angesehen, mir ist aber nicht ganz klar ob die für mein Vorhaben geeignet ist.


    Evtl. kann mir jemand zum Thema Push auf die Sprünge helfen!?


    Vielen Dank im Voraus.


    Gruß
    Dan

    • Offizieller Beitrag

    Hallo Dan.
    Leider müssen wir dich enttäuschen. Eine Push Funktion ist leider (noch) nicht im Hyperion Deamon integriert. Die gewünschten Informationen lassen sich, so wie du das bis jetzt tust, nur über Pull Abfragen.
    Die Weiterleitung ist primär dafür vorgesehen mehrere Deamons mit den gleichen Informationen (Grabber, EffectEngine, etc.) zu versorgen.
    Das soll aber nicht heißen das sich dieser Standpunkt nicht ändern lässt. ;)

  • Hallo Dan,
    ich beobachte deine Bemühungen schon einige Zeit. Respekt! Auch wie viel Zeit du dir dafür nimmst. Es passiert tatsächlich nicht all zu oft, das etwas wirklich gepflegt wird.


    Absolut eine Idee die man mit aufnehmen sollte. Es gibt verhältnismäßig wenig Feedback oder Diskussion zur JSON RPC wie mir gerade so auffällt.
    Wo wir dich schon hier haben. Wo siehst du Probleme oder wo würden dir Verbesserungen helfen in der Einbindung von Hyperion für FHEM? Was wünschst du dir am Meisten?

  • Moin Ihr Beiden,


    so so, meine Bemühungen sind also auch schon bei Brindosch angekommen....


    Mal kurz was zu mir:
    Ich bin kein professioneller Entwickler. Im Januar diesen Jahres bin ich über Euer schönes Projekt Hyperion gestolpert und war sofort "Feuer und Flamme" und habe mir mein eigenes Ambilight gebaut. Währenddessen bin ich dann auch über FHEM gestolpert und war (bin es noch immer) auch davon total begeistert.
    Nachdem es für FHEM noch kein Hyperion Modul gab und jemand einen einfachen Versuch eines Moduls im Forum veröffentlicht hatte, ich damit aber auch nicht so wirklich zufrieden war, war es um mich geschehen. Ich nahm mir vor Perl zu lernen (außer ein paar JS, PHP, HTML und CSS Kenntnissen konnte ich bis dato keine Programmierkenntnisse vorweisen) und mein erstes Projekt war eben dieses Hyperion Modul. Bin also nur Hobbyprogrammierer.
    So wie mein Modul im Moment ist, bin ich (und auch die FHEM-Hyperion-Community) schon sehr zufrieden. Ich habe, denke ich, alles an Funktionen eingebaut was gewünscht war und es funktioniert hervorragend.


    Nun zu meinen Wünschen:
    Klar funktioniert das jetzt so mit dem pullen der Daten, ist allerdings weit davon entfernt wirklich immer den live Status anzuzeigen. Um die System- und Netzwerklast gering zu halten, pulle ich persönlich alle 10 Sekunden, habe das Modul aber auf minimal 5 Sekunden Intervall begrenzt. Eine Push Funktion (oder etwas Ähnliches) wäre natürlich viel angenehmer. Die Anzeige in FHEM wäre eben live und es müsste nicht ständig gepullt werden. Drum war meine Idee ob ich eventuell etwas mit der JSON Weiterleitung diesbezüglich anfangen kann. Hab auch schon versucht den Traffic der Weiterleitung zu sniffen, bin aber nicht wirklich schlau draus geworden (vielleicht fehlt mir da auch noch Wissen!?).
    Also aus meiner Sicht wäre eine Push Funktionalität noch das i-Tüpfelchen Eurer bisher schon wirklich tollen Software.
    Vor einer Woche hatte ich auf Github noch einen Issue gepostet auf den ich bisher leider noch keinerlei Antwort bekommen habe. Es wäre toll wenn sich das nochmal jemand ansehen könnte.
    Um mein Modul wirklich (fast) perfekt zu machen versuche ich gerade noch die einstellbaren Wertebereiche und Schrittweiten herauszufinden, damit eben wirklich nur valide Daten an Hyperion gesendet werden können. Leider tue ich mich damit teilweise etwas schwer da ich versuche das über Hypercon herauszubekommen. Offensichtlich gibt es aber einige Werte die Hyperion per JSON liefert in der letzten Hypercon Version nicht mehr (valueGain?). Darum meine konkrete Frage: Gibt es irgendwo eine Übersicht (Liste) mit allen per JSON einstellbaren Wertebereichen und deren Schrittweiten?


    Vielen Dank im Voraus.


    Gruß
    Dan


    P.S. Ich habe etwas von einer 2.0 Entwicklung mitbekommen. Gibt's da schon ein evtl. Release Datum? Ich möchte gerne gewappnet sein und möglichst kurz nach dem Release entsprechend mein Modul angepasst haben.

  • Ich bin kein professioneller Entwickler.


    Sind hier tatsächlich die Meisten ebenfalls nicht. Ich glaube das liegt primär daran, dass keiner der 8 Stunden vor dem PC sitzt und programmiert das abends nochmal macht.


    Zu deinem issue, ich meine das war schon immer so. Effect und Color setzen nur ein, wenn vom Nutzer etwas gesetzt wurde. Wie sollte es sich verhalten? Wenn die Grabber einsetzen ist es dann auch eine Farbe die aus allen leds zusammen entsteht? Momentan ist das sehr simpel gehalten.


    Um mein Modul wirklich (fast) perfekt zu machen versuche ich gerade noch die einstellbaren Wertebereiche und Schrittweiten herauszufinden


    Die Werte in HyperCon habe ich nach Gefühl gesetzt oder nach Anweisung. (Oder sie so gelassen, wie sie waren)
    Das Problem mit den Werten rührt daher, dass Hyperion 2 Arten der Farbkalibrierung hat ("Alte" und Neue). Zum Dilemma wird aber nun, dass HSV eigentlich raus ist, ich aber nicht glücklich mit der HSL Helligkeitsregulierung bin. Eine Entscheidung muss her was nun entfernt wird. Da wäre Feedback hoch erwünscht.
    Eine Übersicht dazu gibt es nicht. Die JSON RPC ist aber allgemein schlecht dokumentiert. (Nicht trifft es fast besser)



    Wann Hyperion 2.0 fertig wird oder zumindest mal eine Beta verfügbar ist, steht noch in den Sternen.
    Wir haben uns viel vorgenommen und ein Ende ist nicht in Sicht. Eine bessere Dokumentation gehört natürlich auch dazu. Sollte es soweit sein wirst du es rechtzeitig erfahren. Solltest du mal einen Blick riskieren wollen, schau mal in die compilehowto im neuen repo.


  • Zu deinem issue, ich meine das war schon immer so. Effect und Color setzen nur ein, wenn vom Nutzer etwas gesetzt wurde. Wie sollte es sich verhalten? Wenn die Grabber einsetzen ist es dann auch eine Farbe die aus allen leds zusammen entsteht? Momentan ist das sehr simpel gehalten.


    Hmmm, ich war/bin der Meinung dass es mal anders war. Zumindest hat mein Modul bis zur letzten Hyperion Version immer den richtigen Status angezeigt.
    Ich merke das daran weil ich einen Konfig Datei Umschalter eingebaut habe mit (ich glaube) Hyperion Version 1.03.1. Dabei habe ich natürlich auch reichlich getestet. Nach dem killen von hyperiond und Neustart mit anderer Konfig Datei wurde mir in FHEM immer kurz der Status vom aktiven Booteffekt angezeigt und danach ist es auf aus/off umgesprungen (was es ja dann auch ist) wenn der Booteffekt zu Ende ist.
    Du hast Recht, activeLedColor war auch in der älteren Version nicht gesetzt. Habe mir meinen Code nun noch einmal genau angesehen und festgestellt dass (vor Hyperion V1.03.2) nach dem Neustart und Abarbeiten des Booteffekts keine activeLedColor und keine Priorität gesetzt war. Daran habe ich ausgemacht dass Hyperion aus/off ist. Nun wird aber nach dem Booteffekt die default Priorität des Grabbers im JSON angezeigt und somit denkt mein Modul Hyperion sei im clearall Modus.
    Aber egal, wie im Issue bereits beschrieben, habe ich eine andere Möglichkeit gefunden aus dem JSON den aktuellen Status nach Neustart zu bestimmen. Habe das jetzt mal testweise in mein Modul so eingebaut und nun scheint es wieder zu funktionieren, zumindest im Testsystem. Oder gibt es mit unterschiedlichen Grabbern Unterschiede im JSON nach Neustart? Ich benutze nämlich nur den V4L2 Grabber mit 5 Sekunden Booteffekt. Nach dem Booteffekt ist Hyperion bei mir definitiv im Status aus/off und nicht clearall, was per JSON suggeriert wird. Wie verhalten sich andere Grabber? Stehen die evtl. nach Neustart wirklich im clearall Modus? Wie könnte ich sonst wirklich zuverlässig ermitteln ob off oder clearall?


    Na gut, dann werde ich mich mal weiter durch HyperCon hangeln und versuchen die Wertebereiche zu ermitteln. Dass es (noch) keine Einheitlichkeit und Einigkeit bei der Farbkalibrierung gibt macht die Sache natürlich nicht einfacher. Laut Wiki sind ja schon einige Einstellungen als deprecated gekennzeichnet, die zwar in HyperCon auch nicht mehr vorhanden sind, aber dennoch vom JSON angezeigt und auch verändert werden können. Da hilft wohl im Moment nur Ausprobieren was noch geht und mit welchen Werten. Ja, mir ist auch schon aufgefallen dass die ganze JSON Sache nicht wirklich gut dokumentiert ist.


    Die Alpha von NG habe ich natürlich auch schon entdeckt. War nur bisher zu beschäftigt das mal zu kompilieren und anzuschauen. Evtl. hat mich auch die bisher noch gar nicht vorhandene Dokumentation davon abgehalten!? Ich denke ich lasse Euch da mal noch Zeit und schaue es mir dann im Beta Stadium an.


    Gruß
    Dan

  • Leider fehlen vollkommen Anhaltspunkte für den Wertebereich von blacklevel, whitelevel, saturationGain und valueGain da es diese ja auch nicht mehr in HyperCon gibt.
    Könnt Ihr mir bitte einen Tipp geben bis wohin Werte Sinn machen? Schrittweite ist denke ich auch 0.01?


    Danke.


    Gruß
    Dan

    • Offizieller Beitrag

    so so, meine Bemühungen sind also auch schon bei Brindosch angekommen....


    Ich schalte mich mal eben mit ein, das Team ist fast komplett deutschsprachig (unsere Holländischen Freunde verstehen auch das gröbste :)
    Wir lesen im Team soweit alles immer durch, also bleibt kaum etwas "ignoriert" eventuell gibts dann Team-intern eine Absprache, aber ist halt immer schwer dann alles intern abzuklären und dann den Usern nochmal weiter zugeben, also Bemühungen etc wird alles erkannt :)


    Die Alpha von NG habe ich natürlich auch schon entdeckt. War nur bisher zu beschäftigt das mal zu kompilieren und anzuschauen. Evtl. hat mich auch die bisher noch gar nicht vorhandene Dokumentation davon abgehalten!? Ich denke ich lasse Euch da mal noch Zeit und schaue es mir dann im Beta Stadium an.


    www.serhan.in/hyperion.ng.zip gibts die version für den RPi mit PWM, ich versuchs immer aktuell zu halten...
    Momentan machts aber denke ich auch nicht viel Sinn schon damit anzufangen....wenn ein Dev eine neue Idee hat, die das ganzen Konstrukt umwirft, müsstest du jedesmal von vorne anfangen...und ich glaube das würde dir nach einer Zeit die Lust/Motivation sehr schnell rauben...und das wollen wir nicht! Wie du schon sagst,
    aber einer Beta macht es mehr Sinn einzusteigen.


    Vielen Dank für deinen Support in Sachen FHEM! Vielleicht steig ich da auch irgendwann ein, dann werde ich aufjedenfall als erstes deine Erweiterung testen! :)

  • Ach jetzt verstehe ich was du vor hast. Vielleicht sollte ich immer zuerst nach dem Ziel fragen.
    Also du möchtest darstellen was Hyperion gerade so an der Front treibt. Was den priority Teil in der serverinfo angeht kann ich mich gerade nicht mehr erinnern wie gut oder schlecht das funktioniert hat. Die Informationslage ist da ziemlich düster für deinen Zweck und es wird leider keine Verbesserungen mehr geben.


    Dein Problem ist mit 2.0 aber bereits gelöst und geht darüber hinaus. Das hilft dir jetzt natürlich überhaupt nicht.


    Eine Frage, stellst du den Farbwert auch dar oder sagst du dann "Eine Farbe läuft"?


    Ausprobieren was noch geht


    Gehen tut absolut alles, es wurde nichts entfernt. Es gilt nur auseinander zu halten, was ist alt und was ist neu. (Macht die Sache nicht schöner)


  • www.serhan.in/hyperion.ng.zip gibts die version für den RPi mit PWM, ich versuchs immer aktuell zu halten...
    Momentan machts aber denke ich auch nicht viel Sinn schon damit anzufangen....wenn ein Dev eine neue Idee hat, die das ganzen Konstrukt umwirft, müsstest du jedesmal von vorne anfangen...und ich glaube das würde dir nach einer Zeit die Lust/Motivation sehr schnell rauben...und das wollen wir nicht! Wie du schon sagst,
    aber einer Beta macht es mehr Sinn einzusteigen.


    Danke für's Bereitstellen, werde dann aber zur Beta mal mit aufspringen in Sachen Modul(weiter)entwicklung.


    Vielen Dank für deinen Support in Sachen FHEM! Vielleicht steig ich da auch irgendwann ein, dann werde ich aufjedenfall als erstes deine Erweiterung testen! :)


    Sehr gerne und ich hoffe doch darauf dass Du das Modul dann testest! Ist seit Anfang August offiziell im FHEM Repo aufgenommen.


    Übrigens kann ich in meinem SmartHome fast alle smarten Geräte per iPhone steuern/abfragen! Und das Meiste sogar per Siri.
    Auch Hyperion gehorcht somit auf's Wort, denn ich habe es auch in HomeKit integriert.
    Das macht echt Spaß per Siri.



    Ach jetzt verstehe ich was du vor hast. Vielleicht sollte ich immer zuerst nach dem Ziel fragen.
    Also du möchtest darstellen was Hyperion gerade so an der Front treibt.


    Genauuuu....



    Eine Frage, stellst du den Farbwert auch dar oder sagst du dann "Eine Farbe läuft"?


    Es wird alles dargestellt und es kann alles verändert werden.
    Hier mal ein Screenshot wie die Detailansicht mit allen Readings in FHEM aussieht:


    Gruß
    Dan


    EDIT: Hier nochmal ein Screenshot wie Euer Hyperion dann in HomeKit (hier die Eve App) aussieht!

  • Schön dass es Dir gefällt.


    Über FHEM ist mit Hyperion eigentlich alles möglich was auch die Hyperion Pro App kann + mehr...


    hyperionBin und hyperionConfigDir sind Attribute die der User setzen kann. Falls nicht gesetzt nehme ich als default /usr/bin/hyperiond und /etc/hyperion/.
    Es ist damit möglich die vorhanden Konfig Dateien in FHEM darzustellen/auszuwählen und somit zwischen den verschiedenen Konfigurationen umzuschalten. Das funktioniert sowohl auf einem lokalen System als auch per passwordless SSH.
    Ein paar User hatten sogar nachgefragt ob es nicht möglich sei aus FHEM heraus auch die Konfig Dateien einzulesen (als Readi ngs darzustellen) und veränderbar zu machen, so dass man es am Ende mit den aktuellen Einstellungen wieder in die selbe oder eine neue Konfig Datei schreiben kann. Mit der Umsetzung hatte ich bereits angefangen und dann festgestellt dass es Schwachsinn ist, denn es gibt nichts in der Konfig was zur Laufzeit mit dynamischen Werten angepasst werden müsste was nicht auch per JSON Server geht.


    Hier mal eine (nicht vollständige) Feature Liste meines Moduls in FHEM:

    • aktuellen Status ermitteln/anzeigen (aus/Farbe/Effekt/Ambilight)


    • Setzen von aus/Farben/Effekten/Ambilight


    • vollständige Farbkalibrierung durch Setzen der entsprechenden Werte


    • Quellenumschaltung (Neustart von Hyperion mit anderer Konfigurationsdatei) für lokale und remote Hosts


    • definierbares automatisches Polling


    • optimiert für Homebridge/HomeKit


    Gruß
    Dan


    P.S. Ich freue mich sehr dass ich bei Euch auf offene Ohren treffe. Hätte mich vielleicht schon mal früher melden sollen, das hätte sicher meine Entwicklung etwas erleichtert.

  • Kommunikation ist auch hier sehr wichtig. Probleme sollte man zur Sprache bringen und sie lösen wenn möglich.
    Stattliche Liste!


    Der (ssh) config switch ist drin wegen 2 Kalibrierungen oder wird er auch zur Quellenumschaltung genutzt? Beides ein heißes Thema das ziemlich oft angesprochen wird.
    Das Lesen und Schreiben der Konfigurationsdateien ist in der alpha möglich (Sollte du es doch noch später implementieren wollen).

  • Kommunikation ist auch hier sehr wichtig. Probleme sollte man zur Sprache bringen und sie lösen wenn möglich.
    Stattliche Liste!


    Der (ssh) config switch ist drin wegen 2 Kalibrierungen oder wird er auch zur Quellenumschaltung genutzt? Beides ein heißes Thema das ziemlich oft angesprochen wird.


    Das gefällt mir ;)


    Der Konfig Switch ist drin um eben Hyperion mit einer anderen Konfig neuzustarten. Was in den Konfig Dateien letztendlich konfiguriert ist legt der User über HyperCon selbst fest. Das ist nur ein Switch dafür. Natürlich kann man damit dann auch Quellen umschalten. Es gibt auch ein Kodi Modul für FHEM. In Zusammenarbeit kann dann FHEM automatisch z.B. die Kodi Konfig laden sobald man einen Film abspielt. Sobald man dann z.B. Kodi ausschaltet kann FHEM auch darauf reagieren und z.B. wieder die HDMI Konfig laden. Oder andere Farben setzen oder oder oder.
    Bei mir ist beispielsweise valueGain abhängig vom Lichtsensor. :thumbup: Damit ist das in völliger Dunkelheit nicht so sehr hell und bei Tageslicht schön kräftig!



    Oder gibt es mit unterschiedlichen Grabbern Unterschiede im JSON nach Neustart? Ich benutze nämlich nur den V4L2 Grabber mit 5 Sekunden Booteffekt. Nach dem Booteffekt ist Hyperion bei mir definitiv im Status aus/off und nicht clearall, was per JSON suggeriert wird. Wie verhalten sich andere Grabber? Stehen die evtl. nach Neustart wirklich im clearall Modus? Wie könnte ich sonst wirklich zuverlässig ermitteln ob off oder clearall?


    Hat evtl. darauf noch jemand eine Antwort?
    Ich frage auch gerade bei den FHEM Usern nach wie sich das bei denen verhält, habe aber noch keine Rückmeldung.
    Hätte diesbezüglich gerne eine stimmige Aussage um den Status wirklich zuverlässig darstzustellen. Habe das in meiner Dev Version bereits gefixt, bin aber unschlüssig ob das auf alle Grabber Konfigurationen zutrifft.


    Gruß
    Dan


    P.S. Hab mir gerade mal die WebApp zum Anpassen der Wertebereiche und Schrittweiten vorgenommen. Die bietet zumindest Anhaltspunkte... :)

  • Ich denke nun habe ich das Muster durchschaut um den richtigen Status zwischen off und clearall nach einem Starteffekt zu erkennen.
    Habe jetzt nochmal einige Zeit getestet und nun scheint es zuverlässig zu funktionieren. :omg:
    Das Update steht ab später dann für alle updatewilligen FHEM User zur Verfügung.
    Bin gespannt ob nun alles richtig erkannt wird oder ob es Klagen gibt.:eek:
    Die Werte und deren Bereiche habe ich auch gleich mit angepasst.


    Gruß
    Dan

  • Ja, hyperion-remote ist im Prinzip nichts anderes als eine Brücke von Kommandozeile nach JSON PRC. (Die ja nicht dokumentiert ist :D)
    Effekte können zukünftig (zusätzlich) selbst eingestellt, getestet und abgespeichert werden.

  • Ich habe es gerade so probiert:
    {"effect":{"name":"Knight rider","args":{"speed":2.0}},"command":"effect","priority":0}


    Es kam auch {"success":true} aber der Effekt wurde nicht eingeschaltet.


    Gruß
    Dan

  • Kannst du mal kurz gegen testen, ob genau das über hyperion-remote funktioniert?
    hyperion-remote --effect 'Knight rider' --effectArgs '{ "speed" : 2.0}' --priority 0


    Sorry, bin wegen anderer Projekte bisher nicht dazu gekommen das in Ruhe zu testen, kommt aber noch und dann gibt's auch ein Feedback dazu.


    Leider scheint die Status Ermittlung immer noch nicht zuverlässig zu klappen!
    Bin mir immer noch ziemlich sicher dass das JSON einfach nicht den richtigen Status aus gibt (seit V1.03.2).
    Bei meiner config.json mit Starteffekt und V4L2 Grabber geht das Licht aus nach dem Starteffekt, ergo müsste "activeLedColor":[0,0,0] sein, ist aber "activeLedColor":[]. Bei einem anderen Forenmitglied mit Kodi Grabber geht nach dem Hyperion Start direkt das Ambilight (clearall) an und auch bei ihm ist (ja auch richtig) "activeLedColor":[]. Ich konnte sonst noch etwas an den Prioritäten ausmachen, aber auch diese sind identisch.
    Ich habe mein JSON und sein JSON gegeneinander verglichen und es gibt keinerlei Unterscheidungsmerkmal. Es ist also mit Blick auf das ausgegebene JSON nicht 100% möglich zu ermitteln ob Hyperion nach dem Start aus oder clearall ist.
    Es wäre großartig wenn sich das evtl. nochmal jemand anschauen könnte.


    Vielen Dank.


    Gruß
    Dan

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!