Fix device pairing failures by transport
The E-BON app supports four transports — Bluetooth, USB (via a USB-to-Serial bridge), Serial and TCP — and a pairing failure almost always sits at the transport layer rather than in the fiscal protocol itself. This recipe covers the symptom you see per transport.
FiscalError. The app only probes the fiscal protocol after the transport opens. Expect generic OS-level messages ("device not found", "permission denied", "connection refused") — not codes from the E1xx Connection errors family.Identify the likely cause
- Bluetooth — printer not bonded in Android's system Bluetooth settings, Nearby devices runtime permission denied, or the printer is still connected to a different host.
- USB — USB-OTG cable is charge-only (very common with phone cables), Android per-device USB permission prompt was dismissed, or the printer presents itself as CDC-ACM but no driver-level UART node was created.
- Serial — wrong baud rate (Datecs/Tremol default to 115200, Incotex and the generic Custom adapter to 9600), wrong device node (
/dev/ttyUSB0vs/dev/ttyACM0), or the cable is straight-through where the printer expects null-modem. - TCP — printer's IP is on a different subnet, port is not the one the firmware listens on (most fiscal families:
9100or4999), or a router/firewall ACL is dropping the connection.
Verify the transport works
Before retrying from the app, confirm the transport works at the OS level. Examples below — pick the one that matches your transport.
# TCP — confirm the printer accepts a TCP connection on its declared port
nc -zv 192.168.1.42 9100
# Bluetooth — list bonded devices on the Android device via adb
adb shell dumpsys bluetooth_manager | grep -A2 "Bonded devices"
# Serial — list serial nodes the kernel exposes (USB-to-Serial adapters appear as ttyUSB* / ttyACM*)
adb shell ls -l /dev/ttyUSB* /dev/ttyACM*
If you have already paired the device once and want to re-check the cloud-side record, use the API:
curl https://api.e-bon.ro/api/v1/devices/{deviceId} \
-H "Authorization: Bearer <jwt>"
A 404 NOT_FOUND here means the device exists locally on the phone but was never registered with e-bon — re-run Pair Device on the Pairing screen so the cloud claim succeeds.
Apply the fix
Reset the transport at the OS layer
For Bluetooth, unpair the printer from Android Settings → Connected devices, put the printer back in pairing mode, and re-pair before opening the app. For USB, swap to a known-good USB-OTG cable and re-accept the per-device USB permission prompt. For Serial, double-check the baud rate against the printer manual. For TCP, ping the printer's IP from the Android device and verify it sits on the same subnet as the device's Wi-Fi.
Re-grant runtime permissions
In Android Settings → Apps → E-BON → Permissions, ensure Nearby devices (Bluetooth scan + connect) and Location are granted. Android 10+ requires the location permission for any Bluetooth scan, even when no GPS is used.
Open Device Discovery and re-run the scan
In the app, open Devices → Add device and tap the action card matching the transport (Scan Bluetooth, Manual connection for Serial/USB-to-Serial, or TCP with the printer's IP and port). Pick the printer when it shows up and confirm on the Device Pairing screen.
If auto-detect cannot identify the protocol, fall back to Manual Connect
When the Device Discovery scan finds the printer at the transport layer but cannot pin down the protocol, use Manual connection. Pick the protocol from the list (Datecs FP-700, Tremol FM-05, Incotex 777RR, etc.) and submit. The app then opens the transport with that protocol forced and either pairs cleanly or returns a precise driver-level error you can share with support.
Get help if you're still stuck
Open a support case at support@e-bon.ro or e-bon.ro/contact and include the printer model, the transport you tried, the exact OS-level message and a screenshot of the Device Discovery screen.
Troubleshooting
Per-symptom recipes for the most common e-bon failure modes — pairing, command timeouts, webhook delivery, ANAF rejections, HMAC verification and tier limits.
Command timeouts and the 180s sweep
What `command.timeout` actually means versus `command.failed`, how the 30-second sweep works, and how `Idempotency-Key` lets you safely retry.