LGWebOSRemote: a command line remote for LG webOS televisions

The port that newer firmware leaves open

The whole design of this tool follows from one sentence in the readme. It uses a connection via websockets to port 3000 on newer LG televisions, and there are other tools which use a restful connection to port 8080, however that port is closed on newer firmware versions.

So the choice was made for the user. The older approach, a REST interface on the second port, worked on the televisions of a few years ago and stopped working when the manufacturer closed the port. The websocket port is the one that the current firmware still answers, and the tool uses it.

That is worth understanding as a category of problem, because a lot of consumer electronics tooling lives or dies by it. The television is not a computer with an API; it is a device with a service contract that the manufacturer can change in a firmware update, and the people who write these tools are the people who notice when it does.

The implementation is Python, and the transport is handled by a websocket library rather than by hand. The command surface is a single executable called lgtv, and the commands are named after the television's own vocabulary, so an operation is usually a single word that matches what the set calls it.

The project is MIT licensed, the last push was on 2026-10-04, and there are no tagged releases, so the version that matters is the one in the package metadata.

The privacy argument, which the author makes at length

The readme has a section on privacy and security before it has a section on usage, and it is the most forceful writing in the document.

The claim is that LG televisions very likely leak private information to a variety of companies, including screenshots, sound clips, and geo-locatable information such as WiFi network names, and even internal network scans. The argument extends from there: these devices amount to a computer connected to a screen, they have suffered many security vulnerabilities over many years, and they are potentially harmful to your privacy and to your home network security.

The constructive part is short. Some settings can be disabled, and automatic content recognition is the one named, with an article from a security vendor about television flaws and another about turning that setting off.

The recommendation is stronger. The author has decided to disconnect their own television from the WiFi network, and while they maintain the project out of kindness to the community, they advise other users to disable the WiFi functionality on devices that do not need it, listing washing machines, fridge freezers, and dishwashers among the things to consider.

It is an unusual thing to find in the readme of a tool, and it is not the developer being contrarian. The tool only works if the television is on the network, so the argument is really about a device you are invited to keep on your network anyway, and the person inviting you is telling you what they think about it. The links to the security write-ups are the part to follow if you want to check the claim rather than take it on trust.

Scanning, pairing, and the shape of a command

The first two operations are the ones a new user runs, and they are where the readme spends its example budget.

The scan command looks for televisions on the network and prints what it finds as JSON, with a count, a list, and a result field, and each entry has the address, the model, and a UUID.

$ lgtv scan
{
    "count": 1,
    "list": [
        {
            "address": "192.168.1.31",
            "model": "UF830V",
            "uuid": "10f34f86-0664-f223-4b8f-d16a772d9baf"
        }
    ],
    "result": "ok"
}

The auth command then pairs with a television, and it needs the address and a name.

$ lgtv --ssl auth 192.168.1.31 MyTV

And the readme says plainly what happens next: at that point the television will request pairing, follow the instructions on screen. That is the human step in the process, and it is unavoidable, because the pairing request is confirmed on the television itself.

After that, the shape of every command is the same: the name of the television, the connection option, the command, and its arguments.

$ lgtv --name MyTV --ssl on
$ lgtv --name MyTV --ssl off

The name is what makes this scriptable. A stored name means the command does not have to carry an address, so a shell script that turns the television on does not have to know where the television is.

The command list, and the two that are unusual

The available commands are listed in full, and most of them are the television's own remote functions: the volume up and down, the channel up and down, the media play, pause, stop, fast forward and rewind, the three dimensional input toggle, the screen off and on, the mute with a true or false argument, and the power on and off.

Then there are the ones that read state rather than change it, and these are the most useful for automation. There are calls for the audio status and the audio volume, the picture settings, the power state, the sound output, the system information, the current television channel, the foreground application, the cursor socket, the connected input list, the service list, the channel list, the launch points, and the list of installed applications.

Two of them are worth pointing out because they are not obvious.

The first is setDeviceInfo, which takes an input identifier, an icon, and a label, and the readme explains its purpose: it forces the television to disable the so-called PC mode for inputs where the attached device incorrectly or undesirably signals itself as a PC. The example given is a Raspberry Pi running LibreELEC, which is a real problem, because a set top box that announces itself as a computer gets the input restricted to what a computer would show.

The second is the set of YouTube commands. There are four of them, for the modern video identifier and the modern URL, and the legacy identifier and the legacy URL, and the readme notes that the legacy form is what you want if the television has the YouTube plugin, while the plain browser fallback works reasonably well otherwise.

There is also a set of commands for the alert and notification system, including creating an alert with a message and a button, and showing a notification with an icon, and a serialise command, and a generic execute command for anything not covered.

Installing it, in three ways

The requirements are listed first, and they are the ordinary ones for this kind of tool: a wake on LAN utility, the websocket library for Python, and a utility that reads the MAC address of an interface, along with pip and git for the installation itself.

The first installation route is a virtual environment in the current directory.

python -m venv lgtv-venv
source lgtv-venv/bin/activate
pip install git+https://github.com/klattimer/LGWebOSRemote

The second is the same thing system wide, with the environment directory created under the opt directory and the install run with elevated privileges.

sudo mkdir -p /opt
sudo python -m venv /opt/lgtv-venv
source /opt/lgtv-venv/bin/activate
sudo pip install git+https://github.com/klattimer/LGWebOSRemote

The third route is the tool for command line applications, which installs the executable into its own environment and leaves the system Python alone.

pipx install git+https://github.com/klattimer/LGWebOSRemote.git

All three install from the repository rather than from a published package index, which means the install picks up whatever is on the branch rather than a tagged release, which fits a project with no tags.

The system wide route has a wrinkle that is easy to miss: the environment is created with elevated privileges, and then the install command in the readme also runs with elevated privileges, while the activation is done as the ordinary user. That is the kind of detail that trips people up, because the elevated virtual environment is not usable by the ordinary user for the activation step without the path being right, and the readme does not spell out the correction.

The package layout and the pinned dependencies

The repository is small and the manifest describes it accurately.

The package is named after the television platform, with the description of a webOS television controller, and it registers a console script called lgtv that points at the main function of the package. The keywords list the domain, and the classifiers cover the Python versions from 3.8 to 3.12 and the MIT licence.

The version is held in one place in the setup file and is used twice, once for the package version and once to build the download URL for the source tarball, which is a small piece of care that keeps the two from drifting.

The requirements are four, and they are pinned exactly in the requirements file, which is the older and stricter convention. There is the wake on LAN utility, the websocket library, the HTTP client, and the MAC address reader, each at a specific version.

The repository layout has the package in its own directory, the command line entry point at the root, a data directory holding a configuration file that is installed into a config directory on the system, a test directory, a Debian directory for packaging, a build script for Windows, and a document about using it with LibreELEC, which connects back to the PC mode problem the set device info command exists to solve.

The readme also maintains a long list of tested models, which is the kind of list that becomes a project in itself. It runs from an entry level LCD through the OLED range, and it includes entries marked for the secure connection, and it ends with a request to add more. Alongside it, there is a note about the Python versions tested on each platform, from 3.9 on Debian unstable through 3.10 on Windows and on the Windows subsystem for Linux, 3.12 on macOS, and 3.14 on Windows 11.

Editorial conclusion

LGWebOSRemote fits a household that wants to script its television, put it on a network with a remote control of their own, or integrate a set top box or a media centre into a home automation setup. It does not fit a user whose television runs firmware with the websocket port closed, and the readme itself recommends against leaving the set on the network. Verify first that the firmware exposes the port, that the television's IP address is stable enough for the stored configuration to remain useful, and that the pairing step is completed on the screen, because the tool cannot authenticate without a human pressing the right button on the remote.

Frequently asked questions

Official sources

1. Issues
2. klattimer/LGWebOSRemote on GitHub
3. License: MIT
4. README