PepperDash.Essentials.Plugin.LgDisplay 2.9.0-fix-volume-set-hex.2

PepperDash Essentials LG Display Plugin (c) 2025

License

Provided under MIT license

Overview

This repo contains a plugin for use with PepperDash Essentials. This plugin enables Essentials to communicate with and control an LG display over RS-232.

Example Config Object

{
  "key": "display01",
  "name": "Display 1",
  "group": "displays",
  "type": "lg",
  "properties": {
    "id": "01",
    "volumeUpperLimit": 100,
    "volumeLowerLimit": 0,
    "pollIntervalMs": 45000,
    "coolingTimeMs": 10000,
    "warmingTimeMs": 10000,
    "smallDisplay": false,
    "control": {
      "method": "com",
      "controlPortNumber": 1,
      "controlPortDevKey": "processor",
      "comParams": {
        "protocol": "RS232",
        "parity": "None",
        "baudRate": 9600,
        "dataBits": 8,
        "softwareHandshake": "None",
        "hardwareHandshake": "None",
        "stopBits": 1
      }
    },
    "friendlyNames": [                      //if you want to use friendly names, add this section
	        {
	        	"inputKey": "90",           //The input key for the input you want to use a friendly name for, this has to a valid input key(90,91,c0)
	        	"name": "Friendly Name 1",  //The desired name to be displayed on the screen
            "hideInput": false              //if set to true, the input will not be displayed in the list of inputs
	        },
	        {
	        	"inputKey": "91",
	        	"name": "Friendly Name 2",
            "hideInput": false
	        },
	        {
	        	"inputKey": "c0",
	        	"name": "Friendly Name 3",
            "hideInput": true

	        }
        ],
  }

}

The smallDisplay configuration option is used to control padding of the power on command. If smallDisplay is true, the power on command sent will be ka 01 1. If smallDisplay is false, the power on command sent will be ka 01 01.

For more configuration information, see the PepperDash Essentials wiki.

Mock Display (bench testing without hardware)

The lgDisplayMock type builds the real LG controller on an in-process mock panel instead of a serial port. Power, warm-up and cool-down, inputs, volume, mute, polling and NG handling all run through the same code as with real hardware, so the room and the touchpanel behave the same way. To switch an existing display to the mock, change only type. Any control block is ignored.

{
  "key": "display01",
  "name": "Display 1",
  "group": "displays",
  "type": "lgDisplayMock",
  "properties": {
    "id": "01",
    "mock": {                     // optional; these are the defaults
      "responseDelayMs": 50,      // delay before the panel answers each command
      "powerOn": false,           // starting power state
      "input": "90",              // starting input: 90-93 (HDMI 1-4) or c0 (DisplayPort)
      "volume": 20,               // starting volume, 0-100
      "muted": false,
      "videoMuted": false
    }
  }
}

Like a real panel, the mock answers NG to input, volume and mute commands while it is off, and it answers the RS232 protocol only, so it starts polling without overrideWol.

Use the lgmock console command to make changes at the panel, or to inject faults. The controller picks up panel-side changes on its next poll.

lgmock display01 status
lgmock display01 power on|off
lgmock display01 input 90|91|92|93|c0
lgmock display01 volume 0-100
lgmock display01 mute on|off
lgmock display01 fault none|ng|silent    // ng: answer everything with NG; silent: stop answering (goes offline)

Github Actions

This repo contains two Github Action workflows that will build this project automatically. Modify the SOLUTION_PATH and SOLUTION_FILE environment variables as needed. Any branches named feature/*, release/*, hotfix/* or development will automatically be built with the action and create a release in the repository with a version number based on the latest release on the master branch. If there are no releases yet, the version number will be 0.0.1. The version number will be modified based on what branch triggered the build:

• feature branch builds will be tagged with an alpha descriptor, with the Action run appended: 0.0.1-alpha-1
• development branch builds will be tagged with a beta descriptor, with the Action run appended: 0.0.1-beta-2
• release branches will be tagged with an rc descriptor, with the Action run appended: 0.0.1-rc-3
• hotfix branch builds will be tagged with a hotfix descriptor, with the Action run appended: 0.0.1-hotfix-4

Builds on the Main branch will ONLY be triggered by manually creating a release using the web interface in the repository. They will be versioned with the tag that is created when the release is created. The tags MUST take the form major.minor.revision to be compatible with the build process. A tag like v0.1.0-alpha is NOT compatabile and may result in the build process failing.

If you have any questions about the action, contact Andrew Welker or Neil Dorin.