Neues Modul - 66_EPG.pm | TV Programm,Tabelle, FTUI (Anregung,Erweiterung,Tests)

[HomeAuto_User]

 
Mit dem alten Modulstand lieferte der "Event monitor" für das EPG-Device:

Code Auswählen Erweitern


  2020-01-15 19:39:45.086 EPG myEPG loadEPG_now accomplished
  2020-01-15 19:39:51.122 EPG myEPG all EPG channel information loaded

Mit dem neuen Modulstand liefert der "Event monitor" für das EPG-Device:

Code Auswählen Erweitern


  2020-01-16 06:27:51.917 EPG myEPG loadEPG_now accomplished

Neben dem Wiedereinführen des fehlenden Events, würde ich vorschlagen, "accomplished" durch "started" und "loaded" durch "processed" zu ersetzen. Kann aber auch sein, dass ich den Sinn der Events falsch verstehe ...

Zum Stand von gestern abend ist noch anzumerken, dass das Reading FTUI_Info zwar angelegt wurde; allerdings ohne ein Event auszulösen ...

Das ist kein Problem und ist in Ordnung. Du verstehst es nicht falsch und die Anpassung von dir finde ich sogar passender für den User.

@HomeAuto_User

Ich habe eben noch einmal den aktualisierten Stand aus dem genannten Branch aktiviert und jetzt wird kein Reading mehr befüllt, sondern es geht ein Dialog auf - sehr schön.

Die get-Funktion von "außen" aufgerufen, liefert allerdings eine leere Antwort - das machte mich stutzig. Ein wenig Probieren brachte eine Erklärung ans Licht und das Verhalten kann so nachvollzogen werden:

• 
  Starte eine erste, interaktive FHEM-Sitzung und bleibe z.B. auf der Startseite stehen
  


• 
  Starte eine zweite, interaktive FHEM-Sitzung und gehe zur EPG-Device-Detailseite
  


• 
  Nun beide FHEM-Sitzungen so positionieren, dass beide zu sehen sind
  


• 
  Auf der EPG-Device-Detailseite dann z.B. "get <EPG-Device> loadEPG_now" ausführen
  


• 
  Ergebnis ist: Auf der EPG-Device-Detailseite geht irgendwann die Dialogbox auf; in der anderen Sitzung aber auch ...
  


• 
  Von wo das get ausgelöst wird, ist dabei unerheblich. Also Detailseite oder Browserzeile oder FTUI oder ... jede ungefilterte FHEM-Sitzung "profitiert" davon und sieht die Dialogbox ...
  

Ich werde es nachvollziehen bzw. nochmal überdenken. Deine Schilderung ist richtig und ich weiß auch wieso es abbricht. Ich werde vermutlich nicht drum herum kommen zusätzliche Kommandos für eine FTUI Bereitstellung zu realisieren.

[OdfFhem]

@HomeAuto_User

Wo Du gerade dabei bist, über das Thema nachzudenken ...

Momentan denke ich, dass FTUI hauptsächlich dazu dienen wird, die gemachten Einstellungen des FHEM-Devices zu visualisieren; es ist keine eigenständige Parallelwelt. Daraus folgt dann, dass im FHEM-Device unterschiedliche Routinen (für Jetzt, Prime, Tag, ...) bereitstehen, um den Nutzerwunsch umzusetzen. Die dabei aufbereiteten Daten werden in einer "JSON-Variablen" gespeichert und diese kann über EINE get-json-Routine für die Anforderung der JSON-Daten ausgeliefert werden - x-malige Auslieferung erfordert keine x-fache Aufbereitung.

In einem zukünftigen Entwicklungsschritt wäre es mehr als schön, wenn es - wie bei vielen anderen, tagesabhängigen Modulen auch - eine automatische Aktualisierung zu einem bestimmten Zeitpunkt geben würde. Dies müsste meiner Ansicht nach mit einem alignTime-Attribut feingesteuert werden können, da nicht jeder den nicht zu unterschätzenden Neuberechnungsaufwand um 00:00:00 oder einem anderen, fremdbestimmten Zeitpunkt haben will.

Sollten Deine Gedanken in eine ganz andere Richtung gehen, zunächst einfach mal diesen Beitrag ignorieren ...

[HomeAuto_User]

Ich habe soeben mal etwas umgestellt im Code das du FTUI get Befehle hast.
Teste dies mal bitte. Die Befehle erhälst du mit dem Attribut FTUI_support.
Mich würde es interessieren ob dies in die richtige Richtung geht. 
Simuliert habe ich es derzeit nur hier am normalen Desktop.

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/fhem/EPG/pre-release_FTUI/controls_EPG.txt

[OdfFhem]

@HomeAuto_User

Neuen Modulstand aktiviert - der "Event monitor" bestätigt, dass es ein neuer Stand ist ...

Es gibt jetzt zwar die neuen FTUI-get-Routinen, aber das Ergebnis ist immer noch wie vorher. Jede interaktive Sitzung bekommt eine Dialogbox und z.B. FTUI eine leere Antwort.

[HomeAuto_User]

Es gibt jetzt zwar die neuen FTUI-get-Routinen, aber das Ergebnis ist immer noch wie vorher. Jede interaktive Sitzung bekommt eine Dialogbox und z.B. FTUI eine leere Antwort.

Eine leere Information kann ich mir nicht erklären weil bei mir ist diese auf dem Bildschirm gefüllt.

Jede interaktive Sitzung bekommt eine Dialogbox und z.B. FTUI eine leere Antwort.

Hier muss ich einen Filter setzen. Wie verläuft dies bei FTUI?
Ich könnte nun den Filter auf das Device setzen oder die Detailansicht, greift diese aber dann dort?

Gibt es ein kurzes Beispiel wie ich mir dies auf die "schnelle" in FTUI einbinden kann. Ich habe mir extra dafür die Oberfläche nun installiert um das ggf. selbst nachvollziehen zu können.

[OdfFhem]

@HomeAuto_User

Eine leere Information kann ich mir nicht erklären weil bei mir ist diese auf dem Bildschirm gefüllt.

Die überall aufploppenden Dialogboxen sind nicht leer, aber der, der die Daten angefordert hat (z.B. Browserzeile), bekommt keine Daten ...


Zum Testen brauchst Du kein FTUI. Es reicht, den folgenden Aufruf in die Browserzeile einzugeben (lediglich dein_server, evtl. 8083, EPG-Device myEPG und csrf-token müssen angepasst werden):

Code Auswählen Erweitern


http://dein_server:8083/fhem/?detail=myEPG&dev.getmyEPG=myEPG&cmd.getmyEPG=get&arg.getmyEPG=xyz_loadEPG_now_FTUI&val.getmyEPG=&fwcsrf=csrf_123456789012345&XHR=1


[HomeAuto_User]

Auf jedenfall fand ich soeben noch einen Fehler welcher zur Übergabe hinderlich war zum lokalen test.
Kann es sein, das die Daten noch leer sind weil diese 2 Sekunden später eintreffen?

Entnehme ich deinem Beispiel, das dein Device myEPG benannt wurde und du den Befehl xyz_loadEPG_now_FTUI ausführt?

Code Auswählen Erweitern


http://dein_server:8083/fhem/?detail=myEPG&dev.getmyEPG=myEPG&cmd.getmyEPG=get&arg.getmyEPG=xyz_loadEPG_now_FTUI&val.getmyEPG=&fwcsrf=csrf_123456789012345&XHR=1


[OdfFhem]

@HomeAuto_User

myEPG heisst das EPG-Device und den Befehl habe ich bei mir nur "neutralisiert", da ich sonst nicht mehr im FTUI weiterkomme - also xyz_ bitte noch entfernen.

[HomeAuto_User]

@HomeAuto_User

myEPG heisst das EPG-Device und den Befehl habe ich bei mir nur "neutralisiert", da ich sonst nicht mehr im FTUI weiterkomme - also xyz_ bitte noch entfernen.

Das habe ich natürlich gemacht.
Hier der Code welcher eine leere Seite bringt, also nichts.

Code Auswählen Erweitern

http://raspberrypi:8083/fhem/?detail=EPG&dev.getEPG=EPG&cmd.getEPG=get&arg.getEPG=loadEPG_now_FTUI&val.getEPG=&fwcsrf=csrf_123456789012345&XHR=1

Zum Verständnis, wenn ich den Befehl so aufrufe über die Detailansicht, so erhalte ich nach der Verarbeitungszeit eine Dialogbox mit der JSON Ausgabe.

Code Auswählen Erweitern

FW_directNotify("#FHEMWEB:WEB", "FW_okDialog('$data')", "");
So erzeuge ich die Ausgabe, da ich an der stelle mit einem Retrun nichts ausgegeben bekommen.

[OdfFhem]

Soweit ich mich erinnere, muss man nur den reinen Wert zurückgeben. Dein Aufruf ist aber scheinbar der Grund, dass alle Sitzungen die Dialogbox bekommen.

Bin aktuell unterwegs, daher kürzer.

[HomeAuto_User]

Soweit ich mich erinnere, muss man nur den reinen Wert zurückgeben. Dein Aufruf ist aber scheinbar der Grund, dass alle Sitzungen die Dialogbox bekommen.

Die Einschränkung habe ich vollzogen und erhalte auch nur in der Detailansicht nun die Ausgabe.
Natürlich weiterhin ist der Return leer aber das Kommano funktioniert, da ich dieses nach deiner Vorgabe aufrufen kann.

Bin aktuell unterwegs, daher kürzer.

Kein Problem, irgendwann wird schon der Fehler gefunden. 

EDIT: Ich denke zu wissen woran es liegt. Ein normaler Return nach dem ich den BlockingCall aufgerufen habe erscheint nicht, als wenn ich dies aus dem "normalen" Programm aufrufen würde. **weiß nicht so richig wie ich das korrekt formuliere**

EDIT 2: JA es sit so, habe nun mal an anderer Stelle vor dem Blocking eine Return ergänz und da erhalte ich diesen auch als Ausgabe. Ein Workaround hätte ich ggf. im Kopf.

[HomeAuto_User]

@OdfFhem

ich sah im Browser mein JSON 

Zur Information, du kannst mal bitte ein Update machen aus diesem Branch und dann solltest du eine Ausgabe erhalten mit Informationen.

- cmd view_FTU_data
- darin sind die aktuellen Informationen jeweils vom letzten Kommando was via get abgerufen wurde

[OdfFhem]

@HomeAuto_User

Hatte ich bereits gesehen und prompt aktiviert.

Sieht gut aus. Alle drei Hauptvarianten (now, Prime, today) funktionieren - prima.

[OdfFhem]

@HomeAuto_User

Jetzt, wo eine weitere Hürde erfolgreich gemeistert wurde, kann man ja an die weiterhin offenen Punkte gehen ...


Hast Du noch Zeit und Lust, den Hauch von FTUI-Spezial loszuwerden? (auch das besagte Attribut ist damit überflüssig; gibt's in der Art in keinem sonstigen Device)

Die neue get-Routine ist allgemein verwendbar und sollte daher auch einen allgemeineren Namen bekommen.
In einigen anderen Devices wird für diesen Zweck folgende Nomenklatur verwendet:

Code Auswählen Erweitern


get <device_name> json

Unter Umständen kann man später die Ausgabe noch mit Parametern beeinflussen; aber erstmal egal.

Anschließend wäre es noch schön, wenn wir eine typische JSON-Struktur hinbekommen würden. Ich kann jetzt nicht einschätzen, an was der Array-Widerstand liegt, aber vielleicht kannst Du ja mal genauer sagen, wo das Problem liegt.

Man darf ja auch mal träumen und somit wird es in hoffentlich gar nicht so ferner Zukunft einen Mechanismus für die automatische Aktualisierung geben ...


Wie sieht denn Dein Plan aus?

[HomeAuto_User]

@OdfFhem

Jetzt, wo eine weitere Hürde erfolgreich gemeistert wurde, kann man ja an die weiterhin offenen Punkte gehen ...

gern können wir uns denen stellen und ich lerne ja auch nur noch zusätzlich dabei

Hast Du noch Zeit und Lust, den Hauch von FTUI-Spezial loszuwerden? (auch das besagte Attribut ist damit überflüssig; gibt's in der Art in keinem sonstigen Device)

Die neue get-Routine ist allgemein verwendbar und sollte daher auch einen allgemeineren Namen bekommen.
In einigen anderen Devices wird für diesen Zweck folgende Nomenklatur verwendet:

Code Auswählen Erweitern


get <device_name> json


Die Umbennung ist kein Problem und das Attribut ist schönheitssache aber kann auch gern eingespart werden. Entweder man hat Daten in der Ausgabe oder es kommt eben der Hinweis als Return nichts drin.

Anschließend wäre es noch schön, wenn wir eine typische JSON-Struktur hinbekommen würden. Ich kann jetzt nicht einschätzen, an was der Array-Widerstand liegt, aber vielleicht kannst Du ja mal genauer sagen, wo das Problem liegt.

Ich habe lange überlegt und ich denke, wo ich heute mal ein List gemacht habe, kam mir der Punkt wieso ich dies ausgerechnet so machte.
Das einlesen der Daten beruht darauf, das am anfang der Daten immer die Kanäle stehen.

Bsp:

Code Auswählen Erweitern

  <channel id="VOXup.de">
    <display-name lang="de">VOXup</display-name>

Da aber die Informationen der Sendung

Code Auswählen Erweitern

<programme start="20200116001500 +0100" stop="20200116011500 +0100" channel="VOXup.de">

mit der ChannelID gekennzeichnet sind, so habe ich zu beginn alle Kanäle in die Struktur eingetragen mit der ChannelID und darunter liegend den Displayname welcher für uns User bekannt ist.

Das siehst du auch wenn du ein list deines Devices machst.
Somit ergibt sich diese Struktur.

Sobald ich diese auch mit dem JSOn Online öffne, so erhalte ich
- Liste ---> ChannelID´s ---> zugehörige Daten wie Displayname und EPG

PS: wie kann man die Daten (JSON) im FTUi darstellen? Ich würde dies gern auch zur Ansicht hier lokal haben um selbst das ganze beim Testen besser nachvollziehen zu können.