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

[HomeAuto_User]

@OdfFhem

=== neues Reading ===

Aus diesem Grund macht es Sinn, ein Reading einzuführen, das anzeigt, dass eine loadEPG-Routine erfolgreich abgeschlossen wurde. Wird ein solches Reading aktualisiert, löst es ein Ereignis aus und so werden alle "Lauscher" benachrichtigt, dass es neue EPG-Daten gibt. Das Reading state wird zwar auch im Rahmen der Aufbereitung fleißig aktualisiert, aber signalisiert alle möglichen Zustände und ist daher nicht sinnvoll verwendbar. Ein Name für dieses neue Reading könnte in Anlehnung an die anderen Readings z.B. EPG_last_loaded heissen oder aber auch ganz anders ...

Es wird nun erstellst mit dem Wert vom letzten Kommando und den Zeitstempel hat man ja da hinter.
In Ordnung so?

=== jsonEPG ===
{"error":"no data exists"}

Diese Ausgabe erfolgt nun, sobald keine Daten vorhanden sind.

[OdfFhem]

@HomeAuto_User

Hört sich gut an; kann aber frühestens am späteren Abend oder eher morgen testen ...

[OdfFhem]

@HomeAuto_User

Nun habe ich es endlich geschafft, den neuen Modulstand zu aktivieren und die neuen Features zu testen ... scheinen zu funktionieren 


Schon mal schön. (Vielleicht) unabhängig vom neuen Modulstand habe ich noch folgende Auffälligkeiten festgestellt ...

=== 1 ===

Code Auswählen Erweitern


--- Ich klicke mich in den EPG-Raum

Logeintrag --- 2020-01-19_10:49:55 myEPG Data is being updated automatically

--> es gab wohl keine aktuell verwendbaren Daten mehr

Logeintrag --- 2020-01-19_10:50:03 myEPG HttpResponse: downloaded
Logeintrag --- 2020-01-19_10:50:03 myEPG data received

--> Aktion fürs Reinklicken in den Raum ist jetzt beendet, keine weiteren Logeinträge


Unabhängig von unserer noch geplanten Aktualisierungsvariante hätte ich an dieser Stelle erwartet, dass nach dem Herunterladen einer neuen Datei autom. neue EPG-Daten geladen werden. Hätten noch aktuell verwendbare Daten vorgelegen, wäre ja auch genau das passiert.

=== 2 ===

Ein reload des Moduls sorgt stets dafür, dass die aktuelle Ansicht des EPG-Gerätes "zerstört" wird:

Code Auswählen Erweitern


--- Ich mache also einen reload

--- ich mache einen reload auf der Detailseite, da der alte Stand nicht autom. aktualisiert wird
--> get stellt nun nur noch "available_channels / jsonEPG / loadFile" breit

--> auf der Detailseite fehlt neuerdings der Hinweis, dass keine aufbereiteten EPG-Daten vorliegen

--> es ist jetzt ein "get <device> available_channels" notwendig
--> anschließend werden autom. die neu geladenen Daten dargestellt


In diesem Zusammenhang macht es wahrscheinlich Sinn, dass man state noch ein wenig informativer macht. Dort könnten so Zustände wie
- initialized
- no data available
- ...

[Prof. Dr. Peter Henning]

OK, bin zurück von meinem Auslandsaufenthalt und kann wieder mitreden.

Zum Thema Anzeige in FTUI  - wie würde ein Widget aussehen, das ergonomisch gestaltet ist und alle nötigen Informationen in kompakter Form übermittelt? Wwas wäre anzuzeigen, wie wäre es zu bedienen? Wie verhindert man übermäßigen Traffic?

- Rechteck (Canvas? Iframe?) mit einstellbarer Größe, default 600x400 Pixel
- Darin am oberen Rand eine Zeitskala, beginnend bei der vollen halben/viertel Stunde VOR gegenwärtiger Zeit oder vor einer festen Zeitangabe (z.B. Primetime, oder 23:00)
- Zeitskala nach recht fortgeführt mit einstellbarem Skalenfaktor. Scrollbar ?
- Für die gegenwärtige Zeit oder die feste Zeitangabe ein auffälliger senkrechter Strich über das gesamte Rechteck.
- Unterhalb der Zeitskala 5 bis X Zeilen (einstellbar, als "Zeilenfenster" scrollbar über alle ausgewählten Kanäle)
- Innerhalb jeder Zeile links fest angezeigt der Kanalname. Rechts davon (scrollbar mit der Zeitleiste) ein Rechteck für jede Sendung - eventuell mit abgekürztem Titel drinstehend. Die Aneinanderreihung dieser Rechtecke ergibt dann eine Zeitleiste für diesen Kanal. Beim Anfahren mit der Maus (und erst dann...) werden weiter eDaten angefordert und in einem Popup dargestellt.

Das schreit geradezu nach SVG.

LG

pah

[OdfFhem]

@HomeAuto_User

Initiiert durch das Testen mit z.B. "get <device> loadEPG 20200119_1500" scheint es noch folgende Probleme zu geben:

1) Das Reading EPG_last_loaded hat den Wert loadEPG - erst einmal korrekt; besser wäre aber, wenn man noch den Startzeitpunkt mitliefern würde. Hat den Hintergrund, dass man dann auch an die richtige Stelle auf der Zeitskala springen kann (bei nur loadEPG --> abhängig vom gewählten Zeitpunkt ; bei Prime --> 20:15 ; ansonsten --> Jetzt).

2) Ich würde mich bei Prime auch immer auf den aktuellen Tag beschränken und nicht, weil 20:15 vorbei ist, stattdessen den nächsten Tag aufbereiten. Bei loadEPG selbst kann man ja auch nur die verbleibenden Stunden des Tages aufbereiten - dann hätte man eine konsequente Vorgehensweise. Will man einen anderen Tag aufbereiten, dann sollte ein zusätzlicher Parameter für den Tag übergeben werden müssen ...


Mit den aktuellen Überlegungen im Hinterkopf wäre es sicherlich gut, wenn man den Startzeitpunkt im Wert abbilden würde (beispielhaft für heutige Aufbereitung):
- "get <device> loadEPG_now" führt zu loadEPG_now_20200119_HHMM; HHMM entspricht aktueller Aufbereitungszeit
- "get <device> loadEPG_Prime" führt zu loadEPG_Prime_20200119_2015
- "get <device> loadEPG_today" führt zu loadEPG_today_20200119_0000
- "get <device> loadEPG 20200119_1500" führt zu loadEPG_today_20200119_1500

[HomeAuto_User]

Hallo, das ist erstmal viel Input gewesen was ich gleich nochmal lesen muss.

Als erstes würde ich dann die Kleinigkeiten mit dem Reading erstmal angehen und dann step bei step die anderen Sachen.


Gesendet von iPhone mit Tapatalk Pro

[OdfFhem]

@pah

=== Analyse bezogen auf die Screenshots aus #225 ===

- Rechteck (Canvas? Iframe?) mit einstellbarer Größe, default 600x400 Pixel

Größe wird in der Regel rein vom zur Verfügung gestellten Platzangebot bestimmt ... eine sinnvolle Mindestgröße sollte nicht unterschritten werden

- Darin am oberen Rand eine Zeitskala, beginnend bei der vollen halben/viertel Stunde VOR gegenwärtiger Zeit oder vor einer festen Zeitangabe (z.B. Primetime, oder 23:00)
- Zeitskala nach recht fortgeführt mit einstellbarem Skalenfaktor. Scrollbar ?
- Für die gegenwärtige Zeit oder die feste Zeitangabe ein auffälliger senkrechter Strich über das gesamte Rechteck.

Zeitskale wird am oberen Rand dargestellt ; Raster quasi frei skalierbar (im Screenshot 5 Minuten) ; Zeitskala kann via Scrollbar nach links oder rechts verschoben werden ; frei auswahlbäre Sprungmarken für häufig genutzte Zeitpunkte aktivierbar (z.B. 18:00 ; Prime ; Jetzt) ; aktueller Zeitpunkt wird optisch hervorgehoben

- Unterhalb der Zeitskala 5 bis X Zeilen (einstellbar, als "Zeilenfenster" scrollbar über alle ausgewählten Kanäle)

Am linken Rand einer Zeile wird der TV-Sender dargestellt ; Sortierung der TV-Sender gemäß EPG-Device-Einstellung ; Click auf TV-Sender führt Aktion gemäß EPG-Device-Einstellung aus ; Anzahl der dargestellten Zeilen hängt vom bereitgestellten Platzangebot ab ; die restlichen Zeilen können via Scrollbar erreicht werden

- Innerhalb jeder Zeile links fest angezeigt der Kanalname. Rechts davon (scrollbar mit der Zeitleiste) ein Rechteck für jede Sendung - eventuell mit abgekürztem Titel drinstehend. Die Aneinanderreihung dieser Rechtecke ergibt dann eine Zeitleiste für diesen Kanal. Beim Anfahren mit der Maus (und erst dann...) werden weiter eDaten angefordert und in einem Popup dargestellt.

Im eigentlichen Datenbereich werden je Kanal die vom EPG-Device bereitgestellten Sendungen präsentiert ; ausgerichtet an der Zeitskala gemäß Start- und Endezeit ; Rechteck enthält Startzeit, Tooltip-Anker sowie Titel ; exemplarisch wurden Magazine gesondert eingefärbt, aber wegen fehlender Kategorien wäre so etwas momentan wohl nicht "gesichert" umsetzbar

Daten (TV-Sender / Sendungen) werden in der Regel einmalig geholt - sofern man die Seite nicht verlässt ; Neuaufbereitungen im EPG-Device werden via Reading signalisiert und lösen damit ein neuerliches Abholen der Daten aus ; Gründe für eine Neuaufbereitung können Pflege der ch_*-Attribute, Download einer neuen EPG-Datei oder ... sein

Exemplarisch wurde auch das Laden verschiedener EPG-Devices angetestet, da beim Interesse an unterschiedlichen Ländern schnell mehr EPG-Devices notwendig sein können; Der Überblick wird aber sicherlich einfacher, wenn man alle interessanten TV-Sender in einer Übersicht darstellt. Die frei vergebbaren  und nicht zwanghaft fortlaufenden Favoritenkennungen scheinen auch eine EPG-Device-übergreifende Sortierung möglich zu machen.

Das schreit geradezu nach SVG.

An SVG hätte ich bei den Anforderungen ehrlich gesagt am wenigsten gedacht, aber ich bin gespannt ...

[HomeAuto_User]

@OdfFhem

=== 2 ===

Ein reload des Moduls sorgt stets dafür, dass die aktuelle Ansicht des EPG-Gerätes "zerstört" wird:

Code Auswählen Erweitern


--- Ich mache also einen reload

--- ich mache einen reload auf der Detailseite, da der alte Stand nicht autom. aktualisiert wird
--> get stellt nun nur noch "available_channels / jsonEPG / loadFile" breit

--> auf der Detailseite fehlt neuerdings der Hinweis, dass keine aufbereiteten EPG-Daten vorliegen

--> es ist jetzt ein "get <device> available_channels" notwendig
--> anschließend werden autom. die neu geladenen Daten dargestellt


In diesem Zusammenhang macht es wahrscheinlich Sinn, dass man state noch ein wenig informativer macht. Dort könnten so Zustände wie
- initialized
- no data available
- ...

Hallo, dem würde ich mich mal widmen.
Jetzt muss ich erstmal schauen wie dies zu Stande kommt. Es wird beim Reload eine Variable geleert und daher kommt dies.

Der Grund ist, da ich die Globale Variable am Anfang des Modules setze. Bei einem Reload leere ich diese somit und daher ist der Screen dann leer und muss aufgebaut werden.
Im State wird der alte Zustand vom vor dem Relaod angezeigt.

Code Auswählen Erweitern

if (scalar(@channel_available) > 0) {
wird nicht erfüllt und somitd gebe ich eine leere Seite zurück.

Wenn ich da nicht falsch denke, so müsste der Inhalt "geschwenkt werden" auf einen festen Punkt wie Helper?

[Prof. Dr. Peter Henning]

Äh - schlagt mich, aber ich dachte, die PNGs seien bisher nur handgefertigte Mockups.

Jetzt liest es sich so, as ob es schon ein Widget gäbe. Wenn ja, wo? Dann würde ich mir natürlich die Arbeit sparen, die ich gerade angefangen habe.

Ich hatte vor, die Logik dafür in eine subroutine EPG_widget des Moduls zu integrieren - und dieses auch aus dem normalen FHEM ohne FTUI heraus aufrufbar zu machen. So, wie das im Modul Astro.pm und im Modul YAAHM.pm gemacht wurde, d.h. in EPG_Initialize die Zeilen

Code Auswählen Erweitern


  $data{FWEXT}{"/EPG_widget"}{FUNC} = "EPG_widget";
  $data{FWEXT}{"/EPG_widget"}{FORKABLE} = 0;

einzubauen.

LG

pah

[OdfFhem]

@HomeAuto_User

Auf den ersten Blick würde ich Dir zustimmen, dass channel_available wie z.B. {FTUI_Data} "dauerhaft" gemacht werden müsste; dann sollte das Modul nach dem reload eine bereits bekannte Umgebung vorfinden ... wenn wir nicht noch was anderes übersehen haben ...

[OdfFhem]

@pah

Äh - schlagt mich, aber ich dachte, die PNGs seien bisher nur handgefertigte Mockups.

Gewalt ist doch keine Lösung ...

Jetzt liest es sich so, as ob es schon ein Widget gäbe. Wenn ja, wo? Dann würde ich mir natürlich die Arbeit sparen, die ich gerade angefangen habe.

Es gibt eine gute Nachricht: das Test-Widget existiert tatsächlich - wie schon in #185 angedroht. Aber wie so oft im Leben, gibt es auch eine schlechte Nachricht: das Test-Widget ist nicht für FTUI, sondern für FTUI3.

Ich hatte vor, die Logik dafür in eine subroutine EPG_widget des Moduls zu integrieren - und dieses auch aus dem normalen FHEM ohne FTUI heraus aufrufbar zu machen. So, wie das im Modul Astro.pm und im Modul YAAHM.pm gemacht wurde ...

Ich hatte mir die Moonwidget-Routine mal kurz angeschaut und es sieht interessant aus. Wenn man eine praktikable Lösung mit den angedachten Features für reine FHEM-Anwender umsetzen könnte, wäre das doch sicherlich zu begrüßen - ganz unabhängig davon, ob es auch eine reine FTUI-Lösung geben würde.

[HomeAuto_User]

@HomeAuto_User

Auf den ersten Blick würde ich Dir zustimmen, dass channel_available wie z.B. {FTUI_Data} "dauerhaft" gemacht werden müsste; dann sollte das Modul nach dem reload eine bereits bekannte Umgebung vorfinden ... wenn wir nicht noch was anderes übersehen haben ...

Ich habe begonnen es umzuschreiben.
Vorab habe ich den Stand in Pre-Release geschoben und der jetzige Stand wird im Branch pre-release-expanded Step bei Step durchgeführt.

Mir fiel auf, die Variable channel_available allein ist es nicht. Ich habe noch die ,,HTML Variable" welche geleert wird. Diese fasse ich nun an um den Datenbestand nach einem Reload aufrecht zu belassen. Wenn das abgeschlossen ist, können wir das Auto reload angehen.


Gesendet von iPhone mit Tapatalk Pro

[OdfFhem]

@HomeAuto_User

Schön, dass es weitergeht Eigentlich würde ich die Entwicklung auch gerne weiterhin begleiten, aber spätestens ab Donnerstag falle ich mindestens 2 Wochen aus. Somit hoffe ich, dass sich noch mindestens ein anderer Testwilliger findet ...

[HomeAuto_User]

@HomeAuto_User

Schön, dass es weitergeht Eigentlich würde ich die Entwicklung auch gerne weiterhin begleiten, aber spätestens ab Donnerstag falle ich mindestens 2 Wochen aus. Somit hoffe ich, dass sich noch mindestens ein anderer Testwilliger findet ...

Selbst 2 Wochen sind schnell vorrüber und ,,was lange währt, wird gut" [emoji6]


Gesendet von iPhone mit Tapatalk Pro

[OdfFhem]

Hoffentlich