# LG WebOS Remote Control: a Home Assistant card that behaves like a TV remote

> This Home Assistant Lovelace card puts an LG WebOS television's remote controls on a dashboard, with channel and source pads, colour buttons and an option to send volume to an HDMI receiver instead of the TV. It is a front end for the media player entity, and the work it does not do, like waking a sleeping TV, is left to automations.

**madmicio/LG-WebOS-Remote-Control** — Remote Control for LG TV WebOS

- Repository: https://github.com/madmicio/LG-WebOS-Remote-Control
- Stars: 589 · Forks: 93
- Language: TypeScript
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/madmicio-lg-webos-remote-control

## What the card is, and what it is not

The project is a Home Assistant Lovelace custom card for LG televisions running WebOS, and the README calls it a remote control for LG TV WebOS. The screenshots in the example directory show a remote layout, a channel pad popup, a source pad, colour buttons and a sound source pad.

The important thing to understand is the relationship to the existing integration. The card takes a media_player entity as a required option, so the TV is already known to Home Assistant through its own LG WebOS integration. The card is the remote, not the connection. That division explains the whole design, including the things it cannot do.

The channel panel has an extra dependency, and the README is direct about it: browser_mod is required for this channel panel. It also names a second required piece, a custom card called card-channel-pad, from a separate repository by the same author. So a full installation pulls in the card, the channel pad card, and the browser_mod integration.

The project has been curated and developed in collaboration with Piotr Machowski, and the README carries a HACS badge, which is the Home Assistant community store. That matters for installation because the HACS route is the easiest one, and a HACS default badge means the card is expected to be installed that way.

The primary language is TypeScript, and the package.json describes the module as lg-remote-card with the module field pointing at lg-remote-control.js. The author is Maurizio, and the package licence is MIT, although the repository licence is listed as something GitHub cannot classify.

The releases are 2.0.4 on 2026-01-07, 2.0.3 on 2024-04-07 and 2.0.2 on 2023-12-22, and the last push was on 2026-05-08.

## Installing the card and declaring it in the resources list

There are two documented install routes, and both end with the same requirement: the file has to be registered as a resource so the browser loads it.

The HACS route is first. Find and install the LG WebOS Remote Control plugin, then add a reference inside the resources config:

```yaml
resources:
  - type: module
    url: /hacsfiles/LG-WebOS-Remote-Control/lg-remote-control.js
```

The manual route is second. You download lg-remote-control.js from the GitHub releases page and copy it into your custom components directory, then add a reference to it in the resources config:

```yaml
  resources:
    - url: /local/"your_directory"/lg-remote-control.js
      type: module
```

The resource entry is what makes the card available to the Lovelace editor. A card that is installed in the custom components directory but not declared as a resource will not be found by the frontend, which is the most common installation failure and produces an unhelpful unknown card error rather than a clear message.

After that, the card itself is declared in a Lovelace view like any other custom card:

```yaml
- type: 'custom:lg-remote-control'
  entity: media_player.tv_lg_55c8
  mac: xx:xx:xx:xx
```

The entity and the mac are the two required values. The mac is the television's network address, and the options table explains the consequence of leaving it out: if it is not specified, you need to create an automation to perform the action to turn the TV on. That is the WebOS wake-on-network behaviour, which needs the physical address rather than the entity alone.

## The options table, and the typo that will cost you an evening

The main options are listed in a table with a name, type, whether it is required, supported options and a description. The type is custom:lg-remote-control and the entity is required. The name option sets the tv name.

Then there is the mac, described as the tv mac address, with the note about needing an automation to turn the TV on if it is not specified.

The next option is where the documentation has a problem. The options table lists the AV receiver entity as ampli_antity, which is a misspelling, while the working example further down the README uses ampli_entity. The same spelling appears in the AV receiver volume example, which reads:

```yaml
type: 'custom:lg-remote-control'
entity: media_player.lg_webos_tv_oled55c8pla
mac: xx:xx:xx:xx:xx:xx
ampli_entity: media_player.marantz_sr6010
...
```

If you copy the option name straight from the table your configuration will silently do nothing, because the card will not find an option it does not recognise. Use ampli_entity, as the working example shows.

The rest of the options are the colors list of colour options, the channels list of channels in the popup, the sources list of custom apps, and the color_buttons option to display the RED, GREEN, YELLOW and BLUE buttons. The sources option has a note that if it is not set, the default apps will be displayed, which is a useful default because most users only want the standard launcher row and the extra apps on some televisions clutter it.

## Sources and channels, including three apps with special icons

The source pad is a list of apps, and each entry needs an icon and a name. The icon is described as the url of the image to be displayed in the channel pad popup, with mdi:netflix given as the example, and the name is the app name. The README is precise about how to get the name right: you have to write the exact name of the app to launch, and you can find the correct name in the state of your media_player entity under source_list.

The configuration looks like this:

```yaml
sources:
  - icon: 'mdi:power'
    name: "Netflix"
  - icon: 'mdi:youtube'
    name: "YouTube"
```

Three apps are special cases, and the README calls them out directly. disney, amazon and dazn are special, and the icon has to be entered without the mdi prefix:

```yaml
  - icon: disney
    name: Disney+
  - icon: amazon
    name: Prime Video
  - icon: dazn
    name: Dazn
```

That inconsistency is a small trap. Mixing the two styles produces a pad where three icons are blank while everything else renders.

The channels list works the same way, with an image and a number, and the image is a local path to a logo file:

```yaml
channels:
  - image: /local/lg_remote/tv_logo/Rai 1 HD.png
    number: '501'
  - image: /local/lg_remote/tv_logo/Rai 2 HD.png
    number: '502'
  - image: /local/lg_remote/tv_logo/Rai 3 HD.png
    number: '503'
```

The example uses Italian channel names, which tells you the original user base. The number is the TV channel number, quoted as a string so that multi-digit numbers are not treated as integers, and the repository carries a tv_logo directory and a tv_logos.zip so the logo images can be taken from there rather than sourced separately.

## Why the receiver volume and the power on logic are automations, not card features

The two most interesting design decisions in the project are both cases where the author chose an automation over card logic, and the reasons are stated.

The first is volume routing. The option is dedicated to all those with problems controlling the volume of the AV Receiver through HDMI-cec commands. If the ampli_entity item is configured, and when the sound output is set to external_arc (HDMI) or external_optical (optical output), then the remote control buttons will no longer act on the volume of the television, but on the volume of your receiver.

The second is power on and off of the receiver. The README is explicit that it would have been possible to implement automatic power on and choice of the input source of the receiver when the sound output is set to external_arc or external_optical, and to turn the receiver off when any other sound output is set. The reason it was not done is stated plainly: the cards of home assistants do not work in background but only when rendered, and for this and other reasons it is preferable to use a home assistant automation that manages the process, so the actions will also take place when operating with the physical remote control rather than with the home assistant card.

That is the key insight about this project. A dashboard card only exists while someone is looking at it, so anything that has to happen in the background, such as powering an amplifier on when the TV turns on, belongs in an automation. The example given is a template trigger on the sound_output state attribute, with separate ids for the external_arc and tv_speaker cases, plus state triggers on the TV going from off to on and from on to off, feeding into a choose action.

The third capability, button overrides, arrived with version 2.0. With that version the possibility of overriding the functionality of the button is introduced, so you can call a home assistant service at your convenience. The override keys are documented separately in Override_buttons.md, and the repository root carries that file along with a Change_README file, a hacs.json and an info.md.

## How the card is built, and the state of the project

The build setup is a modern TypeScript and rollup one, and the package.json describes it precisely.

The runtime dependencies are three, and they map directly onto the three things a Lovelace custom card needs. custom-card-helpers at 1.9.0 or later provides the card base class and the standard frontend utilities, home-assistant-js-websocket at 9.1.0 or later gives access to the Home Assistant websocket API, and lit at 3.1.0 or later is the rendering library the card is built on.

The devDependencies are the usual set for a rollup-bundled TypeScript card: the babel plugins including class properties and decorators, the rollup plugins for babel, commonjs, json, node-resolve, terser and typescript, rollup itself at 4.9.1 or later, rollup-plugin-serve for local development, typescript at 5.3.3 or later, prettier, cross-var, replace-in-file and the typescript-eslint packages. The ts-lit-plugin is what makes lit's decorators work in the TypeScript build.

The scripts show the release shape. The build script runs the rollup build and then an add-version step, which uses cross-var and replace-in-file to substitute a version placeholder in the built file:

```json
    "build": "npm run rollup && npm run add-version",
```

and the add-version script replaces the placeholder with the package version in dist/lg-remote-control.js. That is the standard way to stamp a version into a card so the frontend can report which build is loaded, and it means the version in the HACS listing and the version inside the JavaScript file stay in step.

The start script runs rollup in watch mode for development, and the rollup script is the plain build.

The last push was on 2026-05-08 and the newest release is 2.0.4 from 2026-01-07, so the project is still receiving work at a steady pace. The repository is not archived, and the collaboration arrangement with Piotr Machowski suggests it is being maintained rather than merely left in place.

## Conclusion

Adopt this card if you run Home Assistant and own an LG WebOS television and want a usable remote, a channel pad and a source pad on a dashboard, especially if your sound goes through an HDMI receiver. Do not expect it to be a full replacement for the physical remote, because the card only runs when the dashboard is rendered and the card does not implement the ChargeRequest path or wake the TV from standby without an extra automation. Before configuring it, check the supported options table in the README, note that the channel pad needs browser_mod and the separate card-channel-pad custom card, and read Override_buttons.md if you plan to remap individual buttons.

## FAQ

### How do I install the LG WebOS Remote Control card in Home Assistant?

Through HACS by finding and installing the LG WebOS Remote Control plugin, then adding a resources entry with url /hacsfiles/LG-WebOS-Remote-Control/lg-remote-control.js and type module. Manually, you copy lg-remote-control.js from the releases page into your custom components directory and reference it as /local/"your_directory"/lg-remote-control.js with type module.

### Which options does the LG WebOS Remote Control card require?

The type custom:lg-remote-control and the entity are required, and the mac is optional but needed to turn the TV on, since without it you need an automation to perform the wake action. Optional options include name, ampli_entity, colors, channels, sources and color_buttons.

### Why does the channel panel not show up?

The README states that browser_mod is required for the channel panel, and that a separate custom card called card-channel-pad is also required. Both have to be installed for the channel popup to work.

### How do I make the volume buttons control my AV receiver instead of the TV?

Set the ampli_entity option to your receiver's media player entity. When the sound output is set to external_arc (HDMI) or external_optical, the volume buttons then act on the receiver rather than the television. Note that the options table spells the key as ampli_antity, while the working example uses ampli_entity.

### Can the card turn on the TV and the amplifier automatically?

The card itself does not. The README explains that Home Assistant cards only work when rendered, so automatic power on and input selection for the receiver is better handled with an automation, which also fires when the physical remote is used rather than only from the dashboard.

## Sources

- [Issues](https://github.com/madmicio/LG-WebOS-Remote-Control/issues)
- [madmicio/LG-WebOS-Remote-Control on GitHub](https://github.com/madmicio/LG-WebOS-Remote-Control)
- [README](https://github.com/madmicio/LG-WebOS-Remote-Control/blob/master/README.md)
- [Releases](https://github.com/madmicio/LG-WebOS-Remote-Control/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/madmicio-lg-webos-remote-control