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

[OdfFhem]

@HomeAuto_User

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

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.

Wie gesagt, es ist eine allgemein verwendbare get-Routine und hat nichts mit FTUI direkt zu tun. FTUI ist nur ein Nutzer dieser get-Routine.

Ich bin mir auch nicht sicher, ob ich sie wirklich nur json nennen würde oder nicht besser jsonEPG in Anlehnung an Deine anderen Routinen. Einen spezifischeren Namen kann man auch deutlich besser suchen, usw.

Es gibt eigentlich nie den Fall, dass keine Daten zurückgegeben werden; im schlechtesten Fall sollte ein leeres JSON-Objekt(-Array) zurückkommen.

Ich habe lange überlegt ...

Wenn man rein aus technischer Sicht überlegt, wird von der neuen Routine ein JSON-Objekt EPG zurückgegeben. Daraus folgert, dass das oberste Objekt einen Namen haben müsste - z.B. "EPG".

Ein EPG-Objekt besteht aus einer Liste von Sendern. Daraus folgt, dass der Wert aus einem Array von Sender-Objekten bestehen sollte.

Ein Sender-Objekt hat keinen Namen, sondern nur Eigenschaften und Werte. Eine Eigenschaft davon ist z.B. die Liste von Sendungen; folgerichtig wird der Wert dieser Liste als Array dargestellt. Würde man Deiner bei den Sendern angewandten Theorie folgen, dürften die Sendungen auch nicht als Array, sondern als einzelne Eigenschaften umgesetzt werden.

wie kann man die Daten (JSON) im FTUi darstellen?

Ich weiss jetzt nicht genau, ob Du damit die Darstellung der reinen JSON-Daten meinst - die gibt es eigentlich nicht.

Aufgehübscht könnte es zum Beispiel wie auf den Screenshots aussehen; ich habe aber zugegebenermaßen keine Ahnung, was @pah im Sinn hat ...

[HomeAuto_User]

Dann würde jedenfalls als nächstes heute Abend
- den Namen der Routine ändern
- Attribut bereinigen
- commref anpassen

Struktur JSON, so stellt das natürlich einen anderen Aufwand dar.

Ich weiß nicht so richtig wie man dies am besten beginnt.

Als oberen Punkt EPG als Anfang wäre kein Problem. Darin aber die Sender als Array stelle ich nicht schwierig vor zuzugreifen weil ich dann ständig dies durchlaufen muss oder wie eine ÜbersetzungsTable benötige.


Gesendet von iPhone mit Tapatalk Pro

[OdfFhem]

@HomeAuto_User

Wie hast Du denn das Array der Sendungen erstellt, ist ja im Prinzip mit den Sendern das gleiche oder nicht?

Wenn Du möchtest, kann ich aber auch mal mit in den Quellcode schauen ...
Da wäre es gut, wenn Du mir genauer sagst, wo die besagte Aufbereitungstelle ist ...

[HomeAuto_User]

@HomeAuto_User

Wie hast Du denn das Array der Sendungen erstellt, ist ja im Prinzip mit den Sendern das gleiche oder nicht?

Wenn Du möchtest, kann ich aber auch mal mit in den Quellcode schauen ...
Da wäre es gut, wenn Du mir genauer sagst, wo die besagte Aufbereitungstelle ist ...

Ab hier https://github.com/fhem/EPG/blob/168c74eecc9d216ea355f2ab6720ec1bd39f64c0/FHEM/66_EPG.pm#L1173 werden die Kanäle erstmal gesammelt und zusammengestellt.

Ab hier https://github.com/fhem/EPG/blob/168c74eecc9d216ea355f2ab6720ec1bd39f64c0/FHEM/66_EPG.pm#L1331 wird Struktur mit Daten gefüllt.

Gern Können wir auch Patches via Github einspielen.



Gesendet von iPhone mit Tapatalk Pro

[OdfFhem]

@HomeAuto_User

Mit Sicherheit nicht die beste Lösung, aber nur eine minimale Änderung:

Code Auswählen Erweitern


#1659
+++ my @mychannels = ();
    foreach my $ch (keys %{$data}) {

#1676
+++   push (@mychannels, $data->{$ch}); 
    }

#1683
--- $hash->{helper}{FTUI_data} = toJSON($hash->{helper}{FTUI_data});
+++ $hash->{helper}{FTUI_data} = toJSON(\@mychannels);

Variablennammen sind wie immer "frei erfunden" und beliebig ersetzbar.

[HomeAuto_User]

@OdfFhem

Ich habe den OptimierungsStandin einen weiteren Branch pre-release_FTUI_v2 geschoben.
Deine Änderungen sollten dort hoffentlich richtig integriert sein.

Code Auswählen Erweitern

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

Sobald wir die Anpassungen "fertig" haben, werde ich dies in den Branch pre-release schieben für alle.

[OdfFhem]

@HomeAuto_User

Ich habe den aktuellen Stand aktiviert und zunächst einmal sieht es gut aus.

Schön wäre noch, wenn wir bei nächster Gelegenheit die Eigenschaft Ch_Command in ch_command umbenennen würden. Die anderen ch_-Felder sind auch komplett in Kleinbuchstaben.

Code Auswählen Erweitern


{Ch_Command: "set ftuitest epg_resource ZDF", EPG: [], ch_id: "ZDF.de", ch_name: "ZDF", ch_wish: 2}


[HomeAuto_User]

@HomeAuto_User

Ich habe den aktuellen Stand aktiviert und zunächst einmal sieht es gut aus.

Schön wäre noch, wenn wir bei nächster Gelegenheit die Eigenschaft Ch_Command in ch_command umbenennen würden. Die anderen ch_-Felder sind auch komplett in Kleinbuchstaben.

Code Auswählen Erweitern


{Ch_Command: "set ftuitest epg_resource ZDF", EPG: [], ch_id: "ZDF.de", ch_name: "ZDF", ch_wish: 2}


@OdfFhem
mit dem Ergebnis bin ich auch zufrieden schon
Soeben habe ich die Anpassung des Namens vollzogen im JSON Output und zugleich noch fehlende Commandref Einträge vollzogen.

[OdfFhem]

@HomeAuto_User

Vielen Dank schon mal für die bislang gute Zusammenarbeit.


Was mir gerade noch aufgefallen ist:
- loadEPG_Prime bereitet zum jetzigen Zeitpunkt bereits die Sendungen für den morgigen Tag auf; in der HTML-Ansicht wird aber der heutige Tag angegeben ...

[HomeAuto_User]

@HomeAuto_User

Vielen Dank schon mal für die bislang gute Zusammenarbeit.

Das gebe ich gerne zurück. *daumen hoch*

Was mir gerade noch aufgefallen ist:
- loadEPG_Prime bereitet zum jetzigen Zeitpunkt bereits die Sendungen für den morgigen Tag auf; in der HTML-Ansicht wird aber der heutige Tag angegeben ...

Das es die Daten von morgen nimmt ist erstmals richtig, weil heute kein 20:15 mehr existent ist.
Hier habe ich soeben es nachvollziehen wollen und ich erhalte selbst in der HTML Ausgabe die Daten von morgen.

Was anderes, ich überlege soeben ob bei dem JSON die Angabe Start & End einer sendung so verarbeitungstechnisch gut ist. 

Code Auswählen Erweitern

"end":"20200117225000 +0100","start":"20200117201500
Leider kann ich das nicht einschätzen, da ich noch keine Erfahrung mit der weiteren Verarbeitung diesbezüglich sammeln konnte.

[OdfFhem]

@HomeAuto_User

Die Prime-Aufbereitung für morgen ist schon nachvollziehbar, aber die Anzeige in der Detailseite ist "falsch" (s. angehängten Screenshot).


Bzgl. Start-/Ende-Angaben hatte ich keine Probleme bei der Verarbeitung.

Gebräuchlicher sind aber z.B. Datums-/Zeit-String im einfachen ISO 8601 Format:

Code Auswählen Erweitern


"start":"2020-01-16T10:15:00", "end":"2020-01-16T10:45:00"


oder

in Kalendern verwendet man in der Regel folgende DATE-TIME-Darstellung:

Code Auswählen Erweitern


"start":"20200116T101500", "end":"20200116T104500"


[HomeAuto_User]

@HomeAuto_User

Die Prime-Aufbereitung für morgen ist schon nachvollziehbar, aber die Anzeige in der Detailseite ist "falsch" (s. angehängten Screenshot).

Bzgl. Start-/Ende-Angaben hatte ich keine Probleme bei der Verarbeitung.

Gebräuchlicher sind aber z.B. Datums-/Zeit-String im einfachen ISO 8601 Format:

Code Auswählen Erweitern


"start":"2020-01-16T10:15:00", "end":"2020-01-16T10:45:00"


oder

in Kalendern verwendet man in der Regel folgende DATE-TIME-Darstellung:

Code Auswählen Erweitern


"start":"20200116T101500", "end":"20200116T104500"


Alles klar, das mit der Datumsanzeige meinst du.
Ich werde es beleuchten und korrigieren.

Wenn wir uns die Frage stellen oder du, wäre es von Vorteil für einen "Leihen" wenn das Format des Datums angepasst wird wie

Code Auswählen Erweitern


"start":"2020-01-16T10:15:00", "end":"2020-01-16T10:45:00"

so würde ich aus dem Bauch heraus sagen ja.

[OdfFhem]

@HomeAuto_User

Entscheidung scheint gut; "Datums-/Zeit-String im einfachen ISO 8601 Format" wird nativ von JavaScript unterstützt.

Code Auswählen Erweitern


Date.parse("2020-01-16T10:15:00") liefert 1579166100000
Date.parse("20200116T101500") liefert NaN


[HomeAuto_User]

Bei der Umstellung des Zeitstempels bei start und end stoße ich auf ein Phänomen welches ich mir nicht erklären kann.

Wir haben mit

Code Auswählen Erweitern

my $data = $HTML;
die Daten dupliziert in der BlockingSub.

Dort möchte ich in $data modifizieren mit Bsp.

Code Auswählen Erweitern

$data->{$ch}{EPG}[$i]{start} = "0865-12";

Der Wert wird auch angenommen aber zusätzlich ebenso in der Variable $HTML was ich aber nicht möchte.
Kannst du dir das erklären bzw. was mache ich verkehrt? 

Die aktuelle Fassung ist im Branch zu Einsicht.

[OdfFhem]

@HomeAuto_User

Kannst du dir das erklären bzw. was mache ich verkehrt?

Beim Zuweisen eines HASHs erzeugst Du keine Kopie, sondern hast nur eine weitere Variable, die auf dieselben Daten zeigt.

Ich habe es jetzt nicht getestet, aber vermutlich kann man unter dieser "neuen" Erkenntnis die einmalige toJSON-Wandlung auf den return-Fall verschieben - das sollte je nach Umfang der EPG-Daten reichlich Arbeitsspeicher schonen ...


Start-/Ende-Formatierung

JavaScript unterstützt übrigens auch nativ das in FHEM gebräuchliche Timestamp-Format:

Code Auswählen Erweitern


Date.parse("2020-01-16 10:15:00") liefert 1579166100000
Date.parse("2020-01-16T10:15:00") liefert 1579166100000
Date.parse("20200116T101500") liefert NaN

Vermutlich wäre dieses damit ebenfalls ein sehr plausibles oder vielleicht sogar das beste Format für start und end.

Ich habe mal im Modul geschaut und festgestellt, dass {start} und {end} an überschaubar wenig Stellen genutzt wird. Desweiteren nutzt Du ja eigentlich auch sowieso schon überall FmtDateTime und "verfremdest" das Ergebnis dann meist im Anschluss. Daher wäre es vermutlich besser und wohl auch mit eher geringem Aufwand machbar, diese Elemente generell auf "unser" neues Format umzustellen.


Was hältst Du von diesem Plan?