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

[HomeAuto_User]

Hallo OdfFhem,

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

Sowas hatte ich vermutet und habe auch beim nachlesen den Verweis erhalten. Da lag ich falsch. Muss ich nur mal weiter lesen um mich dort zu bilden wie ich dann 2 voneinander Unabhängige hätte.

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?

Gern können wir den Plan umsetzen.

Ich schaue soeben mal drüber wo ich das am besten sofort umstelle.
1) entweder bevor ich es in die DAten schreibe oder
2) der aufwändigere Fall, wenn ich es ausgelesen habe, sofort zu wandeln und dann verarbeiten an allen Stellen.

[OdfFhem]

@HomeAuto_User

zum Thema HASH: ich würde den Datenbestand nicht verdoppeln; das Array mit den Verweisen auf die Daten sollte vollkommen ausreichen. Den toJSON-Aufruf kann man vermutlich zum get verlagern statt ihn unmittelbar nach dem Array-Bau auszuführen und dadurch dauerhaft unnötig Speicher zu belegen.

[HomeAuto_User]

Zur Zeit bin ich einfach zu .... eine Funktion mit einem Rückgabewert hinzubekommen....  ... das ist doch nocht das erste mal da ich das nutze
Angeblich zu wenig oder zu viele Argumente obwohl ich diese ($) definiere.

Code Auswählen Erweitern

Too many arguments for main::EPG_StartEnd_toISO at ./FHEM/66_EPG.pm line 1520, near "$start)"

Aufruf

Code Auswählen Erweitern

$start = EPG_StartEnd_toISO($start);

Code Auswählen Erweitern

sub EPG_StartEnd_toISO($) {
return xyz;
}

@HomeAuto_User

zum Thema HASH: ich würde den Datenbestand nicht verdoppeln; das Array mit den Verweisen auf die Daten sollte vollkommen ausreichen. Den toJSON-Aufruf kann man vermutlich zum get verlagern statt ihn unmittelbar nach dem Array-Bau auszuführen und dadurch dauerhaft unnötig Speicher zu belegen.

Sprichst du von den Daten für das JSON?
Wäre es aber nicht günstig diesen zu befüllen wenn ich den normalen get_xyz aufrufe?

Bitte nicht flasch denken, die aufbereitung der Daten erfolgt einmal und keine 3 Varianten wie now, Prime unsw.

[OdfFhem]

@HomeAuto_User

Argument-Thema: Kannst Du mal Dein Modul bereitstellen?

HASH-Thema: Meine Idee war, das Array weiterhin an der bekannten Stelle aufzubauen und in {FTUI_Data} abzulegen. Die toJSON-Wandlung aus #1682 würde ich eigentlich eher in #360 sehen. Wenn das klappt, belegt keine 2.Variable Speicherplatz und enthält Daten, die bis zum get-Aufruf niemand braucht.

[HomeAuto_User]

Werde ich sofort machen, ich schaue gerade wegen der Zeit ob ich dort beim umstellen Fehler produzierte weile ich durch die umstellung die ein oder andere Zeile kürzen konnte.

[HomeAuto_User]

@OdfFhem

die aktuelle Fassung habe ich hochgeladen und ich habe die Zeit umgestellt.
Absofort erhälst du im JSONOutput die Variante 2020-01-16 10:15:00.
Dadurch konnte ich im Code wenige Zeilen erleichtern weil ich dies einfacher mit einer vorhandenen Funktion nutzen kann.

Das durchtesten brachte erstmal keine Fehler. Ich hoffe alles erwichst zu haben.

[OdfFhem]

@HomeAuto_User

Mit den neuen Formaten für Start und Ende gibt es  - zumindest nach den ersten Versuchen - keinerlei Probleme im FTUI-Bereich.


Ich würde noch kurz die HASH-Theorie ausprobieren oder hattest Du einen anderen Plan?

[HomeAuto_User]

@HomeAuto_User

Mit den neuen Formaten für Start und Ende gibt es  - zumindest nach den ersten Versuchen - keinerlei Probleme im FTUI-Bereich.

perfekt und somit ist für FTUI ja der WEg frei

Ich würde noch kurz die HASH-Theorie ausprobieren oder hattest Du einen anderen Plan?

Nein habe ich nicht, gern können wir dort ansetzen.

EDIT - 14:24:
Ich habe soeben noch 2 Fixes nach der Zeitanpassung behoben. Es wurde hochgeladen.

[OdfFhem]

@HomeAuto_User

Du kannst Dir ja mal meine Anmerkungen anschauen; sie beruhen noch auf dem mittäglichen Stand - die relevanten Stellen sollten aber trotzdem gut zu finden sein ...

Array wird einmalig aufgebaut; toJSON nur im get-Fall ausgeführt:

Code Auswählen Erweitern


#355:     return toJSON($hash->{helper}{FTUI_data}); ###OdfFhem### return $hash->{helper}{FTUI_data};

#1690:    $hash->{helper}{FTUI_data} = \@mychannels; ###OdfFhem### $hash->{helper}{FTUI_data} = toJSON(\@mychannels);


Zeile hat nach der gestrigen Änderung keine Daseinsberechtigung mehr:

Code Auswählen Erweitern


#1686:    ###OdfFhem### $hash->{helper}{FTUI_data} = $data;


{hour_diff} scheint nicht weiter genutzt zu werden, könnte also eigentlich ganz entsorgt werden:

Code Auswählen Erweitern


#1546:    ###OdfFhem### $hash->{helper}{HTML}{$ch_name}{EPG}[$data_found]{hour_diff} = $hour_diff_read;

#1676:    ###OdfFhem### ## JSON data revised
#1677:    ###OdfFhem### for (my $i=0;$i<@{$data->{$ch}{EPG}};$i++){
#1678:    ###OdfFhem### ## clean hour_diff for channel
#1679:    ###OdfFhem### delete $data->{$ch}{EPG}[$i]{hour_diff} if ($data->{$ch}{EPG}[$i]{hour_diff});
#1680:    ###OdfFhem### }


$data braucht man in diesem Fall eigentlich nicht, da es ja sowieso keine Kopie ist:

Code Auswählen Erweitern


#1658:    ###OdfFhem### my $data = $HTML;
#1663:    foreach my $ch (keys %{$HTML}) { ###OdfFhem### foreach my $ch (keys %{$data}) {
#1668:    if (exists $HTML->{$ch} && $d eq $ch) { ###OdfFhem### if (exists $data->{$ch} && $d eq $ch) {
#1669:    $HTML->{$d}{ch_command} = $hash->{helper}{Ch_Commands}{$d}; ###OdfFhem### $data->{$d}{ch_command} = $hash->{helper}{Ch_Commands}{$d};
#1681:    push (@mychannels, $HTML->{$ch}); ###OdfFhem### push (@mychannels, $data->{$ch});


[HomeAuto_User]

@OdfFhem
Ich habe den Code durchgegangen und es sind auch die Stellen wo ich schon überlegte, das man aus 2, eines macht. Top!
Soeben habe ich den Stand im Branch aktualisiert und es folgt weiter testen und durchschauen nach optimierungen.

@all, erschreckt nicht, wie sehr hier es hin und her geht Es werden Anpassungen und Verbesserungen durchgeführt. Sollte jemanden noch was auffallen oder vorschlagen wollen, so bitte nicht scheuen und raus mit dem Vorschlag.

[OdfFhem]

@HomeAuto_User

=== neues Reading ===

In FHEM sind viele Vorgänge ereignisbasiert; FTUI ist da eher noch ein bisschen abhängiger ...

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 ...

=== jsonEPG ===

Momentan wird, wenn es keine JSON-Daten gibt, der Text "no data exists" zurückgeliefert. Dies ist aus meiner Sicht falsch, da man von der get-Routine eine JSON-Antwort erwartet. Wenn keine Daten vorhanden sind, müsste also entweder ein leeres Array oder ein Array mit einer error-Eigenschaft zurückgeliefert werden.

=== automatische Aktualisierung ===

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 ...

Hast Du Lust, Dich mit diesem Thema zu beschäftigen?

[HomeAuto_User]

@HomeAuto_User

=== neues Reading ===
=== jsonEPG ===

Das sind die Punkte welche ich auf jedenfall als Nächstes ändern würde um somit den Nutzen mit FTUI oder [emoji3]JSON Optionen zu vollenden bzw. aussagekräftiger zu gestalten.

Danach wäre der Weg offen für

@HomeAuto_User

=== automatische Aktualisierung ===

wo man schauen kann / sollte, ob die automatische Aktualisierung im FHEM Desktop da genutzt werden kann.

Der Grundgedanke war damal, die Daten auch wirklich nur zu aktualisieren wenn der User auf den Room klickt sobald er aktiv die Aktualisierung via Attribut setzte. Vielleicht gibt es da Wege, das ggf auch für das JSON beizubehalten. Ich denke da so, das man ja kein System belasten müsste, wenn man nicht da ist bzw. Sich innerhalb des Systems wo anders befindet. Kannst du mir da Gedanklich folgen?


Gesendet von iPhone mit Tapatalk Pro

[OdfFhem]

@HomeAuto_User

=== automatische Aktualisierung ===

Ich kann Dir schon gedanklich folgen ... aber aus meiner Sicht ist das EPG-Device ein Datendienst - so etwas wie ein Kalender, ein HTTPMOD, ein ...

Ob man die automatische Aktualisierung nutzt oder nicht, entscheidet jeder für sich selbst. Im Normalfall will man sich nicht z.B. täglich selbst darum kümmern, dass aktuelle Daten bereitgestellt werden. Man geht davon aus, dass die gewünschten Daten jederzeit und aktuell bereitstehen. Wenn man auf seine FTUI-Oberfläche schaut, stehen dort einfach schon die aktuellen Daten ... man freut sich also nicht auf eine Sendung und stellt dann irgendwann fest "achso, das war ja gestern" oder so ähnlich.

Ein Nutzer legt fest, ob er die automatische Aktualisierung haben will, um was für eine Zeit diese durchgeführt werden soll und im EPG-Fall noch interessant, welche Aufbereitungs-Variante dabei ausgeführt werden soll ...

[OdfFhem]

@HomeAuto_User

=== jsonEPG ===

Ich hatte ein wenig getestet. Die folgende Änderung

Code Auswählen Erweitern


#360:    return toJSON({error=>$EPG_tt->{"get_view_FTUI_data"}}); ###OdfFhem### return $EPG_tt->{"get_view_FTUI_data"};

liefert folgende Ausgabe zurück

Code Auswählen Erweitern


{"error":"no data exists"}

Das mit dem Array war übrigens für den Fehlerfall Quatsch, da wir ja nur ein einziges Fehler-Objekt zurückgeben wollen.

Vielleicht entspricht dies ja Deinen Vorstellungen ...

[HomeAuto_User]

Ich verstehe dich schon.

Dein JSON Vorschlag für den Error gefällt mir.

Muss erstmal privat aktiv sein und dann passe ich die Punkte an [emoji4]


Gesendet von iPhone mit Tapatalk Pro