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

[OdfFhem]

@HomeAuto_User

So, neuen Stand geladen und einige Tests gemacht. Grundsätzlich funktioniert die geplante Änderung, aber es gibt noch eine Reihe von Anmerkungen, insbesondere im Fav-Umfeld:

• 
  In der "list of all available channels" kann man ein Feld namens "FAV" pflegen und ich dachte kurzerhand, dass mit loadEPG_Fav die Sendungen der Sender zusammengestellt werden, die einen FAV-Eintrag haben. Dem ist aber nicht so - wusste ich ja eigentlich auch schon von einem vorherigen Beitrag. Eingetragen werden die in diesem Feld gepflegten Werte dann in einem Attribut namens Ch_select - hier erschließt sich kein Zusammenhang. Fraglich, ob man nicht als kleinste Änderung zumindest "FAV" in "select" ändert ...
  


• 
  Bzgl. der "list of ..." ergibt sich auch noch eine weitere Frage: Wieso wird der Inhalt von Ch_Commands nicht auch über oben genannte Liste gepflegt?
  Darüberhinaus müsste das Attribut konsequenterweise auch Ch_commands heissen ...
  


• 
  Laut Doku gibt es ein Attribut "FavoriteShows", das Namen von Sendungen enthält; gesucht wird dann aber nicht im Titel-Feld, sondern in vermutlich allen Feldern. Bei z.B. "Tatort" wundert man sich schnell über die große Auswahl an Tatort-Sendungen; man hat eigentlich auch keine Chance, nur an die "echten" Tatort-Sendungen zu kommen.
  Um dass ein wenig beeinflussen zu können, müsste man hier mehrere Attribute anbieten: z.B. FavTitle, FavDesc, FavAll und dann jeweils eine dazu passende Routine wie loadEPG_FavTitle, ...; momentan findet die Bildung des finalen Suchmusters im Modul statt - reine Tatort-Sendungen zu filtern ist nicht wirklich machbar. Alternativ wäre natürlich auch die Hinterlegung eines regulären Ausdrucks sinnvoll ... damit hat man schon deutlich mehr Kontrolle.
  
  Eine Umbennung macht aber auch ohne eine Aufsplittung Sinn, da sich der Zusammenhang zwischen dem Namen der get-Routine und dem Attribut nicht so richtig erschließt - der folgerichtige Name wäre dann loadEPG_FavoriteShows. loadEPG_Fav sucht wohl immer über alle Sender, nicht nur über die "vorausgewählten" Sender - bug oder feature?
  


• 
  Die meisten Werte zum Reading EPG_last_loaded stimmten; zwei kleine Änderungen würden das Bild noch abrunden.
  - Beim Modus today würde ich jetzt doch die 0000 weglassen (also statt 0000 ein leerer Eintrag). Hintergrund: 0000 hätte momentan zwei Bedeutungen; bei today meint man aktuelle Zeit; bei "loadEPG__20200121_0000" aber tatsächlich 00:00. Keine Zeit ist dann innovativer für aktuelle Zeit.
  - Beim Modus Fav fehlt ein Unterstrich - also" loadEPG_Fav__" statt "loadEPG_Fav_".
  - Zusätzlich würde ich noch eine Änderung bzgl. loadEPG empfehlen, da loadEPG im Gegensatz zu den anderen Routinen keine Rückschlüsse auf den Sinn der Routine zuläßt. Gedacht hatte ich an z.B. "loadEPG_time" statt "loadEPG".
  


• 
  jsonEPG liefert nicht immer die zuletzt aufbereiteten Daten ?!? Und zwar immer im Zusammenhang mit loadEPG_Fav. Wenn dem so sein soll, dürfte diese Aktion das Reading nicht beeinflussen. Fraglich ist aber, ob das wirklich so gewollt ist. Denn eine Umschaltung auf eine andere Sicht führt sowieso zu einer Neuaufbereitung. In dem Zusammenhang noch zu erwähnen: Im Room EPG kann ich zwar z.B. den Button Prime drücken und die passenden Daten werden aufbereitet; angezeigt wird dies aber nicht automatisch - also Refresh notwendig ...
  
  Irgendwie scheint das Modul doch die richtigen Daten bereitzustellen, aber das Verhalten ist leicht verwirrend ... vielleicht mal selber mit "Tatort" eingrenzen und testen.
  


• 
  Hinweis zur Doku: "läd" müsste eigentlich "lädt" heissen ... vielleicht aber auch veraltetes Rechtschreibwissen ...
  

[HomeAuto_User]

@OdfFhem
das ist natürlich erstmal wieder viel Stoff 
Als Anfang habe ich mal das Durchgestrichene schon mal erledigt *grins*

Hinweis zur Doku: "läd" müsste eigentlich "lädt" heissen ... vielleicht aber auch veraltetes Rechtschreibwissen ...

Bei den anderen Punkten muss ich erstmal schauen wie diese zusammenfließen. Gern beginne ich ja mit dem kleinsten Problem *grins*.

So, neuen Stand geladen und einige Tests gemacht. Grundsätzlich funktioniert die geplante Änderung, aber es gibt noch eine Reihe von Anmerkungen, insbesondere im Fav-Umfeld:

• 
  In der "list of all available channels" kann man ein Feld namens "FAV" pflegen und ich dachte kurzerhand, dass mit loadEPG_Fav die Sendungen der Sender zusammengestellt werden, die einen FAV-Eintrag haben. Dem ist aber nicht so - wusste ich ja eigentlich auch schon von einem vorherigen Beitrag. Eingetragen werden die in diesem Feld gepflegten Werte dann in einem Attribut namens Ch_select - hier erschließt sich kein Zusammenhang. Fraglich, ob man nicht als kleinste Änderung zumindest "FAV" in "select" ändert ...
  

Ja die Benennung kann gern anders erfolgen. Ob dort select das richtige ist? Es ist ja der gewünschte Senderkanal in der Sortierung.

• 
  Bzgl. der "list of ..." ergibt sich auch noch eine weitere Frage: Wieso wird der Inhalt von Ch_Commands nicht auch über oben genannte Liste gepflegt?
  Darüberhinaus müsste das Attribut konsequenterweise auch Ch_commands heissen ...
  

Ja, das wäre möglich in dem Fenster dies zu pflegen. Anfang ist es aber in der Umsetzung sehr schwierig weil ich es auch "lokal" speichern muss in einem Attribut und dann dort im Sreen wieder auseinander nehmen muss.
Der Name des Attributes heißt doch Ch_Commands.

• 
  Laut Doku gibt es ein Attribut "FavoriteShows", das Namen von Sendungen enthält; gesucht wird dann aber nicht im Titel-Feld, sondern in vermutlich allen Feldern. Bei z.B. "Tatort" wundert man sich schnell über die große Auswahl an Tatort-Sendungen; man hat eigentlich auch keine Chance, nur an die "echten" Tatort-Sendungen zu kommen.
  Um dass ein wenig beeinflussen zu können, müsste man hier mehrere Attribute anbieten: z.B. FavTitle, FavDesc, FavAll und dann jeweils eine dazu passende Routine wie loadEPG_FavTitle, ...; momentan findet die Bildung des finalen Suchmusters im Modul statt - reine Tatort-Sendungen zu filtern ist nicht wirklich machbar. Alternativ wäre natürlich auch die Hinterlegung eines regulären Ausdrucks sinnvoll ... damit hat man schon deutlich mehr Kontrolle.
  
  Eine Umbennung macht aber auch ohne eine Aufsplittung Sinn, da sich der Zusammenhang zwischen dem Namen der get-Routine und dem Attribut nicht so richtig erschließt - der folgerichtige Name wäre dann loadEPG_FavoriteShows. loadEPG_Fav sucht wohl immer über alle Sender, nicht nur über die "vorausgewählten" Sender - bug oder feature?
  

Die Umbenennung des Get Befehles ist kein Problem. Das ein besserer Bezug entsteht sehe ich ein.
Das Derzeit in Titeln und Beschreibung nach dem Wert gesucht wird ist auch richtig. Mit einem Aufschlitten in 2 getrennte Befehle ist es natürlich besser um auch nur Titel oder Beschreibung zu durchforsten. Ob man da ein Attribut nutzen möchte, ist fraglich. So kann man bsp. für Sohn oder Frau die Wünsche vordefinieren. Alternativ ginge dies auch mit einem Übergabeparameter.

• 
  Die meisten Werte zum Reading EPG_last_loaded stimmten; zwei kleine Änderungen würden das Bild noch abrunden.
  - Beim Modus today würde ich jetzt doch die 0000 weglassen (also statt 0000 ein leerer Eintrag). Hintergrund: 0000 hätte momentan zwei Bedeutungen; bei today meint man aktuelle Zeit; bei "loadEPG__20200121_0000" aber tatsächlich 00:00. Keine Zeit ist dann innovativer für aktuelle Zeit.
  - Beim Modus Fav fehlt ein Unterstrich - also" loadEPG_Fav__" statt "loadEPG_Fav_".
  - Zusätzlich würde ich noch eine Änderung bzgl. loadEPG empfehlen, da loadEPG im Gegensatz zu den anderen Routinen keine Rückschlüsse auf den Sinn der Routine zuläßt. Gedacht hatte ich an z.B. "loadEPG_time" statt "loadEPG".
  

Das sollte umsetzbar sein und ich würde es so nach deiner Darlegung umsetzen wollen.

• 
  jsonEPG liefert nicht immer die zuletzt aufbereiteten Daten ?!? Und zwar immer im Zusammenhang mit loadEPG_Fav. Wenn dem so sein soll, dürfte diese Aktion das Reading nicht beeinflussen. Fraglich ist aber, ob das wirklich so gewollt ist. Denn eine Umschaltung auf eine andere Sicht führt sowieso zu einer Neuaufbereitung. In dem Zusammenhang noch zu erwähnen: Im Room EPG kann ich zwar z.B. den Button Prime drücken und die passenden Daten werden aufbereitet; angezeigt wird dies aber nicht automatisch - also Refresh notwendig ...
  
  Irgendwie scheint das Modul doch die richtigen Daten bereitzustellen, aber das Verhalten ist leicht verwirrend ... vielleicht mal selber mit "Tatort" eingrenzen und testen.
  

Das kann ich nur nach und nach durchtesten nochmal wie das Verhalten ist. Das Suchverhalen stimmt vermutlich auch nicht. Ich ahbe soeben beim Test hier "nicht gewollte" Werte gesehen.
[/list]

Ich denke, das kann man nur erstmal priorisieren und dann Stück für Stück die Häppchen "vernaschen" von deiner Testliste.

[OdfFhem]

@HomeAuto_User

Da sollte ja kein Zeitdruck aufkommen, denn ab Donnerstag bin ich zumindest erstmal aus dem Verkehr gezogen ...


Noch kurz zu Deinen "Rückfragen":

- Die gepflegten Werte werden natürlich in Ch_sort übernommen, also wäre "sort" das passendere Label im Dialog.

- Ch_Commands ist nicht gleich Ch_commands ; es geht hier rein um die Namenstheorie: Ch_sort, Ch_select - also warum nicht auch Ch_commands?

[HomeAuto_User]

@OdfFhem

@HomeAuto_User

Da sollte ja kein Zeitdruck aufkommen, denn ab Donnerstag bin ich zumindest erstmal aus dem Verkehr gezogen ...

Noch kurz zu Deinen "Rückfragen":

- Die gepflegten Werte werden natürlich in Ch_sort übernommen, also wäre "sort" das passendere Label im Dialog.
- Ch_Commands ist nicht gleich Ch_commands ; es geht hier rein um die Namenstheorie: Ch_sort, Ch_select - also warum nicht auch Ch_commands?

Alles gut  

Ich werde als erstes nun den kleinsten Punkt

Code Auswählen Erweitern

- Ch_Commands ist nicht gleich Ch_commands ; es geht hier rein um die Namenstheorie: Ch_sort, Ch_select - also warum nicht auch Ch_commands?
anpassen weil das die Struktur steht.

Verstehe ich das richtig,

Code Auswählen Erweitern

- Die gepflegten Werte werden natürlich in Ch_sort übernommen, also wäre "sort" das passendere Label im Dialog.
das wir das Attribut eher auch umbenennen sollten?

Zusätzlich fiel mir auch noch was auf
Sobald ich bei Ch_Commands Devices eintrage und diese zur Steuerung nutze, so fehlt die Anpassung bei "Probably associated with".

[OdfFhem]

@HomeAuto_User

Bzgl. sort: Das Attribut würde ich nicht umbenennen; lediglich die Überschrift im "list of all available channels"-Dialog - also stat "FAV" einfach "sort".

Sobald ich bei Ch_Commands Devices eintrage und diese zur Steuerung nutze, so fehlt die Anpassung bei "Probably associated with".

Was genau heisst das? Bei mir steht immer nur das FileLog-Device in Beziehung zum EPG-Device.

[HomeAuto_User]

@HomeAuto_User

Bzgl. sort: Das Attribut würde ich nicht umbenennen; lediglich die Überschrift im "list of all available channels"-Dialog - also stat "FAV" einfach "sort".
Was genau heisst das? Bei mir steht immer nur das FileLog-Device in Beziehung zum EPG-Device.

Das heißt, wenn du ein Device Bsp: Stubenlicht verwendest bei ARD -> set Stubenlicht on verwendest, so sollte das Device auftauchen in der Liste da unten.

Grund, das Modul ist praktisch ,,verknüpft" mit dem Device. Schau mal in einem DOIF oder AT. Da ist dort unten immer das verknüpfte Device drin.


Gesendet von iPhone mit Tapatalk Pro

[OdfFhem]

@HomeAuto_User

Laut Wiki gilt wohl folgende Theorie und dann ist alles klar:

Diese Liste zeigt Gerätenamen an, die wahrscheinlich mit dem Gerät verbunden sind. Es werden alle Geräte angezeigt, die im Internal DEF erkennbar sind.

Es gibt aber auch ein paar Module, die das Verbundensein-Management selbst übersteuern ...

[HomeAuto_User]

@OdfFhem
das ist die helbe Wahrheit die dort steht 

@HomeAuto_User

Laut Wiki gilt wohl folgende Theorie und dann ist alles klar:
Es gibt aber auch ein paar Module, die das Verbundensein-Management selbst übersteuern ...

Hier ist die volle Wahrheit aus der fhem.pl

Code Auswählen Erweitern

    if(($dh->{DEF} && $dh->{DEF} =~ m/\b$d\b/) ||
       (ReadingsVal($dn, ".associatedWith", "") =~ m/\b$d\b/) ||
       ($h->{DEF}  && $h->{DEF}  =~ m/\b$dn\b/) ||
       $daw =~ m/\b$dn\b/) {
      push(@dob, $dn);
    }

Demzufolge DEF und das versteckte Reading. 

[OdfFhem]

@HomeAuto_User

Genau, das hatte ich auch gesehen und es gibt halt Module, die dieses Reading selbst verwalten, da DEF für den Automatismus nichts hergibt.

So wie ich das sehe, wird EPG bald zu diesen Modulen gehören ...

[HomeAuto_User]

Die Verknüpfung für den User finde ich gut und in einem anderen Faden von meinem Timer Modul wurde ich darauf aufmerksam gemacht worden.

Ich habe begonnen die Sache mit dem FavEinträgen zu trennen. Mal schauen wie ich da vorankomme nach und nach.


Gesendet von iPhone mit Tapatalk Pro

[HomeAuto_User]

Hallo @all,

wer möchte kann jederzeit die Entwicklung des Umbaus und der Erweiterungen via

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

verfolgen.

- u.a. Eine erweiterte Suche von FavTitle & FavDesc ist möglich
- nach reload sind die Daten nicht gelöscht ...
- Anpassung Attribnamen & Strukturnamen

Mit freundlichen Grüßen


Gesendet von iPhone mit Tapatalk Pro

[matrois]

Hallo zusammen,
ich versuche seit einiger Zeit das Modul tvinfo ans Laufen zu bekommen. Meine Definition sieht so aus:

Code Auswählen Erweitern


define tvinfo EPG
attr tvinfo Ch_select Das Erste HD DE,ZDF DE
attr tvinfo DownloadFile DE_guide.xml
attr tvinfo DownloadURL http://epgportal.us.to/epg/
attr tvinfo Variant WebGrab+Plus


"get tvinfo available_channels" funktioniert und ich habe danach eine Liste mit ca. 209 Sendern zur Auswahl. Zum Testen habe ich mich auf zwei Programme beschränkt. "get tvinfo loadFile" schließt mit STATE=Daten empfangen ab. Ein "get tvinfo loadEPG_now" endet jedoch in state=keine EPG Daten verfügbar.

Im Log finde ich Zeitumrechnungen:

Code Auswählen Erweitern


2020.01.26 10:09:43 5: tvinfo: nonBlock_loadEPG_v1 | Time must be recalculated! local=+0100 read=+0000
2020.01.26 10:09:43 5: tvinfo: nonBlock_loadEPG_v1 | hour_diff_result +1
2020.01.26 10:09:43 5: tvinfo: nonBlock_loadEPG_v1 | sec | min | hour | mday | month | year
2020.01.26 10:09:43 5: tvinfo: nonBlock_loadEPG_v1 | 00  | 00  |  19  | 28   | 04    | 2019
2020.01.26 10:09:43 5: tvinfo: nonBlock_loadEPG_v1 | 00  | 50  |  19  | 28   | 04    | 2019
2020.01.26 10:09:43 5: tvinfo: nonBlock_loadEPG_v1 | UTC start        -> 1556470800
2020.01.26 10:09:43 5: tvinfo: nonBlock_loadEPG_v1 | UTC end          -> 1556473800
2020.01.26 10:09:43 5: tvinfo: nonBlock_loadEPG_v1 | start            -> 20190428190000 +0000
2020.01.26 10:09:43 5: tvinfo: nonBlock_loadEPG_v1 | end              -> 20190428195000 +0000[code]


und dies

Code Auswählen Erweitern


2020.01.26 10:10:01 5: tvinfo: nonBlock_loadEPG_v1 value JSON for delivery:
2020.01.26 10:10:01 5: Cmd: >{BlockingStart('6')}<
2020.01.26 10:10:01 5: Cmd: >{EPG_nonBlock_loadEPG_v1Done('tvinfo|DE_guide.xml|keine EPG Daten verfügbar|loadEPG_now|')}<
2020.01.26 10:10:01 4: tvinfo: nonBlock_loadEPG_v1Done running, loadEPG_now from file DE_guide.xml
2020.01.26 10:10:01 5: tvinfo: nonBlock_loadEPG_v1Done string=tvinfo|DE_guide.xml|keine EPG Daten verfügbar|loadEPG_now|
2020.01.26 10:10:01 4: tvinfo: nonBlock_loadEPG_v1Done found 0 broadcast information
2020.01.26 10:10:01 4: WEB_192.168.0.101_50812 GET /fhem?detail=tvinfo; BUFLEN:0
2020.01.26 10:10:01 4: tvinfo: FW_Detail is running (Tableview=on, language=DE)
2020.01.26 10:10:01 5: tvinfo: FW_Detail - channel_available: 209
2020.01.26 10:10:01 5: tvinfo: FW_Detail - channel_select: 207
2020.01.26 10:10:01 4: WEB: /fhem?detail=tvinfo / RL:7185 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate


Nach einem Update ist der zusätzliche Befehl "get tvinfo jsonEPG" aufgetaucht. Dieser liefert [].

Danke für jeden Tipp.

[JensS]

@HomeAuto_User

Das Modul läuft schon eine Weile sehr gut - natürlich. Nun habe ich mal wieder nach dem aktuellen Stand geschaut und die Update-Quelle angepasst. Etwas erstaunt war ich über die Änderung von Ch_Commands in Ch_commands. Aber das war rückzuck korrigiert.
Siehst du eine Möglichkeit, dass sich die Seite nach einem Klick auf "derzeit" oder "PrimeTime" neu aufbaut - sowas wie longpoll?

Gruß Jens

[HomeAuto_User]

@matrois
Danke für die Nutzung.
Ich werde mit deinem List morgen lokal deinen Fall nachspielen und schauen wo es ggf. hängt.

@JensS
Danke ebenso an dich für das Testen.
Das anpassen des Attributnamens erfolgte, das die Namensstruktur einheitlich ist. Deswegen sind wir ja noch im TestBranch.

Eine automatische Aktualisierung kannst du derzeit schon aktivieren. Setzte das Attribut EPG_autoupdate bzw. EPG_autodownload. In der Commandref habe ich dies drin. (Hoffentlich auch verständlich)

Gern helfe ich Euch und nehme Kritik, Anregungen oder Vorschläge auf


Gesendet von iPhone mit Tapatalk Pro

[JensS]

@HomeAuto_User

Klar ist es ein TestBranch. Ein Changelog im ersten Beitrag könnte hilfreich sein, Änderungen zu vermitteln.

Zum Thema Aktualisierung haben wir uns missverstanden.  Autoupdate und Autoload mache ich schon lange per at.
Es geht darum, dass sich die Seite neu aufbaut, wenn man auf eine andere Sendezeit klickt.

Gruß Jens