Voice Broadcast Not Received
Symptom
The voice broadcast APP activated successfully (or reported an error during activation), but the phone does not announce or print on payment success; or the device drops offline intermittently and occasionally misses broadcasts.
Cause
Broadcast messages are pushed from the platform to the phone over a persistent MQTT over WebSocket (wss) connection. The chain is:
payment success → platform → message broker (Artemis 61614) → wss domain (outer gateway / LB) → phone APPSuccessful activation only proves the phone can reach the platform API; if any link in the pipeline above is broken, broadcasts never arrive — and on the APP side this usually shows up as "silently receiving nothing" without a clear error. Nine times out of ten the pipeline is not set up or the configurations disagree.
Check Order
Work from the platform side toward the phone:
- Platform MQTT config filled in? On the admin panel "System Management → System Configuration → Platform Configuration → MQTT Access", check that all three items (access URL / access account / access password) are filled and saved. When empty, the access URL delivered at activation is blank and the phone has nothing to connect to;
- Access URL correct? It must be the full
wss://domain (e.g.wss://mqtt.example.com) and match the access domain bound in the panel ("Gateway Management → MQTT Access") or your self-hosted reverse-proxy domain. If the platform config was changed, already-activated devices must re-activate once to pick up the new URL; - Subscription topic format correct? The
topicdelivered in the activation response must be the slash formdaxpay/device/audio/{deviceNo}. If it is still the dot formdaxpay.device.audio.{deviceNo}, the device has not been re-activated or the backend is still on an old build. On Artemis 2.33+, subscribing to the dot topic lands on an escaped single-segment address that does not match thedaxpay.device.#permission block, so the subscription is rejected (SUBACK 0x80). Do not work around it by widening the#block; verify the topic contract in the manual deployment; - Message broker ready? Panel users: check that the "Artemis MQTT Access" status card is all green (including the 61614 access port). Self-hosted users: verify item by item against the manual deployment snippets — especially whether the
security-settingpermissions are exhaustive and MQTT has been removed from 61616; - Certificate valid?
wss://requires a valid HTTPS certificate for the domain; an expired certificate or a domain mismatch makes the phone OS refuse the connection; - Account credentials consistent? The account and password in the platform config must match the
app-deviceaccount on the broker; if the broker-side password changed, update the platform side too and re-activate devices; - Behind a CDN? Proxying the access domain through most CDNs cuts persistent connections on timeout — showing up as frequent drops and missed broadcasts. Point the access domain directly at the origin, or terminate HTTPS on an outer gateway that supports WebSocket long connections;
- App switches and order source: are the "Voice Broadcast" / "Receipt Printing" switches of the device's owning app enabled (configured in app management on either panel)? Orders from the online API / EasyPay sources are muted by design;
- Device status: on the merchant panel "Payment Device" page, is the device enabled and shown online (long-term offline means the phone was killed by the OS or the pipeline is down — reopen the APP first).
Fix
- Panel users: if the status card is not all green, click "One-Click Apply" once; verify domain / certificate / CDN against Gateway Management - MQTT Access;
- Self-hosted users: complete the configuration per the manual deployment and restart Artemis; on the reverse proxy, confirm the WebSocket upgrade headers and an idle timeout of at least twice the heartbeat interval;
- After any change: re-activate the device in the APP, then verify again.
Verify
The whole pipeline can be verified without a real payment: the "Test Broadcast" entry on the device row (admin or merchant panel) pushes a test voice — hearing it means the pipeline and switches are all fine; if a real payment is still silent, go back to step 8 for the order source and switches. If even the test broadcast is silent, it is a pipeline issue from steps 1–7.