[reloaded] TvHeadend-Modul

[Beta-User]

Vielleicht hilft das etwas beim Thema connection

https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV

Danke für den Hinweis, an diese Stelle/Parallele hätte ich jetzt leider nicht gedacht.

Fyi: im Modul eine eine m.E. einfachere, aber ausreichende Implementierung deines Passwort-Helferleins drinne...

@alanblack:
Ich schau's mir, kann aber etwas dauern.

Als Leitlinie: Attribute bitte dann, wenn man entweder User-Input ermöglichen will, oder irgendeine Info unbedingt verstetigen muss (weil ohne statefile sonst irgendwas gravierend in die Binsen geht). Tendenziell sollte alles, was von Modulseite her kommt, entweder in Readings (wenn  Event-auswertbar gewünscht ist), oder in Internals (wenn sowieso jedes Mal wieder neu aufgebaut und keine Events erforderlich sind).

[alanblack]

Danke für den Hinweis, an diese Stelle/Parallele hätte ich jetzt leider nicht gedacht.

@CoolTux
Ich suche noch nach Parallelen, aber danke für den Hinweis!

@alanblack:
Ich schau's mir, kann aber etwas dauern.

@Beta-User
Lad nochmal runter! Einen Bug hatte ich noch gefunden; und einfach noch einmal den Internaltimer nach FHEM-Guidedlines eingebaut. FHEM friert nicht mehr ein - aber TVHeadend ist scheinbar sehr träge im Erkennen von "verschwundenen" Input-Devices. Ich probiere gerade, wie ich dort eine Reaktion provozieren kann.

Grüße

[Beta-User]

"Normale" Connection-States sollte man anzeigen bzw. in Readings packen wie bei "Multimedia-Geräten" üblich. Die "Besonderheit" hier ist, dass es zwei unterschiedliche Zugangslevels gibt, nämlich "normal" und "privelegiert" (oder wie auch immer man das nennen will). Das könnte man aber gesondert abbilden (Internal).

Bzgl. TvHeadend_HttpGetBlocking(): Das gefällt mir grundsätzlich nicht so gut. Meine Vision wäre, zuerst eine Art "ping" zu machen und dann die Abfragen, die in einem Rutsch durchgehen sollten, mit dieser Methode zu machen, und alles anderen nonblocking (einschl. des "ping"). Bezogen auf InputQuery hieße das: zwei Routinen, eine zum Aufruf, eine für den Callback.

Ansonsten suche ich grade nach den Unterschieden. Evtl. ist es einfacher, wenn du (auch) ein "diff -u" anhängst.

[alanblack]

Ansonsten suche ich grade nach den Unterschieden. Evtl. ist es einfacher, wenn du (auch) ein "diff -u" anhängst.

Bekommst Du gleich. Ich hatte auch die "neue Version" nicht angehängt.
Allerdings habe ich inzwischen auch die "Next Update" vom Log in ein Reading umgebogen. Da bin ich gerade am Testen, ob ich keinen Bug eingebaut habe. Gib mir ein paar Minuten. 

Grüße

[MadMax-FHEM]

Bekommst Du gleich. Ich hatte auch die "neue Version" nicht angehängt.
Allerdings habe ich inzwischen auch die "Next Update" vom Log in ein Reading umgebogen. Da bin ich gerade am Testen, ob ich keinen Bug eingebaut habe. Gib mir ein paar Minuten. 

Grüße

Ist das nun getestet?

Weil ich hab grad die Version von vorne runter...
...die jetzt auch schon mal...

EDIT: also mit dieser Version kommt mein fhem nicht mehr auf die Beine nach shutdown restart (habe ich sicherheitshalber mal gemacht) / nach dem Warum im Log muss ich noch suchen... Oder ich warte auf die neue Version

Code: [Auswählen]

Undefined subroutine &TvHeadend::gettimeofday called at ./FHEM/70_TvHeadend.pm line 118, <$fh> line 426.
und dann wird neu gestartet...

Gruß, Joachim

[alanblack]

Ist das nun getestet?

Naja, ich würde mal sagen: frühe Beta.  Ich habe gerade gesehen, dass da noch ein Doppelpunkt am Readings-Namen hängt. Sonst ist mir noch kein Bug aufgefallen, der nicht schon drin war.

EDIT: also mit dieser Version kommt mein fhem nicht mehr auf die Beine nach shutdown restart (habe ich sicherheitshalber mal gemacht) / nach dem Warum im Log muss ich noch suchen... Oder ich warte auf die neue Version

Lagging habe ich bisher nicht verzeichnet - allerdings auch noch einen Neustart gemacht; mache ich gleich mal.

@Beta-User
Das diff zwischen der letzten Version von 20:00:25 und der aus dem OP hängt dran.

Grüße

[alanblack]

Code: [Auswählen]

Undefined subroutine &TvHeadend::gettimeofday called at ./FHEM/70_TvHeadend.pm line 118, <$fh> line 426.
und dann wird neu gestartet...

Gruß, Joachim

Dann ist diese Doku überarbeitungswürdig: http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Mechanismus_f.C3.BCr_aktive_Readings

In der Routine DEVICE_Define wird ein interner Timer gestartet, der die Updatefunktion aufruft. INTERVAL ist die Periode in Sekunden.

Code: [Auswählen]

sub
DEVICE_Define($$) {
...
InternalTimer(gettimeofday()+$hash->{INTERVAL}, "DEVICE_GetUpdate", $hash, 0);
...
}

Dann weiß ich aber wenigstens, warum es auch beim ersten Mal nicht funktioniert hat.

Grüße

[Beta-User]

Achtung, nicht alles durcheinanderwerfen:
Die FHEM-Doku ist RICHTIG - wenn man davon absieht, dass Prototypes verwendet werden und das nicht gepackaged ist!

Würde zum Verständnis des Fehlers und der Code-Struktur empfehlen, mal das hier zu überfliegen: https://forum.fhem.de/index.php/topic,122708.0.html.

Dann ist vielleicht auch klarer, warum meine InternalTimer-Anweisungen anders aussehen:

Code: [Auswählen]

InternalTimer(time+AttrVal($name,'PollingInterval',60),\&TvHeadend_ConnectionQuery,$hash);Da  wird kein Text übergeben, sondern eine Code-Referenz, und die Zeit wird einfach aus einer Funktion geholt, die zum Perl-Core gehört... (zu letzterem habe ich bisher noch keine Probleme festgestellt und weiß ehrlich gesagt nicht, warum das früher in FHEM anscheinend anders gehandhabt wurde).

Diff. schaue ich mir an.

[Beta-User]

Habe zwar nicht verstanden, was das jetzt genau macht, und finde auch die gleichzeitig laufenden Timer hinterfragenswürdig, aber so läuft es erst mal wieder, soweit erkennbar...

Anmerkung:
Habe die Timer-Initialisierung nach firstInit verlegt. Hintergedanken:
- Da sind alle Attribute gelesen, man könnte also den Input-Query optional machen und/oder ein eigenes Intervall vorsehen;
- Falls man das Modul bzw. die Instand deaktivieren will, kann man mit "firstInit" alles wieder zum Laufen bekommen...

[alanblack]

Habe zwar nicht verstanden, was das jetzt genau macht, und finde auch die gleichzeitig laufenden Timer hinterfragenswürdig, aber so läuft es erst mal wieder, soweit erkennbar...

Meine Änderung pollt die aktiven DVB-Inputs. Wie ich letzte Nacht feststellen musste, funktioniert das auch,
denn ich bekam durch ein Notify darauf eine Meldung auf's Handy.

Allerdings muss da noch eine Änderung rein: der eine Timer, der durch die EPG-Daten erzeugt wird, reicht so
nicht. Der Odroid schien irgendwie gehangen zu haben. Jedenfalls hatte dieses TVHeadend-Modul keine
(sinnvolle) Antwort bekommen, dadurch gab es keine neue EPG-Abfrage, dadurch keinen neuen Timer...
Bei mir gab es heute morgen ein DVB-Input weniger aber EPG-Daten von quasi Mitternacht.
Aktuell hilft hier nur ein irgendwie geartetes Neuladen des Moduls, sonst passiert bei EPG nix mehr.
Ich überlege, ob es der sinnvollste Weg ist - ein kurzer ist es auf jeden Fall - wenn der zweite Timer auch schaut,
ob "nextUpdate" bereits in der Vergangenheit liegt. Ich habe dafür erstmal die Log-Meldungen in ein Reading
geschoben.
Ab Zeile 477

Code: [Auswählen]

        readingsEndUpdate($hash, 1);

        Log3($name,3,"$name - Next update: ".  strftime("%H:%M:%S",localtime($update)));in

Code: [Auswählen]

        readingsBulkUpdateIfChanged($hash, "nextUpdate", strftime("%H:%M:%S",localtime($update)));
        readingsEndUpdate($hash, 1);ändern.

Nur will ich nicht im Worst-Case alle 60 Sekunden eine EPG-Abfrage machen, die nur auf einen
Fehler läuft.

Ich denke, ich sollte "mal den Stecker vom TVHeadend ziehen" und schauen, wie ich möglichst ohne Systemlast
seitens FHEM die Zeit bis zum "Stecker einstecken" überbrücke und dieses auch sauber erkenne.

Grüße

[alanblack]

Nachdem ich ein paar Mal das Device "neustarten" musste, habe ich endlich mal Zeit gefunden, um nach einer Lösung zu suchen.

Einfügen Zeile 16:

Code: [Auswählen]

use List::Util qw(max);
Ändern Zeile 435/436:

Code: [Auswählen]

my $update = $hash->{helper}{epg}{update};in

Code: [Auswählen]

my $update = max($hash->{helper}{epg}{update}, time+AttrVal($name, 'PollingInterval', 60));
Damit kann ruhig mal die EPG-Abfrage schief laufen.

Dann hatte ich zwei Log-Einträge:

Code: [Auswählen]

2022.01.13 22:03:07 1: JSON decoding error: invalid character encountered while parsing JSON string, at character offset 662 (before "\x{1a} Haarserum\\n4...") at ./FHEM/70_TvHeadend.pm line 338.

2022.01.13 22:03:07 1: JSON decoding error: invalid character encountered while parsing JSON string, at character offset 657 (before "\x{1a} Haarserum\\n4...") at ./FHEM/70_TvHeadend.pm line 338.Da habe ich keinen Ansatz, wie ich die Ursache suchen und ggf. beheben kann.

Grüße

[masterpete23]

Hi,

hast du schon eine Lösung gefunden?
Wollte es gerade einsetzen, aber ohne die Umgebung zu crashen