Flutter Bluetooth Thermal Printer Setup: Panda 58mm POS

Panda printers are everywhere in Indonesian retail. They sit on warung counters, in delivery bags, and behind PPOB windows, they cost a fraction of a counter-top Epson, and they are the printer most Indonesian POS apps are actually asked to support. They are also the reason a lot of Flutter developers discover that Bluetooth printing is not one problem but three: permissions, pairing and protocol.

This is the setup that has held up for me across several devices and Android versions, written in the order you should do it rather than the order the packages document it.

What a Panda printer is, technically

Panda is a brand, not a protocol, and the useful thing about the range is how conventional it is. Reading the published specifications for the common models tells you almost everything you need before writing code.

• The desktop PRJ-58D prints at up to 100 mm per second on 57.5 mm paper over USB and Bluetooth, and it exposes an RJ-11 connector for a cash drawer.
• The portable PRJ-R58B-II is a 58 mm mobile unit at 230 dpi, printing at roughly 50 to 90 mm per second, with a rechargeable battery in the 1500 to 2500 mAh range depending on the variant.
• Both accept ESC/POS commands, which is the whole reason a Flutter app written against an Epson-derived command set works on them at all.

That last point is worth dwelling on. You are not writing Panda code; you are writing ESC/POS code and choosing a transport. If your abstraction reflects that, swapping to a different brand later costs you a configuration value rather than a rewrite.

Four transports, and which one you actually get

Bluetooth is not one thing, and the difference decides which Flutter packages can talk to your printer at all.

The important consequence is the iOS one. Apple has never opened Bluetooth Classic serial port profile to third-party apps — accessories need MFi certification or the External Accessory framework — so a printer that works instantly on Android may be unreachable from an iPhone unless it also offers a low-energy interface. Decide this before promising an iOS release.

The dependency set that stays out of your way

Three packages cover the whole job. Two of them are the transport and content split above; the third is Android's runtime permission model, which you cannot avoid on Android 12 and later.

# pubspec.yaml — the two-package split most Flutter POS apps end up with
dependencies:
  print_bluetooth_thermal: ^1.2.2   # transport: discovery, connect, writeBytes
  esc_pos_utils_plus: ^2.0.4        # content: builds the ESC/POS byte list
  permission_handler: ^11.3.1       # Android 12+ runtime permissions

Resist adding a fourth. Every extra plugin in this space brings its own opinion about scanning, its own platform channel and its own idea of what a connection is, and two of them in one app will fight over the adapter.

The first receipt, end to end

This is deliberately linear: enable, connect, build, write, disconnect. Almost every intermittent Bluetooth printing bug I have chased came from doing these in a different order, or from skipping the disconnect.

import 'package:esc_pos_utils_plus/esc_pos_utils_plus.dart';
import 'package:print_bluetooth_thermal/print_bluetooth_thermal.dart';

/// Discover, connect, print, disconnect. Deliberately linear: the failure
/// modes of a 58 mm Bluetooth printer are all about ordering.
Future<void> printTestReceipt(String macAddress) async {
  if (!await PrintBluetoothThermal.bluetoothEnabled) {
    throw StateError('Bluetooth is off');
  }

  final connected = await PrintBluetoothThermal.connect(
    macPrinterAddress: macAddress,
  );
  if (!connected) throw StateError('Could not connect to $macAddress');

  try {
    final profile = await CapabilityProfile.load();
    final generator = Generator(PaperSize.mm58, profile);

    final bytes = <int>[
      ...generator.text(
        'TOKO SUMBER REJEKI',
        styles: const PosStyles(
          align: PosAlign.center,
          bold: true,
          height: PosTextSize.size2,
          width: PosTextSize.size2,
        ),
      ),
      ...generator.text('Jl. Diponegoro 12',
          styles: const PosStyles(align: PosAlign.center)),
      ...generator.hr(),
      ...generator.row([
        PosColumn(text: 'Kopi Susu', width: 8),
        PosColumn(
          text: '25.000',
          width: 4,
          styles: const PosStyles(align: PosAlign.right),
        ),
      ]),
      ...generator.feed(2),
      ...generator.cut(),
    ];

    await PrintBluetoothThermal.writeBytes(bytes);
  } finally {
    await PrintBluetoothThermal.disconnect;
  }
}

Two details are load-bearing. The capability profile is what maps the generator's intentions onto a specific printer's command dialect, so loading it once and reusing it keeps a receipt internally consistent. And the disconnect belongs in a finally block: a connection left open after an exception blocks the next sale, and the cashier's fix will be to restart the app.

Pairing, in the order that works

Field installs go wrong at pairing far more often than in code. This sequence is what I now write into the shop's setup sheet.

1. Charge the printer fully before the first pairing. A printer at low battery will pair, then drop the connection under the current draw of an actual print.
2. Pair in Android settings, not in the app, and confirm the printer appears as a paired device with a stable name.
3. In the app, list paired devices and let the user pick once; store the MAC address against that device, not against the user account.
4. Print a test receipt immediately, from the settings screen. If the first print happens during a real sale, the first failure also happens during a real sale.

Storing the MAC per device matters in multi-till shops. Two tablets syncing the same account will otherwise fight over one printer address, and each will silently print to the other's printer.

What breaks after the demo

A Bluetooth printer that works on your desk fails in three predictable ways in a shop.

• It sleeps. Most portable models power down after a few idle minutes, and the first print after that wakes it but may be dropped. Reconnect and retry once before showing an error.
• The battery sags. Printing draws far more current than idling, so a printer at twenty per cent prints one receipt and disconnects on the second. Surface battery state if the model reports it, and tell staff to keep it on charge.
• The tablet reassigns the adapter. Another app, a car kit or a headset can take priority; on reconnect your MAC address is still correct but the socket is not. Always treat connect as something that can fail and be retried.

None of these are exotic, and all three are invisible during development because a desk has a charger, no competing devices and a developer who taps print every thirty seconds.

Getting a Flutter app printing to a Panda 58 mm printer is mostly about respecting boundaries: system settings own pairing, one package owns the connection, another owns the bytes, and your code owns the retry. Build it in that order and the printer stops being the flaky part of the product.