[reloaded] TvHeadend-Modul

Begonnen von Beta-User, 25 September 2021, 20:48:56

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: CoolTux am 17 Oktober 2021, 16:35:45
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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

Zitat von: Beta-User am 17 Oktober 2021, 16:57:50
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!

Zitat
@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
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

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.

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

Zitat von: Beta-User am 17 Oktober 2021, 19:52:11
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
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

MadMax-FHEM

#19
Zitat von: alanblack am 17 Oktober 2021, 20:00:25
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 ;)

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

und dann wird neu gestartet...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

alanblack

Zitat von: MadMax-FHEM am 17 Oktober 2021, 20:03:07
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.

Zitat
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
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

alanblack

Zitat von: MadMax-FHEM am 17 Oktober 2021, 20:03:07

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
Zitat
In der Routine DEVICE_Define wird ein interner Timer gestartet, der die Updatefunktion aufruft. INTERVAL ist die Periode in Sekunden.

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
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

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:
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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

Zitat von: Beta-User am 17 Oktober 2021, 21:31:49
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
        readingsEndUpdate($hash, 1);

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

in
        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
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

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:
use List::Util qw(max);

Ändern Zeile 435/436:
my $update = $hash->{helper}{epg}{update};
in
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:
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
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

masterpete23

Hi,

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

Beta-User

#27
Zitat von: masterpete23 am 08 Februar 2022, 20:49:33
hast du schon eine Lösung gefunden?
Wollte es gerade einsetzen, aber ohne die Umgebung zu crashen :)
Na ja, das war "nur" ein warning, TvHeadend hat es in den letzten Iterationen bisher nicht wieder geschafft, FHEM zu crashen.

Die Ursache für das warning war vermutlich ein Decodierungs-Thema gewesen (zwangsweise utf-8).

Hier eine aktualisierte Fassung, die auch das mit dem größeren Polling-Intervall und dem Reading statt Log umsetzt.

Kann aber sein, dass das auch "komisch" aussehende Inhalte für die EPG-Daten erzeugt - es wird statt decode_json() nun JSON->new->decode() verwendet (siehe dazu auch https://forum.fhem.de/index.php/topic,122708.msg1227235.html#msg1227235 und https://forum.fhem.de/index.php/topic,126088.msg1207252.html#msg1207252). Bei mir sieht es jetzt auf die Schnelle besehen eher besser aus. Ist aber nicht tief getestet...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files