TV control typically requires external hardware that uses an additional data port, power outlet, and some type of custom programming. Costs are usually around $80 to $150 per display and have to be managed on some type of proprietary system. In commercial and corporate environments, most displays have some form of hardware behind them for digital signage or conference room screen-sharing. Commercial (and some consumer) displays almost always have some form of RS-232 port on them for control.

WeWork uses Enplug devices for digital signage and Mersive Solstice Pods for conference room screen sharing. These devices are network accessible with an API, have USB connectors, have relatively powerful hardware, and have software developed entirely in-house. This gave me an idea to use the devices to control the televisions with a simple, low-cost USB to RS-232 cable. Enplug and Mersive each had to develop their software, I had to develop custom hardware and control software, and it all had to be deployed. In total everything took a little over a year to complete.

3 Types of RS-232 Input (Source: LG MFL69843813)

The result is that Enplug and Mersive Solstice Pod devices are capable of controlling the televisions they are connected to (as long as the television has RS-232) and the software handling the control is completely open to design by the teams responsible for controlling the televisions. The return on investment is several million dollars for WeWork by turning the televisions off at night and on weekends. The control is fully customizable and can also be used for television control based on conference room booking or building occupancy.

Early Testing

As I began my research, I found that in around 2018 Enplug had experimented with having RS-232 control from their devices. Since their hardware only had USB ports and no serial they designed the system to use the Prolific PL2303 chipset. The PL2303 converts USB to an RS-232 serial interface that is available globally and is relatively low-cost. It works on most operating systems, including Windows, Mac, Linux, and Android, right out of the box without any additional driver installation necessary.

Enplug’s first system worked, but the software was not great. The issue was that it used a closed system of RS-232 commands and a scheduling system that was limited. This meant that you could only control the displays or devices that they pre-configured for you and you could not truly customize the schedule. On top of that, with the limited software it took a while to setup a large number of display groups.

Enplug proved that it was possible and that the idea was not crazy. The cable hardware had to be addressed and the software needed work, but the concept was proven to be possible.

Enplug's Built-in Controls


Low-profile DB-9 Design

During testing with Enplug’s first system, two major hardware issues were identified. Luckily the solutions were not that difficult, they just required a lot of cable testing.

First, displays typically used the male connector of DB-9 for RS232 input. Most PL2303 USB to DB-9 connectors on the market use male USB type A to male DB-9 connections; for example, a popular high-quality cable already available is the Sabrent CB-RS232, shown below. Since most televisions used a DB-9 male connector, a null-modem female DB9 to female DB9 cable would be necessary to make the connection with the displays male DB-9 RS232 input. Note that null-modem swaps Tx (transmit) and Rx (receive) on the DB9 connections (this is necessary because if you connect Tx to Tx and Rx to Rx there won’t be any data passing between devices). The PL2303 devices on the market had cable lengths of 3 feet to 6 feet and null modems cable lengths were typically 6 feet, which meant 9 to 12 feet of cable behind the display when the control device was 1 to 2 feet away.

Second, displays mounted to ADA (Americans with Disabilities Act) requirements use low-profile mounts that do not allow for much room behind the display. Most PL2303 USB to DB-9 connectors on the market use a straight connector that take up 2 to 3 inches of space behind the connection point. Also, the PL2303 chipset was usually in the DB-9 connector, such as with the Sabrent CB-RS232 shown below, which added even more bulk. A low-profile mount would not work with straight connectors, so a 90 degree adapter could be used. The issue there is that the adapters usually cost the same or more than the PL2303 USB to DB-9 cable and they are bulky. To add confusion, they come in an upward or downward variation, but it’s pretty confusing to order since DB-9 connectors can be oriented anyway the device manufacturer wants so just knowing if you need up or down doesn’t help a lot.

The solution here was obvious, a new cable needed to be produced. I got to work sourcing a supplier that could provide a female DB9 connector with correct Tx/Rx pin-out that was specially low profile. The PL2303 chipset had to be located on the USB side and the DB-9 connector had to be custom molded. The manufacturer was sourced on Alibaba, their storefront is here. Cables can be purchased directly from them, however they will likely require purchase of 100+ cables at a time. Prices fluctuate based on market conditions but it will always be much cheaper than purchasing the PL2303 USB DB-9 cable, null-modem cable, and 90-degree DB-9 adapter from a US reseller.

3.5mm Phone-Jack RS-232 Connectors

Once the DB-9 connector was sorted out, there was an entire other issue to address. LG and Samsung televisions also use 3.5mm Phone-Jack TRS (tip-ring-sleeve) connectors for their RS-232 controls. 3.5mm Phone-Jack TRS connectors are the exact same thing as a consumer headphone jack. For WeWork deployment specifically, the televisions found at sites were sourced by different AV integrators (installers) that used different television make and models based on availability and price. Also televisions that were replaced due to failure were likely to be different since models are updated annually. The result was that installers of these television control cables had to have all options available when they went on-site, otherwise they would have to visit the site twice which would add significant cost and time to the project.

So why does LG and Samsung use this connector for RS-232? Likely because it is very low-cost, they are already purchasing these connectors for headphone/speaker output, and they take up much less space on their PCB. Ideally, LG and Samsung would use the same pin-out for TRS to RS-232 so that cables can be swapped between them without issues. This is the real world so their pin-outs are not the same, they swapped Tx and Rx. This difference in wiring had to be permanently marked on the cable without influencing manufacturing costs, so the manufacturer used a different color of strain relief connector. Red strain relief connectors were used for LG while black strain relief connectors were used for Samsung. The 3.5mm Phone-Jack connector itself was also specified to use the 90-degree variation in order to reduce profile and reduce strain on the cable. The same manufacturer was used as they could make the cables exactly as required and cost significantly less than any major reseller.


I had to consider the different ways control could be handled by software. Zabbix had to monitor everything and retain data on television power state so that cost savings could be accurately calculated. The amount saved could be estimated based on the number of devices with cables but this would not account for or alert on any issues.

The software had to allow for any control or monitoring system to interface with the televisions and it also had to allow for any RS-232 commands to be sent and received. The best solution was to have Enplug and Solstice Pod devices allow direct access to the PL2303 over their API, including getting the response back.

I spent a few months annoying Enplug and Mersive to get them to release software updates that allow for their API to directly send and receive RS-232 on the PL2303. This would allow a user to send a RS-232 command through the devices API and control any device with any RS-232 command set. It took some convincing and a lot of testing, specifically with getting both ASCII and HEX to work, but they both eventually released the updates to production.

Enplug was first to release the update and they published a guide along with it:

Since this API was based on the existing Enplug API that allows for getting all device information, it’s very simple to determine what to control in a script that controls all displays connected to the devices. There are definitely a few challenges that I’ll address.

Mersive released their update and published the documentation on their website here. They use a method where the device communication is handled over the local network.

Command Examples

Demonstrating how this works is simple. First we have to look at the commands each manufacturer uses. For this example we will just look at turning the television on:


ManufacturerSend Command (turn ON)Receive Confirmation
LG (*universal Set ID)ka 00 01 <CR>a 01 OK01x
SAMSUNG (*universal Set ID)\xAA\x11\xFE\x01\x01\x11*none

Some explanations…

First I want to address what “universal Set ID” is. Commercial televisions sometimes have RS-232 IN as well as RS-232 OUT. This allows for multiple televisions to be chained together with 1 central device sending commands that are applied to every television. The televisions each have a setting in their menu to set the “Set ID” which allows a commands to individually address a television in an RS-232 chain. Universal Set ID means every television in the chain will be addressed. For LG, I use universal instead of 01 (the default) so the commands will always work. For Samsung, I use Set ID 01 because Samsung does not provide any response when a universal Set ID is used.

Next, is carriage return. This is same thing as pressing the “Enter” key on your keyboard. It is basically telling the command to “take”. Some RS-232 devices do not require and will not even work if you include it, Samsung is an example.

Last, you likely notice how LG commands are a little easier to read. That is because LG and Sharp use ASCII formatting while Samsung uses HEX formatting. Some manufacturers will accept either but usually they only work with one or the other.

Now that we know which commands to send and what to expect from the television, we can test it with each device.


Using standard Enplug API, the following needs to be placed in the body:


    "Target": "tvcontroller",
    "Command": "serial",
    "Argument": ["ka 00 01\r"]


    "Target": "tvcontroller",
    "Command": "serial",
    "Argument": ["0xAA0x110x000x010x010x13"]

The API waits 5 seconds for the television to respond to the commands, then returns the results to the user:

LG Response

    "Result": "a 01 OK01x\n",
    "Success": true

Samsung Response

    "Result": "AAFF000341110155\n",
    "Success": true

Solstice Pod





The API waits 5 seconds for the television to respond to the commands, then returns the results to the user:

LG Response

{"result":"Success","reply":"a 01 OK01x"}

Samsung Response


What in the world is �� ? Samsung TVs response in unicode, it can be converted for script use.

Additional Commands

More than power can be controlled with RS-232; it can actually control more than the remote control because RS-232 allows you to specify the parameter within the command. This means instead of clicking “Brightness” then adjusting the brightness percent with a slider you can simply specify brightness and percent within one RS-232 command. At WeWork specifically, energy saving mode is activated every time the televisions are turned on. This generates even more electricity cost savings.

Just a few examples of RS-232 controls are Aspect Ratio, Screen Mute, Volume Mute, Volume Control, Contrast, Brightness, Color, Tint, Sharpness, OSD Select, Remote Control Lock, Treble, Bass, Balance, Equalizer, Energy Saving, Tune Command, and Backlight.

Control Software

There are several ways to handle the control side of the software, the only requirement is that it must be able to use Enplug and Solstice Pod API. The main thing is that a centralized control system is possible. It makes it easy to build software to do custom scheduling and control across an entire fleet no matter the size.

For WeWork, Omnissiah is used to automatically detect and identify all Enplug and Solstice Pods found on their network. They are automatically added to Zabbix where the Enplug and Solstice Pod templates cause each host (device) to engage a trigger that causes an action to add a database record with host information. This trigger uses the hosts known time zone that Omnissiah sets in Zabbix inventory. Twice an hour a cron job runs that performs tasks defined by the database records. The result is that televisions are turned on and off on a defined schedule that accommodates for time zone differences. The system also checks twice per hour that the television is in the correct state (on or off based on the time and date) and a Zabbix item for television control status is updated, which includes “success”,”television error”,”PL2303 error”, “No PL2303”, or “device error”. The detailed status updated regularly allows for tracking television state and calculating any power savings. This system is fairly complicated because WeWork is controlling over 6000 televisions globally.

Manual Control

Since the control is done through the device API it is easy to use Postman to manually control the television. Postman even exports your request to almost any script language so you can just copy paste it out. Since Zabbix can run external scripts it’s simple to take the Postman export, modify it a bit to be more dynamic, and tie it into Zabbix for manual user scripts.

Below are some quick and dirty Python scripts to handle Enplug and Mersive Solstice Pod television control using Zabbix. These take the device ID (Enplug) or IP (Solstice Pod) and use a defined Zabbix macro to send the control. Using a macro allows the script to be the exact same while the macros can be added or modified by the user to change the controls sent to the television.

Installing Manual Scripts

Installing the manual scripts provided above is the same process as configuring any script within Zabbix. I have a quick guide on where to put the scripts available here. There is official documentation available here that explains how scripts in Zabbix work.

Once you have the script in Zabbix you can create an action with it or you can add it to your manual scripts.

Click on Administration, Scripts, then click Create script. From there you specify the name of the script with “/” used to indicate a sub-section. I used “Solstice Pod TV/Power/Turn TV Off” so when a user clicks on a host they can hover over Solstice Pod TV, then hover over Power to see Turn TV Off. The advantage of this is that scripts can be clearly structured.

Now add the necessary commands to run the script. This is the same thing you would type on your command line to run the script, so it should be similar to :

/usr/lib/zabbix/ "{$TVPWROFFLG}" "{$TVPWROFFSS}" "{HOST.CONN}" " "

This is saying to run /usr/lib/zabbix/ with arguments generated by Zabbix macros. The macros are defined below, note that quotes are used because the arguments have spaces in them.

“{$TVPWROFFLG}” – RS232 command for turning LG television off
“{$TVPWROFFSS}” – RS232 command for turning Samsung television off
“{HOST.CONN}” – Interface IP address defined within Zabbix
” ” – Blank, it should have television vendor defined if available

These macros must be defined within Zabbix as global macros or template macros, otherwise the script will fail. You can easily assign them at the template level by modifying the template configuration, or you can just set them as global macros under Administration, General, Macros.

Using macros makes it easy to modify/add/remove RS-232 commands and create new scripts for the users to run, even though you only have 1 script file per device type (Enplug or Solstice Pod).

To finish creating the script, define the user groups allowed to access it, set Host group to Selected and set it for the group defining your Enplugs or Solstice Pods based on the script you are creating, set permissions to Read, and set Enable confirmation with the message if you prefer. That is all that is required, you will immediately be able to use the script on hosts with the correctly assigned group.

Leave a Reply

Your email address will not be published.