[82_LGTV_WebOS.pm] Modul für LG TV's mit WebOS

[fhem-challenge]

Hallo Andreas,

Ich hatte bei meinem auch hin und wieder Aufnahmen gemacht. Da hat sich bei mir nichts dergleichen abgezeichnet. Allerdings ist das Modul und auch die Infos zu den Codes schon recht alt. Durchaus möglich das WebOS 4 sich an einigen Stellen anders verhält.
Ich weiß es leider nicht.


Grüße

Also ich schaue gerade nach. Reproduzierbar ist, dass wenn eine Aufnahme (auch noch in der Zukunft) auf dem LG ansteht, und ich den TV ausschalten, das Modul diesen als state=on sieht. Man erkennt es am TV auch selbst, weil er in diesem Stadium auch nicht (wie gewohnt)  die SSD (oder andere HDD) am USB abschaltet. Das scheint LG logischerweise nur zu machen, wenn auch zukünftig keine Aufnahme ansteht.

Du kennst auch nicht zufällig ein Reading, welches das Modul produzieren kann (aus dem WebOS lesen kann), der einen ausgeschalteten LG TV bei zukünftiger Aufnahme dennoch als "off" o.Ähnliches kennzeichnet ?


Vielen Dank und viele Grüße!

Andreas

[CoolTux]

Ich schaue die Tage einmal wie genau das off zu Stande kommt. Aktuell glaube ich das es anhand des Status der Netzwerkverbindung geschieht. Aber ich bin da unsicher.

[viegener]

Ich habe jetzt einige Zeit ein Problem mit Sonos gesucht und dabei bin auch daraufgestossen, dass wohl freezes, die im Umfeld von LGTV-Webos auftreten das Problem mitverursachen. Es treten regelmässig (ca. einmal in der Nacht) sehr lange Verzögerungen auf:

Beispiele:

Code: [Auswählen]

2020.03.01 02:44:45 1: [Freezemon] freezemon: possible freeze starting at 02:40:24, delay is 261.595 possibly caused by: tmr-LGTV_WebOS_GetForgroundAppInfo(lgtv)
2020.03.01 02:44:45 2: SONOS0: LastProcessAnswer way too old (Lastanswer: 1583026773 ~ 2020-03-01 02:39:33)... try to restart the process and connection...


Code: [Auswählen]

2020.03.04 01:35:07 1: [Freezemon] freezemon: possible freeze starting at 01:32:13, delay is 174.657 possibly caused by: tmr-LGTV_WebOS_GetCurrentChannel(lgtv)
2020.03.04 01:35:08 2: SONOS0: LastProcessAnswer way too old (Lastanswer: 1583281855 ~ 2020-03-04 01:30:55)... try to restart the process and connection...

Ich vermute einen Zusammenhang mit timeouts in der Kommunikation mit dem LGTV, da das Problem konsistent immer wieder auftritt. Momentan habe ich mal den LG device disabled, damit ist das Problem erstmal entschärft.

[CoolTux]

Ich habe jetzt einige Zeit ein Problem mit Sonos gesucht und dabei bin auch daraufgestossen, dass wohl freezes, die im Umfeld von LGTV-Webos auftreten das Problem mitverursachen. Es treten regelmässig (ca. einmal in der Nacht) sehr lange Verzögerungen auf:

Beispiele:

Code: [Auswählen]

2020.03.01 02:44:45 1: [Freezemon] freezemon: possible freeze starting at 02:40:24, delay is 261.595 possibly caused by: tmr-LGTV_WebOS_GetForgroundAppInfo(lgtv)
2020.03.01 02:44:45 2: SONOS0: LastProcessAnswer way too old (Lastanswer: 1583026773 ~ 2020-03-01 02:39:33)... try to restart the process and connection...


Code: [Auswählen]

2020.03.04 01:35:07 1: [Freezemon] freezemon: possible freeze starting at 01:32:13, delay is 174.657 possibly caused by: tmr-LGTV_WebOS_GetCurrentChannel(lgtv)
2020.03.04 01:35:08 2: SONOS0: LastProcessAnswer way too old (Lastanswer: 1583281855 ~ 2020-03-04 01:30:55)... try to restart the process and connection...

Ich vermute einen Zusammenhang mit timeouts in der Kommunikation mit dem LGTV, da das Problem konsistent immer wieder auftritt. Momentan habe ich mal den LG device disabled, damit ist das Problem erstmal entschärft.

Das Problem wurde mir schon von Thomas zugetragen. Teste bitte einmal ob das Problem mit
attr channelGuide 0
weiterhin auf tritt.

[fhem-challenge]

Hallo Zusammen,

die Frage kann ich gleich beantworten. Ich habe channelGuide=0 und mein freezemon meldet:

>>>
2020-03-06: s:11:19:38 e:11:19:39 f:1.144 d:tmr-LGTV_WebOS_TimerStatusRequest(TV)
<<<

gestern hatte das LGTV Modul wieder (aus ungeklärten Gründen) den LG TV eingeschaltet. Die Ursache für das nahezu beliebige EIn-Schalten und dabei den "flatterhaften" state on , off, on, off in ca. 3 Sekundenabständen ist mir vollkommen unklar. Nach einige Zeit ist wieder "Ruhe". Blöd ist halt nur, dass das Modul den LG tatsächlich dann auch einschaltet, wenn er aus war, so hatte ich schon öfter mal, wenn wir nach Hause kamen, nicht erwartete "Stimmen im Wohnzimmer" , da der TV mal wieder lief ;-)

Viele Grüße!

Andreas

[CoolTux]

Hallo Zusammen,

die Frage kann ich gleich beantworten. Ich habe channelGuide=0 und mein freezemon meldet:

>>>
2020-03-06: s:11:19:38 e:11:19:39 f:1.144 d:tmr-LGTV_WebOS_TimerStatusRequest(TV)
<<<

gestern hatte das LGTV Modul wieder (aus ungeklärten Gründen) den LG TV eingeschaltet. Die Ursache für das nahezu beliebige EIn-Schalten und dabei den "flatterhaften" state on , off, on, off in ca. 3 Sekundenabständen ist mir vollkommen unklar. Nach einige Zeit ist wieder "Ruhe". Blöd ist halt nur, dass das Modul den LG tatsächlich dann auch einschaltet, wenn er aus war, so hatte ich schon öfter mal, wenn wir nach Hause kamen, nicht erwartete "Stimmen im Wohnzimmer" , da der TV mal wieder lief ;-)

Viele Grüße!

Andreas

Kannst Du bitte ein list vom Device machen?

[the ratman]

kurz reinschwindeln ...

sag mal cool: kannts dus irgendwie machen, dass man an den tv senden kann, obwohl dieser noch als offline angezeigt wird?

grund: kann ja durchaus dauern, bis nach dem starten des tv dein modul kommunizieren möchte und ich würd da schon lange meine befehle für z.b. umschalten von apps usw. erledigen.

[CoolTux]

kurz reinschwindeln ...

sag mal cool: kannts dus irgendwie machen, dass man an den tv senden kann, obwohl dieser noch als offline angezeigt wird?

grund: kann ja durchaus dauern, bis nach dem starten des tv dein modul kommunizieren möchte und ich würd da schon lange meine befehle für z.b. umschalten von apps usw. erledigen.

Das wird nicht gehen.
Er zeigt online an sobald eine Netzwerkverbindung aufgebaut wurde. Vorher kommen eh keine Befehle an.


Grüße

[the ratman]

uije, das dacht ich mir anders. na dann: thx für die info!

[viegener]

Das Problem wurde mir schon von Thomas zugetragen. Teste bitte einmal ob das Problem mit
attr channelGuide 0
weiterhin auf tritt.

Ich habe es auch probiert. Es gab wieder dasselbe Problem:

Code: [Auswählen]

2020.03.06 00:56:23 1: [Freezemon] freezemon: possible freeze starting at 00:52:33, delay is 230.157 possibly caused by: tmr-LGTV_WebOS_Get3DStatus(lgtv) tmr-HMLAN_KeepAlive(hmlan)
2020.03.06 00:56:23 2: SONOS0: LastProcessAnswer way too old (Lastanswer: 1583452350 ~ 2020-03-06 00:52:30)... try to restart the process and connection...
Ein Blick in den Code lässt mich vermuten, dass es mit einem blockierenden Verhalten von syswrite in LGTV_WebOS_Write($@) zusammenhängen könnte.

Ich setze jetzt mal verbose auf 4 und schaue ob ich mehr Hinweise bekomme

[CoolTux]

Ich habe es auch probiert. Es gab wieder dasselbe Problem:

Code: [Auswählen]

2020.03.06 00:56:23 1: [Freezemon] freezemon: possible freeze starting at 00:52:33, delay is 230.157 possibly caused by: tmr-LGTV_WebOS_Get3DStatus(lgtv) tmr-HMLAN_KeepAlive(hmlan)
2020.03.06 00:56:23 2: SONOS0: LastProcessAnswer way too old (Lastanswer: 1583452350 ~ 2020-03-06 00:52:30)... try to restart the process and connection...
Ein Blick in den Code lässt mich vermuten, dass es mit einem blockierenden Verhalten von syswrite in LGTV_WebOS_Write($@) zusammenhängen könnte.

Ich setze jetzt mal verbose auf 4 und schaue ob ich mehr Hinweise bekomme

Das wäre super wenn Du das testen könntest. Vielen Dank.


Grüße

[viegener]

Das wäre super wenn Du das testen könntest. Vielen Dank.


Grüße

OK - Ergebnis mit Verbose 4 (Wow 24 MB log in wenigen Stunden). Der entscheidende Zeitpunkt heute morgen zwischen 5:27 und 5:30:

Code: [Auswählen]

2020.03.07 05:27:35 4: LGTV_WebOS (lgtv) - LGTV_WebOS_Get3DStatus: 0
2020.03.07 05:27:35 4: LGTV_WebOS (lgtv) - WriteFn called
2020.03.07 05:27:35 4: LGTV_WebOS (lgtv) - <entfernt>
2020.03.07 05:30:43 4: LGTV_WebOS (lgtv) - ReadFn started
2020.03.07 05:30:43 4: LGTV_WebOS (lgtv) - Socket Disconnected
2020.03.07 05:30:43 1: 192.168.1.34:1000 disconnected, waiting to reappear (hmlan)
2020.03.07 05:30:43 1: HMLAN_Parse: hmlan new condition disconnected
2020.03.07 05:30:43 1: [Freezemon] freezemon: possible freeze starting at 05:27:36, delay is 187.966 possibly caused by: tmr-PRESENCE_StartLocalScan(iphonevonkarin) tmr-HTTPMOD_HandleSendQueue(hssDeparture) tmr-LGTV_WebOS_Get3DStatus(lgtv)
2020.03.07 05:30:43 4: LGTV_WebOS (lgtv) - LGTV_WebOS_GetExternalInputList: 0
2020.03.07 05:30:43 4: LGTV_WebOS (lgtv) - WriteFn called
2020.03.07 05:30:43 4: LGTV_WebOS (lgtv) - socket not connected
2020.03.07 05:30:43 4: LGTV_WebOS (lgtv) - Baue Socket Verbindung auf
2020.03.07 05:30:44 4: LGTV_WebOS (lgtv) Couldn't connect to 192.168.2.80:3000
2020.03.07 05:30:44 2: SONOS0: LastProcessAnswer way too old (Lastanswer: 1583555181 ~ 2020-03-07 05:26:21)... try to restart the process and connection...
2020.03.07 05:30:44 1: HMLAN_Parse: hmlan new condition init
2020.03.07 05:30:44 1: 192.168.1.34:1000 reappeared (hmlan)
2020.03.07 05:30:45 1: HMLAN_Parse: hmlan new condition ok
2020.03.07 05:30:54 4: LGTV_WebOS (lgtv) - Baue Socket Verbindung auf
2020.03.07 05:30:54 4: LGTV_WebOS (lgtv) Couldn't connect to 192.168.2.80:3000
2020.03.07 05:31:04 4: LGTV_WebOS (lgtv) - Baue Socket Verbindung auf
2020.03.07 05:31:04 4: LGTV_WebOS (lgtv) Couldn't connect to 192.168.2.80:3000
2020.03.07 05:31:14 4: LGTV_WebOS (lgtv) - Baue Socket Verbindung auf

5:27 Aufruf scheint ok zu sein
5:27 hier ist auch die letzte Antwort des Sonos-Tochterprozesses
5:27 Freeze started
5:30 Socket disconnected
5:30 Sonos declared dead

danach geht bis heute morgen nur noch "Baue Socket Verbindung auf"...

[CoolTux]

Vielleicht hilft es den Netzwerkverkehr mit zu schneiden.

Bei mir selbst habe ich leider kein SONOS

[viegener]

Vielleicht hilft es den Netzwerkverkehr mit zu schneiden.

Bei mir selbst habe ich leider kein SONOS

Ich denke Sonos spielt hier keine Rolle - ist nur der Teil der mich auf die Spur geführt hat. Es gibt auch freezes, wenn Sonos nicht aktiv ist

Ich habe mal ins log der Fritzbox geschaut, es gibt einen Eintrag um die Zeit herum (5:23 nicht sicher wg. der Zeitdifferenz eigentlich sind sowohl fritzbox als auch fhem auf derselben Zeit)

Code: [Auswählen]

05:23:21 WLAN-Gerät wurde abgemeldet (5 GHz), LGTV, IP 192.168.2.80
05:17:31 WLAN-Autokanal: Die Kanaleinstellungen wurden nicht geändert, weiter aktiv auf Kanal 52 (5 GHz).
05:17:21 WLAN-Autokanal: Aktuelle Erfassung der WLAN-Umgebung (5 GHz) zur Optimierung der genutzten WLAN Kanäle läuft, WLAN-Geräte werden daher unter Umständen neu angemeldet.

Meine Vermutung:
- der LG meldet sich vom Netzwerk ab (nach einigen Stunden inaktivität ?)
- der Socket wird dabei nicht sauber geschlossen sondern bleibt in der "Luft"
- Beim nächsten Schreibvorgang aus FHEM läuft der syswrite (der ist ja blocking) in einen Timeout (aber erst nach Minuten)


Weitere Vermutung:
- Das ganze tritt vielleicht nicht auf, wenn der LG per Kabel ans Heimnetz angeschlossen ist?


 
Die Zeitdifferenz

[the ratman]

sorry - schon wieder ne frage habe.

kannst du mir sagen, wie ich die infos zum laufenden programm am tv abrufen kann?
geht immer noch um mein "tuning" der shield-fb und im speziellen hier um den waf (wie immer *g*).

mein infrarot-hub kann das - heißt dort "Info" und klappt einfach informationen zum laufenden programm über das obere drittel des screens - weißt schon: anfang- und endzeit und - so vorhanden - ein bissi infotexte.
da ich im schlafzimmer leider keinen ir-hub hab, wäre ein befehl direkt an den tv gebot der stunde ...


falls das hilft: mein harmonyhub listet das unter
NavigationExtended --> Guide, Info, PageDown, PageUp, Exit
auf.
ausserdem scheints ein toggle-schalter zu sein - sprich: der befehl lässt die infos auch wieder verschwinden.

und nur zur sicherheit *g*: es geht nicht um die epg!