Get tablet battery level into a PLC with Node-RED and OPC UA

What you need

• A Windows tablet that runs the kiosk browser and Node-RED on the same machine. The battery node reports the battery of the machine Node-RED runs on, so a copy parked on a server is no use here.
• The node-red-contrib-battery node, installed from the palette manager. Its message carries three fields: hasbattery, whether a battery is present; maxcapacity, the pack's full-charge capacity; and percent, the charging level in percent.
• An OPC UA client node from the palette, set to write a value on each incoming message.
• The PLC's OPC UA server, enabled. OPC UA is standardized as IEC 62541: the PLC runs a server that publishes its variables in an address space, and your client connects to a server endpoint and reads or writes those variables.
• A network path from the tablet to the PLC, with port 4840 open, the standard OPC UA port.
• A charger arrangement that keeps the pack topped up between shifts. Use the charger the tablet was designed for, and set the power plan so the tablet stays awake on charge through its shift. Charging setups for a mounted tablet HMI, dock and cable choices included, are covered in this charging guide for a Node-RED tablet HMI.

Read the battery level on the tablet

1. Install node-red-contrib-battery from the palette manager.
2. Add an inject node, set it to repeat every 30 s, and wire it into the battery node. That interval is the poll rate the rest of this article assumes.
3. Deploy and open the debug pane. A message should arrive on each poll carrying percent somewhere between 0 and 100 and hasbattery true. If hasbattery comes back false, Node-RED is probably not running on the tablet, or the machine has no battery to report.

Write the percent to the PLC over OPC UA

1. In the PLC project, declare the variable the tablet will fill: TabletBatteryPercent, type INT, holding a whole number from 0 to 100. Note the node ID it takes in the server's address space.
2. Install an OPC UA client node and set its endpoint to your PLC's address on port 4840; an illustrative endpoint looks like opc.tcp://192.168.1.50:4840. Match the security policy the server asks for; on a first connection that usually means trusting the client certificate on the PLC side.
3. Point the client at the node ID of TabletBatteryPercent and set the action to write on each message.
4. Between the battery node and the write, a short function picks out the percent and sends 0 when no battery is reported:

// Illustrative mapping. The battery node message carries percent,
// maxcapacity and hasbattery; confirm where your node version places
// them in the debug pane before relying on this path.
let percent = 0;            // number, charging level in percent
let present = false;        // boolean, battery present
percent = msg.payload.percent;
present = msg.payload.hasbattery;
msg.payload = present ? Math.round(percent) : 0;  // 0 when no battery is reported
return msg;

5. Deploy again. From here the PLC holds the tablet's charge state, refreshed on every poll.

If the cell already moves data through an MQTT gateway, the same percent value rides along on that path; MQTT in CODESYS: PLC library or Node-RED gateway shows how the gateway side is wired. If the tablet cannot run Node-RED at all, a small service program built on the BatteryReport class, the documented Windows route to charge, capacity and status, can hand the same values over TCP or a file for another program to forward.

Raise the alarm in the PLC

The alarm belongs in the PLC, next to the machine alarms. Two declared variables and four lines do it:

// TabletBatteryPercent: INT, refreshed over OPC UA on each poll
// LowBatteryAlarm: BOOL, shown in the HMI software's alarm list
IF TabletBatteryPercent < 20 THEN
    LowBatteryAlarm := TRUE;
END_IF;
IF TabletBatteryPercent >= 25 THEN
    LowBatteryAlarm := FALSE;
END_IF;

The raise limit is 20 percent and the clear limit is 25 percent. The 5-point band stops the alarm chattering while a charging pack hovers near the limit. Twenty percent buys time to act: on a tablet that runs about 7 h per charge it is roughly 1.4 h of runtime, enough to reach the charger at the next break. The worked example below carries the arithmetic.

Show LowBatteryAlarm in the HMI software's alarm list with its own text and color. If operators acknowledge alarms at the panel, follow signal an HMI alarm acknowledgment back to the PLC for the handshake.

Keep LowBatteryAlarm out of any stop or safety circuit. Its whole job is getting the charger plugged in before the tablet dies.

Example: a tablet at 17 percent against the raise limit

Inputs: percent now, 17 percent, read from the node's percent field on a tablet that has been off its charger since the shift started, an illustrative reading and a typical case for a kiosk tablet mid-shift. Raise and clear limits as set above. Poll and write interval as configured in the inject node. Battery life for the runtime math, about 7 h of screen-on per full charge, a common figure for a tablet at kiosk brightness.

Rule: the PLC raises LowBatteryAlarm on any poll where TabletBatteryPercent is below the raise limit, and clears it only when a poll reports the clear limit or more.

Arithmetic: 17 percent is below 20 percent, so the alarm sets on the next write. The wait is at most one poll interval and averages about half that. Runtime left at 17 percent is 0.17 × 7 h = 1.19 h, about 1.2 h. At the raise limit the same math gives 0.20 × 7 h = 1.4 h of warning.

Result: LowBatteryAlarm sets within one poll of the crossing, the low-battery entry appears in the HMI alarm list, and the tablet still has about 1.2 h of screen-on time to get plugged in.

Decision: at the raise limit or above, nothing happens. Below it the alarm sets within one poll and stays set until charging carries the reading to the clear limit. If shifts run long and 1.4 h is too little warning, raise the limit: at 30 percent the same tablet gives 0.30 × 7 h = 2.1 h.

How to check it worked

1. The debug pane shows a message on each poll with percent inside the 0 to 100 range and hasbattery true.
2. On charge, percent climbs across successive polls; off charge, it falls. Watch TabletBatteryPercent in the PLC's online view at the same time to confirm the writes land.
3. Test the alarm path quickly by temporarily setting the raise limit to 90 percent while the tablet sits around 60 percent: LowBatteryAlarm should set within one poll and appear in the alarm list. Restore the limit, put the tablet back on charge, and confirm the alarm clears once the reading passes the clear limit.

If the percent never arrives

Work through these in order.

1. No message in the debug pane, or hasbattery false: Node-RED may be running somewhere other than the tablet, because the node reports the machine it runs on. Battery access also differs by platform, so check the node's page for your tablet's operating system. If it cannot read the battery there, the small service program on the BatteryReport class is the fallback, handing the percent over TCP or a file.
2. The OPC UA node reports a connection fault, especially one repeating on the poll cycle: the endpoint address is wrong, port 4840 is blocked, or the security policy does not match. Trust the client certificate on the PLC side and retry. The same fault pattern on an HMI link is worked through in fix an HMI protocol error that pops up every 30 seconds.
3. The connection is up but TabletBatteryPercent stays stale: the write is being refused. Check the variable's access rights in the PLC project and compare the node ID in the write node against TabletBatteryPercent's ID in the server address space.

Recommendation: poll the battery and write to the PLC every 30 s, raise the alarm below 20 percent, clear it at 25 percent, and keep the tablet on its charger whenever it is not in someone's hand. Move the raise limit to 30 percent when shifts run long and 1.4 h of warning is not enough to reach the charger.

Questions