Neues Modul für Hyperion Server 98_Hyperion.pm

[DeeSPe]

Hallo Dan,
mir ist gerade aufgefallen, dass "mode_before_off" nie auf "clearall" wechselt und somit auch das toggle zwischen "off" und "clearall" nicht funktioniert.
Setze ich "clearall", wechselt der aktuelle Modus auf "off" und nicht, wie erwartet auf "clearall".
Könntest du das bitte noch mal kontrollieren?

Das ist sehr merkwürdig, denn das klappt bei mir wie es soll!
Wenn ich "set <name> clearall" oder "set <name> mode clearall" absetze geht auch das Reading "mode_before_off" auf "clearall". Das togglen klappt deshalb bei mir auch wie gewünscht.
Gibt es eine bestimmte Konstellation in der das auftritt?

Des weiteren ist mir noch etwas unverständliches bei dem Reading "priority" aufgefallen:
Ich habe das Attribut "hyperionDefaultPriority" auf 99 gesetzt, so sollte beim steuern über das Modul ja alles mit priority 99 eingestellt werden, setze ich aber ein "clearall" ab, steht im Reading "122". Woran kann das liegen?

Das ist eben genau so!
Sobald man clearall absetzt werden alle Prioritäten gelöscht, der Video Grabber aktiviert und die default Priorität vom Video Grabber gesetzt. Diese ist in der Konfig Datei zu finden.

Und noch ein Wunsch:
Wenn ich es richtig verstanden habe werden beim "set Hyperion off" die LEDs einfach auf RGB 000000 gesetzt, oder? Aufgrund das dies auch mit DefaultPriority gesetzt wird, hat dies aber keinen Einfluss auf Einstellungen, die mit einem niedrigeren priority Wert gesetzt wurden. Spricht etwas dagegen "off" immer mit der höchste n Priorität (0) abzusetzen, damit bei "off" wirklich alles aus geht!?

Genau so war es (unbeabsichtigt) bis vor einigen Updates.
Das ist aber nicht sinnvoll da das Modul sonst den Status von Hyperion verändern könnte der gar nicht von ihm selbst gesetzt wurde, weil evtl. ein anderes Device einen Befehl mit höherwertiger Priorität gesetzt hat.
Um das FHEM Device zum absoluten Hyperion Master Device zu machen ist es nötig die default Priorität auf 0 zu stellen, was sie auch per default ist.

Ich hoffe ich konnte "Licht ins Dunkel" bringen...

Gruß
Dan

[Schlimbo]

Hallo Dan,

Ich habe gerade noch ein wenig getestet und herausgefunden, dass das Reading "mode" und   "mode_before_off" nicht stimmt, wenn eine andere Remote Quell Hyperion steuert (z.B. KODI auf dem SchieldTV oder das Enigma2 Plugin "Enigmalight")  KODI verbindet sich über den PROTO-Server (Port: 19445) und EnigmaLight über den Boblight-Server (Port: 19333), Sobald einer von beiden mit Hyperion verbunden ist wechselt der Modus im Modul auf "off" und "mode_before_off" bleibt auf dem letzten eingestellten wert.

Beispiel:
-Über FHEM habe ich rgb 0000FF mit prio 99 eingestellt --> mode = rgb ; mode_before_off = rgb
-Jetzt starte ich meinen Enigma Receiver, er verbindet sich mit prio 122 mit Hyperion, da die Prio von FHEM aber höher ist bleiben die LEDs auf 0000FF -->  mode = rgb ; mode_before_off = rgb
-Um das Ambilight vom Enigma Receiver zu bekommen setzt ich jetzt ein "clearall" ab. --> mode = off ; mode_before_off = rgb

Da sich hier der Status von mode_before_off nicht auf "clearall" anderen, sondern auf den vorhergegangenen wert "rgb" stehen bleibt funktioniert jetzt das toggle nicht wie gewünscht.

Ich hoffe ich könnte es einigermaßen verständlich erklären, wenn nicht bitte einfach fragen.

Gruß Schlimbo

[Schlimbo]

Genau so war es (unbeabsichtigt) bis vor einigen Updates.
Das ist aber nicht sinnvoll da das Modul sonst den Status von Hyperion verändern könnte der gar nicht von ihm selbst gesetzt wurde, weil evtl. ein anderes Device einen Befehl mit höherwertiger Priorität gesetzt hat.
Um das FHEM Device zum absoluten Hyperion Master Device zu machen ist es nötig die default Priorität auf 0 zu stellen, was sie auch per default ist.

Okay, das macht natürlichen Sinn.

In meiner Konstellation nutze ich es etwas anders:
Ich setze mit dem Modul unterschiedliche Modi mit unterschiedlichen Priority Werten.
Zum Beispiel:
Normales Licht wird bei mir mit DefaultPriority 99 eingestellt.
Kommt jetzt ein Anruf über die FritzBox, signalisiere ich dies mit blinken der LEDs in rot, dies wird mit einer höheren Priorität (Wert 90) gesetzt, ist der Anruf angenommen oder vorbei wird einfach die Prio 90 gelöscht und die vorhergegangenen Farbe ist wieder aktiv, ohne sich vorher merken zu müssen was aktiv war.

Ich hab eine ganze Reihe von Signalisierungen mit unterschiedlichen Priorisierungen z.B.

Code Auswählen Erweitern

-msgCmdLightHigh --> set %DEVICE% effect Blink_red 5 0
-msgCmdLight --> set %DEVICE% effect Blink_green 5 1
-msgCmdLightLow --> set %DEVICE% effect Blink_blue 5 3
-Telefon klingelt --> set <name>  effect Strobe_red  90
-Luftfeuchtigkeit zu hoch --> set <name>  rgb 0000FF 0 94
Hiermit kann ich sicherstellen, dass wichtigere Meldungen immer angezeigt werden.

Deswegen wäre es für mich schön, wenn "set <name>  off" trotzdem alles ausschaltet.
Ware es möglich hierfür noch ein extra Attribut zu spendieren z.B "hyperionOffPriority"?
Ist dies gesetzt wird der "off" Befehl mit dieser Priority ausgeführt, ist er nicht gesetzt wird "hyperionDefaultPriority" benutzt.

[DeeSPe]

Ich habe Dich schon verstanden.

Jetzt wo Du das mit dem Grabber sagt kann ich Dich beruhigen. Es liebt nicht am Modul, sondern an Hyperion.
Seit der letzten Version (V1.03.2) ist das leider ein Bug von Hyperion, den ich schon seit einiger Zeit bei Hyperion im Forum mit den Programmierern diskutiere.
Das Problem ist dass Hyperion keine activeLedColor mehr anzeigt wenn es nach einem Starteffekt die LEDs ausschaltet. Es sollte dann eigentlich activeLedColor:[0,0,0] drin stehen.
Ich habe dann versucht den Unterschied an den unterschiedlichen Prioritäten auszumachen, das funktioniert leider nur bedingt da die Zustände unterschiedlich mit unterschiedlichen Grabbern sind. Da ich keinen KODI Grabber benutze/habe, konnte ich das nur an meinem V4L2 Grabber testen und dort passt der Status eben gerade mit den vorhandenen Prioritäten.
Ich hoffe auf ein Update von den Hyperion Machern, bin aber leider nicht so zuversichtlich da alle an Hyperion.ng schrauben.


Interessant wie Du so die unterschiedlichen Möglichkeiten von Hyperion benutzt! Bin begeistert!
Klar kann ich Dir noch so ein Attribut einbauen wenn es nützlich ist! Ich schaue mal.

Gruß
Dan

Gruß
Dan

[Schlimbo]

Ich habe dann versucht den Unterschied an den unterschiedlichen Prioritäten auszumachen, das funktioniert leider nur bedingt da die Zustände unterschiedlich mit unterschiedlichen Grabbern sind. Da ich keinen KODI Grabber benutze/habe, konnte ich das nur an meinem V4L2 Grabber testen und dort passt der Status eben gerade mit den vorhandenen Prioritäten.

Das heißt du wertest die aktuelle Priorität aus und wenn sie mit der in der Hyperion-Konfig übereinstimmt, weißt du, dass der Grabber aktiv ist!?
Könntest du diese Auswertung auch für die anderen Quellen einbauen?

Ich habe für PROTO und Boblight Server in der Konfig jetzt die gleiche Priorität hinterlegt, wie sie auch von den Remote Geräten gesetzt wird:

Code Auswählen Erweitern

        // NO V4L2 GRABBER CONFIG
// FRAME GRABBER CONFIG
"framegrabber" :
{
"width" : 64,
"height" : 64,
"frequency_Hz" : 10.0,
"priority" : 890
},

// JSON SERVER CONFIG
"jsonServer" :
{
"port" : 19444
},

// PROTO SERVER CONFIG
"protoServer" :
{
"port" : 19445,
"priority" : 800
},

// BOBLIGHT SERVER CONFIG
"boblightServer" :
{
"port" : 19333,
"priority" : 122
},
Somit könnte hierüber doch auch der aktuelle modus erkannt werden, oder?

Klar kann ich Dir noch so ein Attribut einbauen wenn es nützlich ist! Ich schaue mal.

Das wäre super, danke.

Gruß
Schlimbo

[DeeSPe]

Das heißt du wertest die aktuelle Priorität aus und wenn sie mit der in der Hyperion-Konfig übereinstimmt, weißt du, dass der Grabber aktiv ist!?
Könntest du diese Auswertung auch für die anderen Quellen einbauen?

Das ist nicht so!
Die Konfig Datei wird nicht ausgelesen. Die Priority Werte aus der Konfig sind auch nicht im JSON enthalten.
Ich hatte mir vor einiges Zeit angesehen ob das eine mögliche Lösung wäre, habe es aber verworfen da ich keinen Zugriff auf die Konfig Datei einbauen wollte, da dieses dann für den Benutzer zwingen wäre zu konfigurieren. Auch die richtige Priority des jeweiligen Grabbers in der Konfig Datei zu finden ist nicht ganz einfach. Nach jedem Neustart mit einer anderen Konfig Datei müsste dann auch wieder die Konfig Datei geprüft werden.
Ganz ehrlich ist mir das viel zu viel Aufwand nur um diesen Bug zu umgehen der nicht an meinem Modul liegt sondern an Hyperion selbst. Und ob das wirklich DIE Lösung wäre weiß ich auch nicht! Und dann kommt vielleicht morgen doch ein Hyperion Update und alles war umsonst.
Verstehe mich nicht falsch, ich programmiere sehr gerne für FHEM, aber es muss den Aufwand wert sein!

Gruß
Dan

[Schlimbo]

Kein Thema, das verstehe ich voll und ganz.
Dann hoffe ich mal, dass es irgendwann in Hyperion noch gefixt wird...
Noch mal vielen danke für das tolle Modul, den klasse support und die Zeit die du hier investierst.

Gruß
Schlimbo

[DeeSPe]

Deswegen wäre es für mich schön, wenn "set <name>  off" trotzdem alles ausschaltet.
Ware es möglich hierfür noch ein extra Attribut zu spendieren z.B "hyperionOffPriority"?
Ist dies gesetzt wird der "off" Befehl mit dieser Priority ausgeführt, ist er nicht gesetzt wird "hyperionDefaultPriority" benutzt.

Die angehängte Version hat das was Du möchtest.
Das Attribut hyperionDefaultPriorityOff ist hinzugekommen.

Probier mal bitte ob das so funktioniert wie Du möchtest, sollte es aber.

Gruß
Dan

[Schlimbo]

Danke für die Änderung.
Das Ausschalten funktioniert so, jedoch habe ich dadurch jetzt ein weiteres Problem:
Da "off" jetzt mit einer höheren Priorität gesetzt wird (bei mir Priority 0) als alle anderen Befehle, kann ich nach dem "off" Befehl erst wieder etwas steuern wenn ich ein "clear 0" ausführe.

Jetzt wird die ganze Sache doch wieder komplizierter als anfangs gedacht, fällt dir hierzu noch eine einfache Möglichkeit ein, dies zu beheben?

edit:
Ein Möglichkeit wäre evtl. bei einem "set <name> on" immer ein "set <name> clear <hyperionDefaultPriorityOff>" mit zu geben.

Gruß
Schlimbo

[DeeSPe]

Danke für die Änderung.
Das Ausschalten funktioniert so, jedoch habe ich dadurch jetzt ein weiteres Problem:
Da "off" jetzt mit einer höheren Priorität gesetzt wird (bei mir Priority 0) als alle anderen Befehle, kann ich nach dem "off" Befehl erst wieder etwas steuern wenn ich ein "clear 0" ausführe.

Jetzt wird die ganze Sache doch wieder komplizierter als anfangs gedacht, fällt dir hierzu noch eine einfache Möglichkeit ein, dies zu beheben?

edit:
Ein Möglichkeit wäre evtl. bei einem "set <name> on" immer ein "set <name> clear <hyperionDefaultPriorityOff>" mit zu geben.

Gruß
Schlimbo

Genau wegen diesem Problem ist das halt Käse!
Du kannst nur "clear 0" absetzen oder "clearall" um da wieder rauszukommen.
Klar könnte man beim Wiedereinschalten prüfen ob die Priorität dem Attribut hyperionDefaultPriority entspricht bzw. der übergebenen Priority. Wenn nicht setzt man vorher automatisch ein clear der entsprechenden Priority ab, bevor man wieder einschaltet.

Das ist aber alles blöd ehrlich gesagt, da es ja dem Konzept der entsprechenden Priorisierung entgegen wirkt!

Gruß
Dan

Gruß
Dan

[Schlimbo]

Ja, das habe ich jetzt auch gemerkt, es wird dadurch nur komplizierter.
Okay, dann lassen wir das mit dem "hyperionDefaultPriorityOff" besser sein.

Gruß
Schlimbo

[Bootscreen]

@DeeSPe: sachma ist es machbar ein Attribut zu bekommen ala "autoDisableAfter" ? So das man dort einen Wert X eintragen kann und wenn er dann X mal ein "Can't connect" bekommt sich selbst disabled? In den letzten Tagen klappt nämlich mein Auto Disable nicht mehr zu 100%

[DeeSPe]

Ja, das habe ich jetzt auch gemerkt, es wird dadurch nur komplizierter.
Okay, dann lassen wir das mit dem "hyperionDefaultPriorityOff" besser sein.

Gruß
Schlimbo

Das testweise einzubauen war glücklicher Weise kein großer Aufwand.
Schön dass ich Dich damit überzeugen konnte das es keinen Sinn ergibt!

@DeeSPe: sachma ist es machbar ein Attribut zu bekommen ala "autoDisableAfter" ? So das man dort einen Wert X eintragen kann und wenn er dann X mal ein "Can't connect" bekommt sich selbst disabled? In den letzten Tagen klappt nämlich mein Auto Disable nicht mehr zu 100%

Ich denke mal drüber nach ob und wie das Sinn machen könnte.

Eigentlich würde ich (an Deiner Stelle) aber mal versuchen herauszubekommen warum Dein AutoDisabler nicht mehr funktioniert.
Per notify sollte man den doch auch selbst erstellen können.
Ala notify auf state:ERROR und bei jedem triggern des notify ein Reading hochzählen. Dann noch ein zweites notify auf das Zählreading und wenn dieses Zahl X erreicht hat setzt es Hyperion auf disable.
Oder habe ich das falsch verstanden?

Gruß
Dan

[Bootscreen]

Da bin ich schon auf der Suche, komm aber zu keinem Ergebnis. Mein AutoDisabler prüft das Kodi Device und scheinbar bekommt er da manchmal nicht mit wenn Kodi disconnected. Zu 99% klappt es und zu 1% leider nicht.
Hab jetzt aber, mit deinem Ansatz, einen zweiten AutoDisabler zusammen geschustert welcher nur auf das Hyperion Device reagiert. Falls es jemand intressiert oder ebenfalls einsetzen möchte:
Es müssen lediglich in der ersten Zeile das triggernde Device geändert werden und in der zweiten Zeile der Log-Eintrag raus oder auf die eigenen Bedürfnisse angepasst werden.
Apropo gibt es eine Variable wmoit ich im notify oder DOIF den Namen des notifys oder DOIF's bekomme? $NAME gibt mir ja nur den des triggernden Devices.

Code Auswählen Erweitern

hyperion:serverResponse:.*ERROR.* {
   Log3 "hyperion.state.notify", 3, "hyperion.state.notify \"$EVENT\"";
   
   my $count=ReadingsVal($NAME, "errorCount", 0);
   $count++;
   
   if($count < 5)
   {
      fhem("setreading $NAME errorCount $count");
   }
   else
   {
      fhem("setreading $NAME errorCount 0");
      fhem("attr $NAME disable 1");
   }
}


//Nachtrag:
Ich glaub ich hab grad beim stöbern das Problem gefunden warum hyperion manchmal beim starten von FHEM, FHEM aufhängt.
Und zwar in Zeile 466

Code Auswählen Erweitern


    InternalTimer(gettimeofday() + $hash->{INTERVAL},"Hyperion_GetUpdate",$hash,1);

Ich glaub die letzte 1 ist das Problem. Zitat aus dem Wiki (http://www.fhemwiki.de/wiki/DevelopmentModuleAPI#InternalTimer)

$waitIfInitNotDone optional
ACHTUNG: Dieser Parameter sollte unter keinen Umständen verwendet werden!
Dieser Parameter verändert das Verhalten von InternalTimer() während der Initialisierung von FHEM. Ist dieser Parameter auf 1 gesetzt und FHEM noch in der Initialisierungsphase (Konfiguration einlesen), so wird ein Sleep des Hauptprozess durchgeführt, bis der gewünschte Zeitpunkt $timestamp erreicht ist. Dadurch wird der gesamte FHEM-Prozess solange blockiert und ist in dieser Zeit nicht ansprechbar. Dieses Verhalten ist besonders Relevant bei der Nutzung von InternalTimer() in der Define-Funktion eines Moduls und sollte daher so keinesfalls benutzt werden. Um Funktionsaufrufe zu Verzögern, bis die Initialisierung beendet ist, sollte auf das Event global:INITIALIZED in der Notify-Funktion gewartet werden.
Standardwert: 0

[DeeSPe]

Genau so meinte ich das mit notify!

Schaue ich mir an mit der 1.

Gruß
Dan