LBS 19000309 - LG TV webOS

[bkr]

Danke, ich habe den LBS erhalten

[bkr]

Hallo,

ich habe mir gerade im Black Friday deal einen LG Fernseher zugelegt und sehe jetzt, dass der LBS im Downloadportal nicht mehr zur Verfügung steht. Kann mir den jemand per PN zusenden? Das wäre super klasse.

Danke,
Ben

[plarad]

Hallo,
das Einschalten des TV geht grundsätzlich nur über WOL und ich nutze dazu auch nur den LBS 19000825.
Im ausgeschalteten Zustand reagiert der TV nicht einmal auf Pings, sondern akzeptiert nur WOL.
Nach dem WOL prüfe ich die Erreichbarkeit des TV zyklisch mit Pings, bis er antwortet. Das ist notwendig, da der TV einige Zeit braucht, bis er wieder richtig auf LAN verfügbar ist. Die Pings sende ich aus meinem eigenen LBS, um die Übersichtlichkeit der Logik zu verbessern.
Wenn der TV nach WOL auf Pings reagiert schaltet mein LBS auf die Nutzung von bscpylgtv um und fragt zyklisch den Zustand ab. Wobei ich jedoch vor jedem Aufruf von bscpylgtv noch ein Ping sende, um zu prüfen, ob die Netzwerkverbindung noch o.k. ist. Aktuell liegt die Zykluszeit bei meiner Nutzung bei ca. 60 Sekunden, da dies für mich vollkommen ausreichend ist.
Interessanter ist eigentlich die Tatsache, dass alles nicht nur über die Visu, sondern eben auch über die Fernbedienung erfolgen kann. Hätte man nur die Visu als Bedienung könnte man viel einfacher arbeiten.
Deshalb habe ich für die Auswertung der FB zusätzlich einen IR-Trans am Laufen, der die Befehle der FB zusätzlich an die Visu übergibt.
Damit erkenne ich auch den Befehl zur Abschaltung des TV, wenn dieser von der FB kommt und frage dann den Power-Status wieder zyklisch ab. Erst über bscpylgtv und dann über Ping. Power Off ist für meine Anwendung erst dann, wenn keine Pings mehr beantwortet werden. Vorher ist für mich nur Standby.
Das Ganze läuft natürlich mit etwas Verzögerung, die mich jedoch nicht stört. Den Zustand Power Off des TV benötige ich primär für die Abschaltung der Stromversorgung für die schwarzen Kästen (TV, Endstufe, Vorstufe, usw.). Diese wird erst getrennt, wenn wirklich alle schlafen. Für die Steuerung von Licht, Rollladen usw. nutze ich den Status meiner Audiokiste. Die ist wesentlich flinker bei den Reaktionen und einfacher über LAN auszuwerten.
Unterm Strich ist das Ganze bestimmt nicht ultraflink. Aber braucht man das wirklich?
Wenn schnelle Reaktionen notwendig sind, sind KNX und die Visu selbst schon zu langsam.
Durch den Einsatz des IR-Trans kann ich bereits kurz nach dem Senden von IR-Befehlen auch über die Visu reagieren und brauch nicht unbedingt die Änderung des Gerätestatus abwarten. Wenn dieser etwas Nachlauf hat, ist das nicht so schlimm. Auch der Takt der zyklischen Geräteabfrage kann langsamer sein. Erst wenn sich etwas auf der Visu oder der FB tut, frage ich außerzyklisch ab.
Szene auslösen, Geräte abschalten, usw., das sind alles Funktionen, die mit etwas Verzögerung auskommen.
Zeitverzögerung sind bei dieser Art der LAN-Verbindung unvermeidbar. Bei jeder Aktion muss ja zunächst einmal eine Verbindung der Geräte neu erstellt werden. Und dann kommt noch die Reaktionsgeschwindigkeit des Endgerätes dazu. Und da sind der LG und mein Visuserver bestimmt auch nicht die Schnellsten.

[Thome]

Hallo plarad, vielen Dank. Mit deiner Anleitung hat es jetzt geklappt! Wirklich zufrieden bin ich aber noch nicht.
Power_off klappt soweit. Für Power_on nutze ich weiterhin den LBS hier, da der WOL kann. Das funktioniert auch ohne erfolgreichen Handshake.
bscpylgtv kann wohl gar kein WOL?
Und hast du eine elegante Lösung für den aktuellen Power Status? Stromverbrauch über Schaltaktor messen funktioniert nur bedingt, da der C3 nach dem Ausschalten bei der automatische Regeneration noch recht viel Strom zieht. Der LBS hinkt mit dem Status auch ziemlich hinterher.
Mit Pings bombardieren? "get_power_state" über bscpylgtv zyklisch aufrufen? Wird je nach Updateintervall auch deutlich hinterher hinken.

[plarad]

Hier ein kurzer Auszug aus meiner Doku als pdf. Eventuell ist das ja hilfreich.
Ich habe mir 2 getrennte LBS für die Nutzung geschrieben, die jedoch auf meinen speziellen Anwendungsfall zugeschnitten sind und die ich deshalb auch nicht veröffentlicht habe.
Aber wenn erst einmal Python 3.10.x läuft, ist der Rest auch kein Problem mehr.
Viele Grüße

[Thome]

Hallo plarad, wie hast du denn Python 3.10 auf CentOS 7 installiert bekommen? Bei mir scheitert die Installation immer mit einem Fehler

./_bootstrap_python ./Programs/_freeze_module.py abc ./Lib/abc.py Python/frozen_modules/abc.h
Fatal Python error: init_import_site: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
  File "/root/Python-3.12.2/Lib/site.py", line 73, in <module>
    import os
  File "/root/Python-3.12.2/Lib/os.py", line 29, in <module>
    from _collections_abc import _check_methods
SystemError: <built-in function compile> returned NULL without setting an exception
make[1]: *** [Python/frozen_modules/abc.h] Fehler 1
make[1]: Leaving directory `/root/Python-3.12.2'
make: *** [profile-opt] Fehler 2
​

Habe auch schon diverse Python Versionen probiert, immer das gleiche Ergebnis.

Ich wäre mit der Python Lösung sehr zufrieden. Modbus läuft bei mir auch sehr zuverlässig über den Python modbus-cli und dem EXEC LBS.

Danke!

[plarad]

Ich habe das gerade mal heruntergeladen und nur schnell auf der PHP-Interactiv Shell versucht. Bis $tv = new SmartTV() keine Fehler. Bei Pairing-Anforderung $tv->displayPairingKey() knallt es aber schon. Habe das Ganze mit den Ports 8080, 3000 und 3001 getestet. Immer das gleiche Ergebnis.

Als Standard-Port 8080 zu verwenden entspricht auch nicht dem, was ich mit Wireshake gesehen habe. Da läuft das aktuell über 3001 mit TLS1.2.

Da die Lösung bereits aus 2016 stammt und die Problem mit dem Handshake erst seit Mitte 2023 bestehen, kann ich mir vorstellen, dass das Handshake auch in dieser PHP-Version nicht funzt.

Viele Grüße, Plarad

[jonofe]

Schön wäre es, wenn sich ein Python-Kenner das obige Paket anschauen könnte und es schaffen würde, dies direkt in PHP umzusetzen.

Hast du mal getestet, ob diese Implementierung läuft:

https://github.com/StefanNemeth/PHP-LG-SmartTV

Da es schon PHP ist, wäre es vermutlich nicht so aufwändig, dies in einen LBS zu gießen. Ich würde das dann mal über die Weihnachtsferien versuchen umzusetzen.

[plarad]

Hallo,
meine Vermutung, dass das Problem des fehlerhaften Handshakes mit einem Firmwareupdate von LG in Zusammenhang steht hat sich durch weitere Informationen in anderen Foren verdichtet.
Dabei habe ich aber auch einen Lösungsansatz gefunden und diesen bereits erfolgreich getestet.

https://github.com/chros73/bscpylgtv

Hier gibt es eine Lösung, die auch mit aktueller LG-Firmware funktioniert. Es wird eine Möglichkeit geboten, auf der Ebene der Kommandozeile zu arbeiten.
Für einen schnellen Test wird eine Version für Windos-Kommandozeile bereitgestellt, die auch keine Pythoninstallation erfordert. Dieser Test lief sehr schnell und positiv.

Die Handshakeverbindung läuft jetzt über Port 3001 mit TLS1.2 (laut Wireshake)

Für andere Betriebssysteme wird die Installation von Python > Version 3.8 nötig.

Da CentOS 7.x dies nicht bereitstellt, habe ich nachträglich Python 3.10.13 auf CentOS 7 installiert, was nicht ganz so einfach war, wie es klingt. Es dauerte mehrere Versuche, bis alle benötigten Python 3.10.-Pakete installiert waren. Aber Hartnäckigkeit zahlt sich aus.

Ich habe nun auch auf der CentOS-Kommandozeile getestet und es läuft.

Nun muss das Ganze noch mit einem entsprechendem LBS weiter geformt werden. Da ich nur einen Bruchteil der Kommunikation mit LG benötige, wird mir dies wohl auch noch gelingen.

Schön wäre es, wenn sich ein Python-Kenner das obige Paket anschauen könnte und es schaffen würde, dies direkt in PHP umzusetzen.

Viele Grüße, Plarad

[plarad]

Hallo,
ich habe zwar kein webOS7, sondern 5.5.0-1101, habe aber damit neuerdings auch ein Problem mit dem WS-Handshake.

Ich nutze eine stark reduzierte Version des LBS 19000309, da ich einen Großteil der Funktionen nicht benötige (der LG arbeitet nur als Monitor).

Leider läuft dieser aber auch aktuell nicht mehr (außer das WOL zum Einschalten).

Ich habe eine Version des LBS unabhängig von EDOMI mit Apache NetBeans und XAMPP zum Testen. Damit kann ich auch schrittweise abarbeiten und habe folgendes Ergebnis:

fsockopen() funktioniert ohne Fehler.

Anforderung zum Aufbau der WS-Verbindung habe ich aus dem LBS 19000309 übernommen.
$ws_handshake_cmd = "GET " . $this->path . " HTTP/1.1\r\n";
$ws_handshake_cmd .= "Upgrade: websocket\r\n";
$ws_handshake_cmd .= "Connection: Upgrade\r\n";
$ws_handshake_cmd .= "Sec-WebSocket-Version: 13\r\n";
$ws_handshake_cmd .= "Sec-WebSocket-Key: " . $this->ws_key . "\r\n";
$ws_handshake_cmd .= "Host: " . $this->host . ":" . $this->port . "\r\n\r\n";

$path=‘/‘
$port=3000
$host=‘IP des TV‘
$ws-key generiert wie in LBS19000309

Versendet wird das mit fwrite($sock,$ws_handshake_cmd) und liefert 157 als Ergebnis. Also o.k.

stream_select($read, $write, $except, 5) liefert auf dem entsprechenden $sock im $read-Array die gewünschte 1 – auch o.k.

Und nun kommt das Problem:
$response belege ich zum Testen mit einem String z.B. xxxx und führe die Abfrage des Steams durch.

$response = stream_get_contents($sock);

Der Befehl wird ausgeführt, liefert jedoch nur einen leeren String (die xxxx sind weg). Aber der gewünschte json-String fehlt.


In den TV-Einstellungen ist::
Schnellstart (QuickStart+) auf aus
Mobilgeräte auf ein

Im versteckten Servicemenü
IP Control an
WOL auf an

Hat LG da eventuell bei einem Update etwas geändert?

Hat jemand eine Idee?

Danke bereits vorab.

[jonofe]

Der Power Status jedoch wird angezeigt, somit muss ja eine Verebindung bestehen.

Der Power Status wird aus der Netzwerk-Errreichbarkeit abgeleitet, ist also keine Indikation für eine API Kommunikation.
Ich habe leider kein WebOS 7 TV und kann somit keine qualifizierte Hilfe geben.
Die Fehlermeldung bedeutet, dass keine Antwort auf den Handshake Request gekommen ist.
Evtl. hat LG da was geändert.

[eXec]

Moien,

hat jemand den LBS mit einem webOS 7.3.1-43 am laufen?
Bekomme kein Pairing hin.

 [TABLE="border: 0, cellpadding: 0, cellspacing: 0"]
  [TR]
  [TD]2023-10-23 21:30:52[/TD]
  [TD]848390[/TD]
  [TD]1496766[/TD]
  [TD]debug[/TD]
  [TD]EXE19000309 [v1.0]: Sending WS handshake: GET / HTTP/1.1[CR][LF]Upgrade: websocket[CR][LF]Connection: Upgrade[CR][LF]Sec-WebSocket-Version: 13[CR][LF]Sec-WebSocket-Key: SWs3eEtFaig1MnBtIm92PQ==[CR][LF]Host: 10.0.0.203:3000[CR][LF][CR][LF] (8239)[/TD]
  [/TR]
  [TR]
  [TD]2023-10-23 21:30:52[/TD]
  [TD]850378[/TD]
  [TD]1496766[/TD]
  [TD]debug[/TD]
  [TD]EXE19000309 [v1.0]: ERROR during WS handshake! (8239)[/TD]
  [/TR]
  [TR]
  [TD]2023-10-23 21:30:52[/TD]
  [TD]852102[/TD]
  [TD]1496766[/TD]
  [TD]debug[/TD]
  [TD]EXE19000309 [v1.0]: Connection closed to 10.0.0.203 (8239)[/TD]
  [/TR]
  [/TABLE]
 ​

image.png
Der Power Status jedoch wird angezeigt, somit muss ja eine Verebindung bestehen.
Gruß André

[jonofe]

Das bedeutet, dass irgendwas beim Auslesen der App-Liste schief läuft, bzw. dass die App-Liste leer ist. (A13)
Was genau kommt an A13?

Das es alle 30 Sekunden passiert, liegt vermutlich daran, dass E31 alle 30 Sekunden getriggert wird.

Hast du evtl. Apps vom Gerät gelöscht, so dass jetzt ggf. gar keine mehr installiert ist?
Oder eine neue Firmware instaliert?

Du kannst die Zeile 1144 (was der Zeile 657 im EXEC Bereich entspricht) anpassen:

Aus

if (array_key_exists('payload',$apps) && array_key_exists('launchPoints',$apps['payload'])) 

machst du

if (is_array($apps) && array_key_exists('payload',$apps) && array_key_exists('launchPoints',$apps['payload'])) 

Dann sollte der Fehler eigentlich weg sein.

[Zaschii]

Seit einigen Tagen alle 30s folgenden Fehler im Log....

EXE19000309.php | Fehlercode: 2 | Zeile: 657 | array_key_exists() expects parameter 2 to be array, null given

ERROR

... jemand eine Idee?

VG

[jonofe]

Grundsätzlich wird nach dem Eingangswechsel ein Update aufgerufen. Kann sein, dass dies zu früh kommt, um schon den neuen Wert zu holen.
Bei mir funktioniert es aber über E31 und E31, d.h. E31 kurz nach Wechsel des Eingangs oder aber E32 auf 1 setzen.

Verwndest du den LBS für mehrere Geräte? Grundsätzlich mach es bei solchen LBS Sinn die Konfigurationseingänge statisch zu belegen und nicht über iKOs, damit der LBS beim Start alle notwendigen Infos hat, die er zum Start braucht. Und bei mehrere Geräten dann ja eine LBS Instanz je Gerät.